Don’t Panic — Disaster Recovery

Disaster recovery is the arranged return of a technology service after a severe disruption. It exists because a running server, a successful backup job, and a working business service are three different creatures that only occasionally attend the same meeting. The aim is not to rescue every machine first. It is to restore the business outcome that depends on them.

The first useful pair of terms is RTO and RPO. The recovery time objective is the longest acceptable interruption. The recovery point objective is how far back recovered data may be. Together they stop recovery planning from becoming an expensive collection of reassuring nouns. Four hours and fifteen minutes, for example, are requirements for the path, not compliments for the plan.

That path begins with business impact. Name the process that must return, then trace its application, data, identity, network, facilities, suppliers, and the people authorized to decide. A database restored in splendid isolation does not help an authenticated customer complete a transaction. The surprise is that backup and replication are useful, but neither is a complete recovery capability. Replication can copy corruption with great enthusiasm.

Next comes the recovery posture. Backup and restore has low standby cost but takes longer. Pilot light keeps the core ready. Warm standby runs a smaller copy. Active-active serves from multiple locations and adds coordination and consistency demands. The label is not the decision. The complete path must meet the RTO, RPO, capacity, risk, and cost constraints, which is less glamorous but considerably more helpful when the primary environment is unavailable.

A recovery plan is the part that makes those choices executable. Activation criteria say when an authorized team begins. Recovery restores dependencies in order. Reconstitution validates a known state and returns to stable operation. The plan must remain reachable when the primary environment is not, because a recovery document trapped inside the disaster has made a brief but decisive career change.

Testing supplies the evidence. A document review finds stale instructions. A tabletop exposes decisions and coordination. A simulation exercises procedures. A full recovery test checks the complete path and its timing. Record the actual recovery time, recovered data point, failed steps, manual work, and hidden dependencies. Then correct the design and test it again.

Read the Course introduction for the full map and glossary. Use Slides for the dependency flow and recovery-posture comparisons. Keep Cheatsheet open while designing a runbook or reviewing a test. The Quiz is where a component check has to defend itself against a business-function check.

Don’t Panic — Disaster Recovery

Relevant careers