Recovery Targets
DR Strategy Reference
| Strategy | Typical RTO | Typical RPO | Relative Cost |
|---|---|---|---|
| Backup & Restore | Hours – Days | Hours | $ |
| Pilot Light | ~10–30 min | Minutes | $$ |
| Warm Standby | Minutes | Seconds – min | $$$ |
| Hot / Active-Active | Near-zero | Near-zero | $$$$ |
How it works
Two numbers define how resilient a system has to be. RTO (Recovery Time Objective) is the maximum tolerable duration of an outage, how long the business can run without the system before the impact becomes unacceptable. RPO (Recovery Point Objective) is the maximum acceptable data loss expressed as time, the age of the most recent clean restore point you would fall back to in a disaster. A third input, backup frequency, is your worst-case data loss between protection events: if you back up every 24 hours, a failure just before the next run loses nearly a full day of data.
The planner normalises all three inputs to seconds, then runs one hard test: your protection interval must be no larger than your RPO. It also maps your RTO and RPO against the disaster-recovery tiers in the reference table above to surface an architecture pattern whose recovery capability is fast enough to meet both targets.
Backup meets RPO when backup interval ≤ RPO target
Worked example. Target RTO of 4 hours (14,400s), target RPO of 1 hour (3,600s), and nightly backups every 24 hours (86,400s). Because 86,400 > 3,600, the backup interval exceeds the RPO, the planner flags Increase backup frequency. To close the gap you would move protection to hourly or tighter (≤ 3,600s), or adopt continuous replication. The RPO test is independent of RTO: hitting a one-hour RPO says nothing about how fast you can bring the service back.
Benchmarks & reference points
The figures below are exact arithmetic or standard definitions, not survey data. Availability "nines" convert directly to allowed downtime: downtime/year = (1 − availability) × 8,760h. Two other identities frame the same trade-off, availability from reliability data is MTBF ÷ (MTBF + MTTR), and expected loss for the business case is SLE = AV × EF then ALE = SLE × ARO (asset value × exposure factor, annualised by rate of occurrence). DR-posture entries are typical, illustrative conventions.
| Availability (SLA) | Max downtime / year | Max downtime / month | Typical DR posture |
|---|---|---|---|
| 99% | 3.65 days | 7.3 hr | Backup & restore |
| 99.9% | 8.76 hr | 43.8 min | Pilot light |
| 99.99% | 52.6 min | 4.4 min | Warm standby |
| 99.999% | 5.26 min | 26 s | Hot / active-active |
Downtime figures use a 365-day year and a 730-hour (one-twelfth-of-a-year) average month. An SLA target implies an RTO envelope; it does not by itself set your RPO, which is governed by replication or backup cadence.
Using this in the boardroom
RTO and RPO are the cleanest way to make resilience a business decision rather than an IT preference. Present them per system tier - mission-critical, important, standard - not as a single blanket number, because a flat "everything recovers in an hour" target is what drives runaway DR spend. For each tier, pair the objective with its cost consequence: a tighter RPO buys less data loss but demands replication; a tighter RTO buys faster recovery but demands pre-provisioned standby capacity. That framing lets the board choose a service level against a price, which is the decision they are actually equipped to make.
The most common pitfall is a target that has never been tested. A stated four-hour RTO means nothing until a recovery exercise proves it; the gap between the objective and the demonstrated result is your real exposure, and it belongs in the risk register. Pair this number with backup success rates, last-restore-test date, and the annualised loss estimate (ALE) for the systems in scope to turn a resilience ask into a defensible business case.
The one-line takeaway
RTO and RPO are the price tags on downtime and data loss. Set them per system, match each to the cheapest DR tier that credibly meets it, and treat any objective you have not tested as an assumption, not a guarantee.
Frequently asked questions
What is the difference between RTO and RPO?
RTO measures time to recover, how long the outage lasts before service is restored. RPO measures the data you can afford to lose, how far back your last usable restore point sits. RTO drives recovery infrastructure and process; RPO drives backup or replication frequency. A system can have a tight RPO but a loose RTO, or vice versa.
Can my backup frequency be longer than my RPO?
No, that is the single check this planner enforces. Your worst-case data loss equals the gap between protection events, so the backup interval must be equal to or shorter than the RPO. If backups run every 24 hours but the RPO is one hour, a failure can lose far more data than the business agreed to tolerate. The fix is more frequent snapshots or continuous replication.
Should RTO and RPO be the same value?
Not necessarily. They answer different questions and are often set independently. A reporting system might tolerate a long RTO but need a short RPO because the data is hard to reconstruct; a public website might need a short RTO but tolerate a longer RPO. Set each to the business impact it controls.
How do RTO and RPO relate to an SLA's "nines"?
Availability nines cap total downtime over a period, 99.9% allows about 8.76 hours a year. That constrains your RTO envelope (recoveries have to fit inside the downtime budget) but says nothing directly about data loss. RPO is a separate commitment set by how often you protect data, so an SLA and an RPO target are complementary, not interchangeable.
What RTO and RPO should I actually target?
Work backwards from business impact, not technology. Estimate the cost of an hour of downtime and the cost of losing an hour of data for each system, then set objectives where tightening them further stops being worth the added spend. Tier your systems so only the genuinely critical ones carry the most demanding - and most expensive - targets.