Why You Need These Numbers Before the Incident
Without agreed-upon targets, every incident becomes a negotiation under pressure. "How long will this take?" is a terrible question to answer while the database is down and the CEO is on the phone. RTO and RPO are the contracts you negotiate with the business before disaster strikes.
RPO — Recovery Point Objective
"How much data can we afford to lose?"
RPO is measured in time. It defines the maximum age of data you must be able to recover. If your RPO is 1 hour, you can lose at most 1 hour of transactions.
| Backup Strategy | Achievable RPO |
|---|---|
Daily pg_dump |
~24 hours |
Hourly pg_dump |
~1 hour |
| Continuous WAL archiving | Seconds (near-zero) |
RPO drives your backup frequency. A financial system processing payments might require an RPO of 5 seconds. A nightly analytics report database might tolerate an RPO of 24 hours.
RTO — Recovery Time Objective
"How long can we be offline?"
RTO is also measured in time. It defines the maximum acceptable downtime from the moment of failure to the moment the database is serving traffic again.
| Scenario | Likely RTO |
|---|---|
Restore 10TB via pg_dump |
24–72 hours |
| Restore 10TB via physical backup (parallel) | 2–6 hours |
| Failover to a warm standby replica | Seconds to minutes |
RTO drives your restore mechanism. If your RTO is 2 hours and your dataset is 5TB, pg_dump is architecturally incompatible with your requirements — regardless of how reliably the dumps are taken.
The Dangerous Gap
The most common DBRE failure mode is an untested RTO. A team takes daily backups, calculates their RPO correctly, but has never actually timed a restore. They assume it will take "a few hours." When disaster strikes, they discover the restore takes 36 hours — and their RTO was 4 hours. The backup was valid. The strategy was broken.
Physical backups are usually required to meet aggressive RTO goals. Warm standby replicas (streaming replication) are required to meet RTO goals measured in seconds.