Disaster Recovery (DR) is the organisational capability to restore critical technology systems and data to operational status following a catastrophic event — whether a natural disaster (flood, fire, earthquake), a human error (accidental deletion, misconfiguration), a cyber attack (ransomware, destructive malware), or an infrastructure failure (power outage, hardware failure at scale).
Key DR metrics
Recovery Time Objective (RTO) is the maximum acceptable time between a disaster and the restoration of service. If your RTO is 4 hours, your DR plan must restore all critical systems within 4 hours of an incident.
Recovery Point Objective (RPO) is the maximum acceptable data loss, measured in time. If your RPO is 1 hour, you must be able to recover to a state no more than 1 hour before the disaster — meaning backups or replication must run at least every hour.
RTO and RPO define the engineering requirements for your DR architecture. Lower values require more investment: active-active multi-site architectures can achieve RTO of seconds and RPO of zero, but at significant cost. Backup-and-restore architectures are cheaper but may have RTO of hours and RPO of 24 hours.
DR tiers
Backup and restore: Data is backed up to a separate location. Recovery involves restoring from backup and rebuilding the environment. Lowest cost, highest RTO/RPO.
Pilot light: A minimal version of the environment runs continuously in a secondary site (just the core components). In a disaster, the remaining components are activated. Moderate cost and RTO.
Warm standby: A scaled-down version of the full environment runs continuously and is synchronised with the primary. Recovery involves scaling up the secondary. Lower RTO, higher cost.
Active-active: Full production capacity runs in multiple sites simultaneously. Traffic is distributed across all sites. Failover is automatic and seamless. Highest cost, near-zero RTO/RPO.
DR testing — the critical gap
Most DR plans are tested rarely or not at all. When they are tested, the test is usually a theoretical walkthrough rather than an actual failover exercise. This is the single most dangerous gap in enterprise IT risk management — the only way to know a DR plan works is to execute it against production systems. Platforms that simulate DR (chaos engineering, automated failover exercises) close this gap.