Problem
Region goes down. Data corrupted. Ransomware encrypts DB. No plan = extended outage, data loss, business failure.
reliability-opsestablished · high operational burden
Disaster Recovery (DR)
Also known as: dr, business-continuity, rto-rpo, failover
Intent
Define and practice recovery from catastrophic failures: region loss, data corruption, ransomware, ensuring RTO/RPO targets are met.
Forces
- •RTO (Recovery Time Objective): max time to restore service
- •RPO (Recovery Point Objective): max data loss acceptable
- •Cost: DR infrastructure = idle capacity until needed
- •Testing: untested DR plan = no DR plan
Solution
✓ When to Use
- •Any production system with availability requirements
- •Regulatory: DR mandated (finance, healthcare, gov)
- •Customer contracts specify RTO/RPO
✗ When Not to Use
- •Dev/test environments
- •Systems where data loss/downtime acceptable
- •Team not ready for DR investment
Pros
- +Business continuity: survive catastrophic events
- +Compliance: meet regulatory requirements
- +Confidence: known recovery capability
Cons
- −Cost: 2x-4x infrastructure for warm/hot DR
- −Complexity: replication, failover, testing
- −Operational: quarterly tests, runbook maintenance
- −Data consistency: async replication = potential loss
Cost Profile
Infrastructure
High — 2x-4x for warm/hot DR
Operational
High — testing, runbooks, replication monitoring
Cognitive
Medium — RTO/RPO trade-offs, strategy choice
Failure Modes
Untested DR plan fails when needed
Replication lag > RPO → data loss
Failover splits brain: both regions active
DNS TTL too high → clients stuck on dead region
DR region same failure domain (same AZ, same provider)
Real-World Examples
Alternatives
- backup-only
- multi-az
- active-active
- chaos-engineering
Related Patterns
- backup-restore
- multi-region
- replication
- chaos-engineering
- runbook
- rto-rpo
Competency Domains
reliability opsdata statesecurity complianceeconomics evolutiondistribution communication