liveBook · Manning

Recovery time objective

As explained in PostgreSQL Mistakes and How to Avoid Them

A recovery time objective is the maximum acceptable duration of service unavailability after a disruptive failure.

Recovery time objective (RTO) is the maximum downtime acceptable before service is fully restored after a disaster. In PostgreSQL, RTO depends on the high-availability architecture, not merely on having backups. section 9.5

The backup-only recovery trap

A team may feel protected because backups and point-in-time recovery can recover committed data. If the server burns down, however, restoring the installation onto replacement hardware or a new cloud instance can cause significant downtime. A spare server or standby reduces that restoration delay; replication and failover architecture determine whether the result meets the RTO. section 9.5

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

Use the cascaded-replication diagram to relate redundancy architecture to faster recovery and reduced service interruption. section 9.5

How PostgreSQL Mistakes and How to Avoid Them covers it

How deep it goes
Defines downtime tolerance and connects it to HA architecture, but stops short of prescribing a numerical target or recovery procedure.
Examples
Uses server fire, replacement infrastructure, backups, spare servers, and cascaded replication as recovery scenarios.
What you can do after
Evaluate whether backup-only recovery or redundant PostgreSQL infrastructure can meet an acceptable downtime limit.
How it connects
Connects RTO with RPO, PITR, WAL, backups, replication, warm standby, hot standby, and high availability.

Also explained in

Compare how 3 books explain recovery time 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.