Before you build a DR strategy, you must answer two fundamental business questions. These answers drive every architectural and cost decision that follows. You cannot have a "one-size-fits-all" plan; you need specific, agreed-upon targets signed off by business stakeholders — not just engineering.
1. Recovery Time Objective (RTO)
Question: "How long can our application be down before the business suffers unacceptable damage?"
- Definition: The maximum acceptable length of time that your application can be offline after a disaster occurs. The clock starts the moment the disaster is declared, not when engineering first notices something is wrong.
- Example: If your RTO is 4 hours, it means from the moment the disaster strikes, you must have everything back up and running within 4 hours. Miss that window and you've breached your SLA, your legal obligations, or both.
- Business translation: RTO is about time. It answers: "How long can we afford to be dark?"
2. Recovery Point Objective (RPO)
Question: "How much data are we willing to lose?"
- Definition: The maximum acceptable amount of data loss, measured in time. It defines how far back in time you're willing to roll back when you restore from a backup or replica.
- Example: If you back up your database every night at midnight, and a disaster strikes at 11:59 PM the next day, you will lose nearly 24 hours of data. Your RPO in this scenario is 24 hours. If your business can only tolerate losing 15 minutes of data, you need a fundamentally different strategy — like continuous replication — not just more frequent snapshots.
- Business translation: RPO is about data. It answers: "How much work are we willing to redo?"
The Relationship Between RTO, RPO, and Cost
These two metrics are independent axes, but they share a common driver: cost. Achieving a lower RTO requires more pre-provisioned infrastructure (so you can fail over quickly). Achieving a lower RPO requires more frequent or continuous data replication (which consumes bandwidth, storage, and compute). The closer both targets are to zero, the closer your cost approaches "running everything twice, all the time."
This is why RTO and RPO targets must be set by the business, not by engineering. Engineering's job is to say: "Here's what it costs to achieve RTO=1hr/RPO=15min versus RTO=5min/RPO=1min." The business decides which cost is justified.
Interviewers frequently ask: "What's the difference between RTO and RPO?" A weak answer defines them in isolation. A strong answer explains the relationship: "RTO governs how fast you recover the system; RPO governs how much data you can afford to lose. They're set by the business based on cost tolerance, not by engineering based on what's technically easy. A near-zero RPO with a high RTO is possible — you replicate data continuously but take a long time to spin up new infrastructure. A low RTO with a high RPO is also possible — you keep servers warm but only sync data nightly. The combination you choose drives your architecture."