4.8.2. DR Testing Methods
💡 First Principle: A DR plan has unknown gaps until it's tested. Each testing method provides different levels of confidence with different levels of risk. The testing progression moves from lowest risk (tabletop) to highest confidence (live failover).
DR Testing Methods
| Method | What Happens | Risk | Confidence Level |
|---|---|---|---|
| Tabletop exercise | Team walks through the DR plan in a meeting, discussing steps | None (no systems involved) | Low—identifies plan gaps, not execution gaps |
| Simulated failover | Test systems fail over in isolation; production unaffected | Low | Moderate—validates technical steps without production risk |
| Live failover | Actual production traffic fails over to DR site | High (production impact if issues arise) | High—the only true validation |
Production vs. Non-Production Testing
- Non-production: Failover of test/dev replicas in a sandbox. Safe but doesn't prove production would work.
- Production: Actual traffic shifted to DR site. Highest confidence but carries the risk of the DR site not being ready. Schedule during lowest-traffic windows.
DR Test Frequency
| System Criticality | Recommended Test Frequency |
|---|---|
| Mission-critical | Live failover quarterly; tabletop monthly |
| Business-critical | Simulated failover semi-annually; tabletop quarterly |
| Standard | Tabletop annually; simulated annually |
What a Good DR Test Documents
- Actual recovery time achieved (vs. RTO target)
- Data loss at recovery point (vs. RPO target)
- Issues discovered and remediation actions
- Personnel who executed the test and their roles
- Update the DR plan with lessons learned
⚠️ Exam Trap: Tabletop exercises identify plan gaps but cannot find execution problems (a step that's documented but technically impossible, for example). Live failover finds execution problems but carries production risk. Both are necessary parts of a complete DR testing program.
Reflection Question: An organization conducts annual tabletop DR exercises and considers its DR plan validated. During an actual disaster, the team discovers that the DR failover script depends on a resource that was decommissioned six months ago. What type of DR testing would have caught this, and why did tabletop testing miss it?
