What should a server disaster recovery runbook contain?
A useful recovery runbook lets an authorised team restore a defined service when the usual server or administrator is unavailable. It must connect business priorities to executable, version-appropriate procedures. Keep the runbook accessible independently of the systems it describes.
Before you start
- The service inventory, recovery objectives and owners of each critical dependency.
Instructions
1. Define ownership and activation
Record who declares the incident, who coordinates recovery and who approves restored service. Include trusted contact routes, service identifiers, recovery objectives and the conditions for invoking the plan. Reference how to obtain credentials securely; do not embed passwords or private keys in the document.
2. Document the dependency order
List network and identity prerequisites, required infrastructure, data sources, software versions and existing recovery-point locations. Describe how to choose the correct point and retrieve keys. Arrange restoration so databases, storage and supporting services are ready before dependent application components are started.
3. Specify tests and keep evidence
Define technical and business acceptance checks, data reconciliation, traffic restoration and communications. Include what to do when a step fails and when to escalate. Rehearse the plan in an isolated environment, record actual timings and update it after relevant platform, staffing or application changes.
Check the result
- An authorised colleague can follow the runbook without relying on one person’s memory.
- A rehearsal demonstrates the critical dependencies and acceptance checks.
Troubleshooting
- The runbook cannot be opened during an outage
- Move its authorised access path outside the failed dependency and test emergency access. A document stored only on the unavailable server cannot guide its recovery.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.