Most disaster recovery plans don't fail because the technology didn't work. They fail because nobody agreed, in advance, on what "recovered" actually means — and the first time that gets decided is mid-outage, under pressure, by whoever's on the call.
What RTO and RPO actually measure
Recovery Time Objective (RTO) is how long a system can be down before the business impact becomes unacceptable — the clock from failure to "we're back." Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time — the gap between your last good backup or replica and the moment of failure. They answer two different questions: how long can we wait, and how much can we lose.
Why "as fast as possible" isn't a target
A number you can't measure against is a number you can't plan around. If your RTO is "as fast as possible," nobody can tell you whether a given architecture meets it, and nobody can tell you what it costs to improve it. A real objective — four hours, thirty minutes, near-zero — lets you design a specific architecture and test it against a specific number.
Set objectives per system, not company-wide
Your order-processing database and your internal wiki do not deserve the same recovery objective, and pricing them the same way wastes money in one direction and risks the business in the other. Start by ranking systems on actual revenue and compliance impact, not on how senior the person who asked for them is. A payment system might justify a fifteen-minute RTO and a near-zero RPO. An internal reporting tool might be fine at 24 hours and a nightly backup.
The cost curve: why five-minute RPO isn't always worth it
Recovery objectives don't scale linearly with cost — they scale exponentially as you approach zero. Going from a 24-hour RPO to a 4-hour RPO might mean scheduling backups more often. Going from 4 hours to 5 minutes usually means synchronous replication, a second active site, and meaningfully more infrastructure spend. That jump is often justified for a transaction database and rarely justified for a file share. The point of setting objectives deliberately is making that trade-off on purpose, not by default.
Test the objective, not just the infrastructure
A replicated standby environment proves your architecture works. It doesn't prove your team can execute a failover inside the RTO you promised the business — under time pressure, with the runbook open, without the one person who usually does it. DR drills that measure actual time-to-recovery against the stated objective are what turn a paper plan into one you can trust during a real incident.
This is the core of what we build under High Availability & Disaster Recovery — objectives set per system based on real business impact, failover architecture matched to those objectives, and drills that test the number, not just the hardware.