Disaster recovery starts from explicit recovery time and recovery point objectives, which determine whether you need active-active, warm standby or backup-and-restore. Multi-cloud reduces provider-level risk but adds data replication, consistency and operational complexity that must be justified by a real requirement.
Start from recovery objectives
Recovery time objective is how long the business can tolerate an outage; recovery point objective is how much data it can afford to lose. Both are business decisions derived from impact analysis, and together they determine the architecture far more than any preference for a particular pattern.
Minutes of tolerated downtime justify active-active, which is expensive because it requires full capacity in more than one place and careful data handling. Hours allow warm standby, where infrastructure exists but runs at reduced capacity and scales up on failover. Days allow backup and restore into freshly provisioned infrastructure.
Write the objectives down per system and get them signed off. Without agreed numbers, every incident becomes a debate about whether to fail over, and that debate consumes the recovery window.
Choosing the right pattern
Active-active with traffic split across regions or providers gives the fastest recovery but requires that the application can tolerate concurrent writes in more than one place, which many transactional systems cannot without significant redesign.
Warm standby is the common compromise. A scaled-down replica runs continuously with data replicating in, and failover promotes it and scales it up. The recovery time is dominated by scaling and traffic switching rather than by infrastructure creation.
Pilot light keeps only the data layer live and provisions compute on failover. Backup and restore provisions everything. Both are cheaper and slower, and both are entirely appropriate for internal systems where hours of downtime are acceptable.
| Pattern | Typical RTO | Relative cost | Main difficulty |
|---|---|---|---|
| Active-active | Seconds to minutes | Highest | Concurrent writes and consistency |
| Warm standby | Minutes to an hour | High | Scaling and traffic cutover |
| Pilot light | Hours | Medium | Provisioning and validation |
| Backup and restore | Hours to days | Lowest | Restore confidence and data age |
| Cross-provider standby | Minutes to hours | Very high | Schema and service parity |
Data replication and consistency
Data is where disaster recovery designs fail. Synchronous replication across regions adds latency to every write and is only viable within a limited distance. Asynchronous replication avoids the latency but guarantees a non-zero data loss window, and that window must be stated and accepted rather than discovered.
Failover also raises the split-brain problem. If the primary is merely unreachable rather than dead, promoting a replica can produce two systems accepting conflicting writes. The design needs a fencing mechanism, such as a quorum, a lease with an expiry, or an operator decision with an explicit policy.
Across providers, replication is harder still because managed services differ. Prefer portable data stores with streaming replication, and keep the schema under your own version control so the standby can be brought up independently.
- State the data loss window implied by asynchronous replication explicitly.
- Implement fencing to prevent split-brain during failover.
- Prefer portable data stores when spanning providers.
- Keep schema migrations under your own version control.
Testing and traffic switching
Recovery plans should be tested on a schedule, with the same rigour as a production change. Test three scenarios: planned failover, unplanned failover with the primary abruptly unavailable, and failback. Failback is frequently untested and is where the second outage occurs.
Traffic switching should be automated and reversible. Health-checked DNS with short time-to-live values, global load balancing or anycast routing all work, but the switch must be scripted so it is not dependent on a specific engineer being available.
Measure the actual recovery time achieved against the objective and record it. The gap between designed and achieved recovery time is the most useful number in the whole programme.
- Rehearse planned failover, unplanned failover and failback.
- Automate traffic switching with health checks and short TTLs.
- Record achieved recovery time against the objective every test.
- Treat failback as a first-class scenario, not an afterthought.
Frequently asked questions
Do we need multi-cloud for disaster recovery?
Only if provider-level failure is a genuine risk you must survive and the cost is justified. Multi-region within one provider covers the far more common failure modes at much lower complexity and cost.
What is the difference between RTO and RPO?
Recovery time objective is the maximum tolerable outage duration; recovery point objective is the maximum tolerable data loss measured in time. Both are business decisions that determine which recovery architecture is appropriate.
Why do disaster recovery plans fail in practice?
Usually because failover was never tested, or because failback was not planned. Data replication consistency and split-brain prevention are the other common causes of an outage that lasts far longer than the objective.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.