Introduction
Systems fail — hardware breaks, regions go down, human error deletes data. Disaster recovery (DR) planning defines how an organization prepares for and recovers from such failures. Two metrics anchor every DR conversation: how much data you can afford to lose, and how long you can afford to be down.
Cricket analogy: A stadium's floodlights can fail mid-match, a groundstaff error can damage the pitch overnight, so every franchise has a contingency plan defining how quickly they can resume play and how much of the day's data they can afford to lose.
Explanation
Recovery Point Objective (RPO) is the maximum acceptable amount of data loss, measured in time. An RPO of 1 hour means that after a disaster, you can tolerate losing up to 1 hour of the most recent data — which dictates how frequently you must back up or replicate data. Recovery Time Objective (RTO) is the maximum acceptable downtime — how long the business can tolerate the system being unavailable before recovery must be complete. An RTO of 4 hours means the system must be back online within 4 hours of a failure being declared.
Cricket analogy: If a scoring app syncs every hour, an RPO of 1 hour means losing at most the last hour of ball-by-ball data after a crash; an RTO of 4 hours means the app must be back up and scoring again within 4 hours of going down.
Cloud providers describe a spectrum of DR strategies with increasing cost and decreasing RPO/RTO. Backup and restore is the cheapest: data is backed up periodically and restored onto new infrastructure only when disaster strikes, resulting in high RPO/RTO (hours to days). Pilot light keeps a minimal version of critical infrastructure always running in a secondary region (such as a database being continuously replicated) that can be rapidly scaled up when needed, improving RTO. Warm standby runs a scaled-down but fully functional copy of the full system in a secondary region at all times, ready to take full traffic after scaling up, further reducing RTO. Multi-site active-active runs full production capacity in two or more regions simultaneously, with traffic routed to both — offering the lowest possible RPO/RTO, near-zero, at the highest cost.
Cricket analogy: A club could just re-enter last season's stats from paper records after a data loss (cheap but slow), keep a backup scorer on standby (faster), run a full parallel scoring team ready to take over (faster still), or run two live broadcasts from two venues simultaneously (instant, but expensive) depending on how critical zero downtime is.
Example
Strategy Relative cost Typical RTO Typical RPO
Backup & restore $ Hours-days Hours
Pilot light $$ Tens of minutes Minutes
Warm standby $$$ Minutes Seconds-minutes
Multi-site active-active $$$$ Near-zero Near-zero# Example: trigger an on-demand snapshot of a database volume as part of a backup routine
aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 \
--description "Nightly backup $(date +%F)"Analysis
An e-commerce checkout system that loses even a few minutes of order data could face real financial and legal exposure, so it may justify the cost of warm standby or active-active. A low-traffic internal reporting tool, by contrast, might tolerate a full day of downtime and data loss, making simple backup and restore sufficient and far cheaper. The core design principle is that RPO and RTO should be set by business impact, and the DR strategy should be the cheapest option that still meets those targets — over-engineering DR for non-critical systems wastes budget, while under-engineering it for critical systems creates unacceptable risk.
Cricket analogy: A live ball-by-ball scoring app losing even a few minutes of data during a World Cup final risks real reputational damage, justifying a fully redundant backup scorer, while a club's weekly practice-attendance log can tolerate a full day of downtime with simple periodic backups.
Key Takeaways
- RPO = maximum acceptable data loss, measured in time; it drives backup/replication frequency.
- RTO = maximum acceptable downtime; it drives how fast recovery infrastructure must be ready.
- DR strategy tiers, from cheapest to most expensive: backup and restore, pilot light, warm standby, multi-site active-active.
- Choose the DR tier based on business impact of downtime and data loss, not just what is technically possible.
Practice what you learned
1. What does Recovery Point Objective (RPO) measure?
2. A system has an RTO of 4 hours. What does this mean?
3. Which disaster recovery strategy keeps a minimal always-on version of critical infrastructure in a secondary region, ready to scale up?
4. Which DR strategy offers the lowest RPO and RTO, at the highest cost?
Was this page helpful?
You May Also Like
Cloud Storage Classes
Learn how hot, cool, and cold/archive storage tiers trade off cost against retrieval latency for different access patterns.
High-Availability Design
Design systems that stay up through redundancy and automatic failover, and understand what each additional 'nine' of uptime really costs.
Multi-Cloud and Hybrid Cloud
Distinguish using multiple public cloud providers (multi-cloud) from mixing private/on-prem infrastructure with public cloud (hybrid cloud), and why teams choose each.