A database is corrupted. A region goes dark. A bad migration wipes a table. It will happen eventually — and when it does, two questions decide how painful it is: "How much data did we lose?" and "How long until we're back?"
Those two questions have names — RPO and RTO — and they're the heart of disaster recovery planning. Get clear on them before the disaster, and recovery becomes a procedure instead of a panic.
The two numbers that matter
When disaster strikes, picture a timeline with the incident in the middle. The two metrics sit on either side of it:
last backup ────[ RPO ]────► 💥 incident ────[ RTO ]────► recovered
- RPO (Recovery Point Objective) looks backward: how much data can you afford to lose? It's the gap between your last good backup and the moment of failure.
- RTO (Recovery Time Objective) looks forward: how much time can you afford to be down? It's how long recovery is allowed to take.
| Metric | Question | Measured in |
|---|---|---|
| RPO | How much data can we lose? | Time of data (e.g. "up to 5 minutes") |
| RTO | How long can we be down? | Time to restore (e.g. "under 1 hour") |
RPO in plain terms
If your RPO is one hour, you're saying: "in a disaster, losing up to the last hour of data is acceptable." That directly dictates how often you back up. Want an RPO of five minutes? You need backups (or replication) at least that often.
- Daily backups → RPO of up to 24 hours (you could lose a day's data).
- Continuous replication → RPO near zero (almost no data loss).
The smaller the RPO, the more frequent — and usually more expensive — your data protection has to be.
RTO in plain terms
If your RTO is one hour, recovery — detecting, deciding, restoring, verifying — must fit inside an hour. That shapes your architecture, not just your backups:
- Restore from backup manually → RTO of hours (download, restore, verify).
- Automated failover to a standby → RTO of minutes (traffic just shifts).
The smaller the RTO, the more automation and redundancy you need standing by.
Setting targets that fit
The trick is matching targets to the business value of each system — not making everything "as fast as possible," which is ruinously expensive.
- Rank your systems. The payments database and the marketing blog have very different stakes.
- Ask the business. "If we lost an hour of this data, what's the impact?" "If this was down for four hours?"
- Set RPO/RTO per system based on those answers — tight for critical, relaxed for the rest.
- Cost it. Tighter targets cost more (more frequent backups, hot standbys). Pay for it where it matters.
The hardest-won lesson: an untested disaster-recovery plan is just a hopeful document. Practise it. Run a real restore. Time it. The first time you test, you'll discover the backup that wasn't actually running, or the restore that takes three times longer than assumed — and you'll find out on a calm Tuesday instead of during the real thing.
How this connects to the rest
DR targets are cousins of your SLAs and SLOs — they're reliability promises, just for catastrophic events rather than everyday ones. And they defend against the big items on the website downtime list: data loss, regional failures, corruption.
The bottom line
| In one line | |
|---|---|
| RPO | How much data you can lose — sets backup frequency. |
| RTO | How long you can be down — sets your architecture. |
| Set by | The business value of each system, not "as fast as possible". |
| Then | Test the plan — an untested DR plan is a guess. |
Disaster recovery isn't about preventing every catastrophe — it's about deciding, in advance and on purpose, how much you can lose and how fast you'll be back. Define RPO and RTO per system, build to meet them, and rehearse — so the worst day is survivable, not existential.
Reliability targets for the everyday kind start with SLA vs SLO vs SLI.