Disaster Recovery
Disaster Recovery
The Disaster Recovery domain tests how you keep critical services and data available after a disruption. Expect questions on business impact analysis (BIA), recovery objectives, backup design, alternate-site strategies, plan roles, and exercise results.
Core rules
- The BIA identifies critical processes, dependencies, and maximum tolerable downtime (MTD). DR derives recovery time objective (RTO), the target time to restore service, and recovery point objective (RPO), the maximum acceptable data loss measured in time.
- RTO must be less than or equal to MTD. RPO drives backup frequency and replication. A 15-minute RPO cannot be met by a nightly full backup alone.
- Know backup behavior: a full copies all selected data; an incremental copies changes since the last backup of any type; a differential copies changes since the last full. Restore chains differ, so test restores, not just backup jobs.
- Use layered protection: 3-2-1 copies, offline or immutable backups, encryption, and periodic restore tests. Snapshots improve rollback but are not a complete DR strategy.
- Site options range from hot (near-ready duplicate), warm (partial capability), to cold (space and power only). Cloud patterns include backup-and-restore, pilot light, warm standby, and active-active.
Worked example
A payment service has an RTO of four hours and an RPO of 15 minutes. The team proposes a nightly full backup to a remote site. Reasoning: the restore can plausibly fit four hours, but the RPO is violated by up to 24 hours. A compliant design needs more frequent incremental backups or continuous replication, plus a tested restore runbook and an exercise that measures actual restore time.
Traps
Swapping RTO and RPO; treating high availability as DR; assuming a snapshot is an offsite copy; never testing restores; forgetting dependencies such as DNS, identity, and encryption keys; and suspending security controls during recovery.