Disaster Recovery Plan: Setting RTO and RPO per Service

Recovery time objective (RTO) is the longest outage a service can have before the damage is unacceptable. Recovery point objective (RPO) is the longest window of data you can afford to lose, measured backward from the failure. An RPO of one hour means losing at most the last hour of writes.

They're independent. A reporting dashboard might tolerate a day of downtime but no data loss; a real-time feed might tolerate losing a few minutes of history but not an hour of downtime. Set each per service, not for the company as a whole, since a single blanket target either overspends or under-protects.

You don't need precision, just useful buckets. A four-step exercise:

1. List every service and datastore, including identity, DNS, email, and the CI system you'd need to redeploy.
2. For each one, ask what breaks for customers and for revenue if it's down for one hour, one day and one week.
3. Group them into three tiers: revenue-critical, important, and can wait.
4. Give each tier an RTO and RPO. For example, say revenue-critical is one hour and five minutes, important is one day and one hour, and can-wait is one week and one day.

Those tier numbers are examples; yours should come from what your customers and contracts require. Link them to availability promises: a 99.99% target leaves only about 52.6 minutes of downtime per year¹, so a one-hour RTO can't coexist with that promise.

Patterns trade cost for speed. From cheapest to most expensive:

• Backup and restore: data is copied elsewhere, and you rebuild infrastructure from code and restore data after a disaster. Slowest, cheapest. Fits the can-wait tier.
• Pilot light: the database is replicated to a second region, but application servers stay off until needed.
• Warm standby: a scaled-down copy of the whole stack runs continuously in another region and scales up on failover.
• Active-active: traffic is served from multiple regions at once. Fastest, but also the most complex and costly, and it forces hard questions about data consistency.

Most small companies land on backup-and-restore or pilot light for the database. For managed databases such as AWS RDS, cross-region copies and read replicas are the usual building blocks; check what your configuration supports. The backup half deserves its own checklist: retention, off-account copies and timed restore drills.

The runbook is what you follow when nobody has time to think. Each service section should have:

• Who declares a disaster and who leads the recovery, with backups named.
• The order of operations, since identity, DNS and secrets usually have to come back before applications do.
• Exact commands or console steps for restoring data and redeploying, tested by someone other than the author.
• Where credentials and infrastructure code live if your primary account or laptop is unavailable.
• How you'll communicate with customers, using the same approach as your incident response plan.
• Verification steps to confirm the service is really healthy before you announce recovery.

Don't forget dependencies outside your control, such as a payment provider or email service. Note the workaround, or accept that they're part of your RTO.

Start with a tabletop exercise: walk through a scenario such as 'the primary region is unavailable' and follow the runbook aloud, noting every gap. Next, run a real restore into an isolated environment and time it against your RTO. Only after that consider a live failover test in staging, then a controlled window in production if the business needs it.

Record the measured recovery time and data-loss window. If they miss the targets, you have two choices: spend more to improve the design, or change the targets with the business's agreement. Both are legitimate; ignoring the gap is not. See also MongoDB Atlas vs AWS RDS vs Supabase for how datastore choice affects recovery options, and the ransomware response plan for the security variant.