RPO and RTO
Set two targets for every disaster, how much data you may lose and how long you may be down, and let them pick the backup and standby design.
RPO is the most data you accept losing, measured in time. RTO is the longest you accept being down.
Use it when#
Someone asks "are we backed up?" and the honest answer is "to when, and how fast can we get it back?"
A bad migration or a dropped table has to be undone, and the last copy is a day old.
You choose between nightly snapshots, log archiving and a standby.
How it works#
RPO is set by how often data leaves the primary. A nightly snapshot means an RPO of up to 24 hours. Point-in-time recovery archives the write-ahead log (WAL) continuously, so the RPO is minutes and you can restore to just before the bad statement. Synchronous replication brings it to zero, at the price of slower writes.
RTO is set by how long recovery takes. Restoring a snapshot and replaying a log grows with the size of the data, so a 1 TB database restores far slower than a 10 GB one. A hot standby skips the copy and takes over in seconds.
A standby does not undo a delete, because it copies the delete too. Only a backup with history does.
What it costs#
Log archiving and a standby each add storage and a second box. The usual mistake is trusting backups nobody has restored. A drill finds the bad one before the disaster does.
In Quorum#
Pick a Database's backup mode, as below. Nightly is the cheap floor, and PITR keeps minutes of RPO.
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | medium | Medium for the app, so the Database is the part under test. |
| Database | Instance size | medium | Medium for the primary. |
| Database | Backups | pitr | Point-in-time recovery archives the write log, so the gap shrinks from a day to minutes. |
| Database | Standby | On | The standby shortens the recovery time when a zone fails. It does nothing for a bad delete. |
Research this Design needs: Point-in-time recovery, Multiple zones, Health checks, Restore drills.
A backup nobody has restored may not restore, and Restore drills test each backup as it is taken so that roll never fails. Pressing Restore after an accidental delete reads the backup, and the time grows with the rows. A Read Replica in another region sets the RPO by its lag, and a Spread store loses none. The DR drill measures both numbers for the IPO checklist. See Disaster recovery tiers, and the glossary entries RPO and RTO and point-in-time recovery.