Most DR plans are built for the most likely scenarios and fail in the actual ones. Here is how to design for resilience, not optimism.
The Documentation That Fails Under Pressure
A disaster recovery plan stored in a SharePoint site that is only accessible on the network you just lost is a design failure. DR documentation must be available offline, on personal devices, and in printed form at a minimum. Beyond accessibility, DR plans often fail because they describe what to do in the assumed scenario — total data centre failure — rather than the actual common scenarios: a single server failure with corrupted backups, ransomware that has encrypted the backup server, a SaaS provider outage that affects a critical workflow, or a key person being unavailable. Design for partial failures and external dependencies, not just total failures.
RTO and RPO Must Be Derived from Business Needs
Recovery Time Objective (RTO) — how long before the business is unacceptably impacted — and Recovery Point Objective (RPO) — how much data loss is acceptable — are business decisions, not technical ones. Most organisations set them by asking IT how fast they can recover; the correct approach is asking business leaders how long each critical function can be down before customers leave, revenue stops, or regulatory penalties apply. A healthcare provider may have a 2-hour RTO for patient scheduling; a manufacturing company may accept 4 hours for ERP but only 30 minutes for production control systems.
Backup Validation Is Not Backup Testing
Backup jobs completing successfully is not the same as backups being restorable. The only test that matters is a restore test: actually restoring from backup to a clean environment and verifying the data is complete and the application runs. Most organisations perform backup restore tests annually at best; regulators and insurers increasingly expect quarterly restore validation for critical systems. Document the test: who performed it, which backup set was used, what was restored, and whether the application functioned correctly after restore.
Cloud DR Changes the Economics
Traditional DR required maintaining warm standby hardware at a secondary site — expensive and often under-maintained because it was only touched during an incident. Cloud DR using AWS Elastic Disaster Recovery, Azure Site Recovery, or Zerto dramatically lowers the cost of maintaining a recovery environment. Replication runs continuously to the cloud target; in a failover event, cloud infrastructure is provisioned on-demand. The cost model shifts from maintaining idle hardware to paying for replication compute and storage only while in standby. Test failover costs are also dramatically lower when failover can be automated and torn down after the test.
- DR documentation must be available offline and on personal devices — plans stored only on the affected network fail immediately
- RTO and RPO must be set by business leaders based on business impact — not by IT based on what they can technically achieve
- Backup validation (job completion) is not the same as restore testing — test full application restores quarterly for critical systems
- Cloud DR (AWS DRS, Azure Site Recovery) reduces standby costs dramatically compared to warm hardware at a secondary site