← Concepts

阅读中文版本

Disaster Recovery

Disaster recovery restores service after a large-scale failure. It is measured by tested recovery time and data loss, not by the thickness of a plan document.

reliability

Definition

Disaster recovery (DR) is the set of technical and organizational capabilities that restore critical systems and data after an event that disables a primary site, region, provider, or core dependency, within declared recovery objectives.

Context and scope

DR covers scenarios beyond routine incidents, such as region outages, ransomware, corrupted replication, and loss of a critical vendor. It depends on backups, replicated infrastructure, runbooks, and people who have practiced failover.

Common misconceptions

  • High availability is the same thing as disaster recovery
  • A disaster recovery plan is complete once it is written
  • Failover is automatic and risk-free in every architecture

Anti-patterns

  • Running failover drills without measuring actual recovery time
  • Making the DR region depend on the same identity, DNS, or key service as production
  • Treating DR as an annual document review instead of a tested capability

Related concepts

Related examples

Authoritative source

https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final

How it works

DR starts with a business impact analysis that ranks systems and sets recovery objectives. Strategies form a cost ladder: backup and restore, pilot light, warm standby, and active/active multi-site. Each needs traffic failover through DNS or global load balancing, data replication, independent identity and key services, runbooks, and communication plans. Game days rehearse the switch and record actual timings.

detect region failure -> declare incident -> promote replica
-> repoint DNS / load balancer -> verify critical journeys
-> communicate status -> plan failback

When to use it

Plan DR for events that exceed normal incident response: regional outages, ransomware, corrupted replication, provider failure, or loss of a core dependency. Compared with high availability, which masks component failures within a region, DR addresses losing the region or the primary provider itself.

Trade-offs

Active/active gives the fastest recovery but demands conflict handling, data partitioning, and double the operational surface. Warm standby is cheaper but may run stale and untested. Backup-and-restore is simplest but slowest. Untested DR drifts as infrastructure, dependencies, and people change.

Concrete example

A team runs production in one region and a warm standby in another with asynchronous replication. During a game day they promote the standby, repoint DNS with a 60-second TTL, and measure 22 minutes to restore checkout, inside the one-hour target, while discovering a missing secret in the standby vault.

High availability is not DR, and a written plan is not a capability. DR is proven by measured recovery, not documentation. Related concepts include Backup and Restore, RTO and RPO, Chaos Engineering, and Runbook.