Two numbers shape every disaster recovery design: how long you can be down, and how much data you can lose. Agree them with the business before you choose technology, because they decide the cost.
The definitions
- Recovery time objective (RTO): the maximum acceptable time between an outage and the service being usable again.
- Recovery point objective (RPO): the maximum acceptable amount of data loss, measured as time. An RPO of 15 minutes means you can lose up to the last 15 minutes of data.
How to set them
Start with business processes rather than servers. For each process, ask what happens after one hour, four hours, one day and one week without it. Then map the processes to the systems they depend on, including the dependencies people forget: identity, DNS, networking and licensing.
- Group systems into three or four tiers instead of inventing a number for each server.
- Write the tier, RTO, RPO and owner next to each system in one table.
- Check dependencies. A tier-one application cannot recover faster than the identity service it relies on.
Matching targets to technology
Tight RPOs need continuous replication or very frequent snapshots. Tight RTOs need infrastructure that is already standing by. Relaxed targets can use nightly backups and rebuild on demand, which costs far less. Most organizations discover that only a small share of systems justify the expensive tier.
Prove it
A target is only a wish until you have tested it. Schedule restore and failover tests, record the actual times, and report the gap between target and result to management. Add one scenario where backups are the only thing left, because that is the ransomware case.