Having backups is not the same as having a recovery plan. Plenty of teams discover this during an outage, when the backup exists but nobody knows how long a restore takes, which credentials it needs, or whether the restored system will even start.

Disaster recovery planning is really a series of business questions answered with engineering. Two numbers drive almost everything: how much data you can afford to lose, and how long you can afford to be down.

The Two Numbers

Recovery point objective (RPO) is the maximum amount of data loss, measured in time, that the business will tolerate. An RPO of one hour means that after recovery you may be missing up to the last hour of writes.

Recovery time objective (RTO) is the maximum acceptable time from the start of an outage until the service is usable again.

These are targets, not guarantees. The honest work is checking whether your current setup can actually meet them. A nightly backup cannot satisfy an RPO of fifteen minutes, no matter how good the tooling is.

Set Them Per Service, Not Per Company

A single company-wide RPO and RTO sounds tidy and produces bad outcomes. Either you overspend protecting a reporting dashboard like it is the payment system, or you under-protect the payment system because the budget was spread thin.

Go through your services and ask the owning team and the business sponsor two plain questions: what happens to the business if this is down for an hour, a day, a week? And what happens if we lose the last hour, the last day of its data? Group the answers into a few tiers. Three is usually enough.

A trap I see often: engineers pick the targets alone. The result is either unrealistic ambition or targets nobody has the mandate to fund. The numbers need a business owner who understands the cost of each tier.

Recovery Patterns and What They Trade

Cloud providers describe a spectrum of approaches, usually from cheapest and slowest to costliest and fastest. The names vary but the shape is consistent.

Pattern	What runs in the recovery site	Typical recovery speed	Relative cost	Good fit
Backup and restore	Nothing until disaster	Slowest	Lowest	Internal tools, non-critical batch systems
Pilot light	Data replicated; minimal core running	Moderate	Low to moderate	Services with a moderate RTO
Warm standby	Scaled-down full copy always running	Fast	Moderate to high	Customer-facing services
Active-active	Full capacity in multiple locations	Fastest	Highest	Services where downtime is unacceptable

Higher tiers also bring more complexity, especially around data consistency across locations. Active-active with a single-writer database is not really active-active for writes. Be sceptical of any design that claims fast failover without explaining how data stays consistent.

What Actually Has to Be Recoverable

The database is the part everyone remembers. The parts that bite are the ones adjacent to it:

• Infrastructure definitions. If your environment was built by clicking in a console, rebuilding it under pressure is guesswork. Infrastructure as code turns a rebuild into a repeatable process.
• Secrets, certificates and keys. A restored application that cannot decrypt its own configuration is useless.
• DNS and traffic routing. Failover often depends on changing where users are sent, so know who can do that and how.
• Dependencies outside your control. If your recovery region needs a third-party service that is also affected, your plan has a hole.
• Access. If the identity provider used to log in lives in the failed environment, how do your engineers get in?

Test It, Then Test It Again

An untested plan is a hypothesis. Restores fail for boring reasons: expired credentials, a backup that was never actually verified, a runbook referencing a server that no longer exists.

Start small. Restore a backup into an isolated environment and check that the data is intact and the application starts. Time it. That measured duration is your real RTO for that tier, which is often longer than anyone assumed. Then run a larger exercise where a team follows the runbook with only the documentation, no tribal knowledge.

Schedule these. Systems change, and a plan that worked last year may not work now.

A Realistic Example

Suppose a team runs an order service, an internal wiki and a nightly reporting job. They classify the order service as needing an RPO of minutes and an RTO of under an hour. The wiki can lose a day and be down for a day. Reporting can be rebuilt from source data.

For the order service they choose warm standby in a second region with continuous database replication. The wiki gets nightly backups. Reporting gets nothing beyond its code in version control.

During their first restore test of the wiki, they find the backup works but the restore takes far longer than expected and requires a secret held by one person on leave. They fix the secret storage and update the stated RTO. That is a successful test: it found problems before an incident did.

Frequently Asked Questions

Is high availability the same as disaster recovery? No. High availability keeps a service running through common failures like a single instance or zone going down. Disaster recovery deals with larger events such as losing a region, corruption or a destructive mistake. You usually need both, designed together.

Do replicated databases replace backups? Not by themselves. Replication faithfully copies mistakes, including accidental deletes and corrupted data. Backups with point-in-time recovery protect against that. Many teams keep both.

How often should I test recovery? Often enough that the plan cannot silently rot. A small restore test on a regular schedule, plus a fuller exercise at least periodically and after major architecture changes, is a reasonable pattern. The right cadence depends on how critical the service is.

Should the recovery site be in another region or another provider? Another region covers most regional failures. A second provider adds protection against provider-wide problems, but also significant complexity and cost. Decide based on the impact the business can tolerate, not on fashion.

Who should own the plan? The service owner, with business sign-off on the targets. A central team can provide patterns and tooling, but they cannot own every service’s recovery.

Next Step

Pick your most important service and write down its current RPO and RTO in one sentence each, then run a timed restore of its latest backup into an isolated environment. Compare the measured result with what everyone believes. The gap is your first piece of real disaster recovery work.