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.
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
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.
Misconceptions and related concepts
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.