An enterprise platform with strict availability commitments must define its disaster recovery strategy. How should RTO and RPO targets drive the choice between backup restore, warm standby, and active-active?

The two numbers that decide everything

RPO — recovery point objective: how much data you can afford to lose, measured in time. It is determined by replication, not by recovery procedure.

RTO — recovery time objective: how long you can afford to be down. It is determined by how much must happen after the failure before service resumes.

Every strategy is a point on the curve these two define, and cost rises steeply as both approach zero.

The options

Backup and restore. RPO equals backup frequency (hours). RTO equals restore plus verification plus cutover (hours to days). Cheapest by a wide margin. Appropriate for systems where a day's downtime is survivable — internal tools, analytics, archives.

Pilot light. Core data replicated continuously; minimal infrastructure running; the rest provisioned on failover. RPO minutes, RTO hours. Modest cost. The risk is that the provisioning step is rarely exercised and frequently does not work when needed.

Warm standby. A scaled-down but running copy of the full stack, continuously replicated. RPO seconds, RTO minutes. Substantially more expensive. Failover is a traffic redirect plus a scale-up, and both can be tested.

Active-active. Both regions serve traffic continuously. RPO near zero, RTO near zero. Most expensive, and the complexity is not linear — it introduces bidirectional replication, conflict handling, and split- brain risk. But it has one decisive advantage: the failover path is the normal path, so it is exercised constantly rather than annually.

How to choose

By business impact per unit of downtime, per system — not per company. The common mistake is a single enterprise-wide DR standard, which over-invests in systems that do not need it and under-invests in the ones that do.

• Revenue-critical transactional systems justify warm standby or active-active.
• Systems whose failure is embarrassing but not costly justify pilot light.
• Systems whose failure nobody notices for a day justify backup and restore, and saying so out loud is an act of engineering honesty.

The questions that expose weak DR plans

"When did you last fail over?" A DR plan that has never been executed is a document, not a capability. The most common finding in a real disaster is that the plan's assumptions expired: a dependency added last year that exists only in the primary region.

"What is the RPO of your dependencies?" Your database may replicate continuously while your configuration store, secrets manager and object storage do not. The system's real RPO is the worst of its components.

"Can you fail back?" Failing over is half the problem. Returning — with data written in the secondary region during the event — is frequently harder and almost never rehearsed.

"Does failover need the thing that failed?" If the runbook requires a service in the failed region, the plan does not work.

The honest framing

DR is insurance, and the premium is paid continuously against an event that may not occur. The architecture's job is to make the premium proportional to the actual business risk of each system, rather than uniform — and to ensure the policy is tested, because an untested DR plan is an expense without a benefit.