liveBook · Manning

Recovery point objective

As explained in PostgreSQL Mistakes and How to Avoid Them

A recovery point objective is the maximum amount of data loss measured in time that a disaster-recovery plan is designed to tolerate.

A recovery point objective (RPO) measures how much data a disaster-recovery plan can afford to lose. In PostgreSQL, point-in-time recovery can restore committed data through the last WAL file successfully saved. section 9.5 section 9.5

Backups are not automatically enough

A team runs automated backups and assumes the database is protected. If the server burns down before the newest WAL file is saved, recovery may stop at an earlier committed transaction; the unsaved interval is the realized data loss. Keeping a spare server addresses recovery time, not the RPO itself. section 9.5 section 9.5 section 9.5

Figure 9.3 A sample PostgreSQL HA setup with a cascaded replication for redundancy and backup
figure

Use the cascaded-replication layout to relate redundancy and backup paths to reducing exposure to data loss. section 9.5

How PostgreSQL Mistakes and How to Avoid Them covers it

How deep it goes
Defines the metric and relates it to PITR and saved WAL, while deferring detailed recovery procedures.
Examples
Uses automated backups, server destruction, saved WAL files, PITR, and cascaded replication as operational examples.
What it assumes
Assumes PostgreSQL backup familiarity while defining RPO alongside PITR, WAL, replication, and RTO.
What you can do after
Evaluate whether backup and replication arrangements limit disaster data loss to an acceptable interval.
How it connects
Connects point-in-time recovery, write-ahead logging, replication, redundancy, and recovery time objective.

Also explained in

Compare how 5 books explain recovery point objective →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of PostgreSQL Mistakes and How to Avoid Them. The section links point to the parts of the book it draws on.