Backups Are Not a Disaster Recovery Plan
Most organisations have backups. Considerably fewer know how long a full restore takes, who performs it, in what order systems come back, or whether the most recent backup is readable. The gap between those two states is where outages turn into existential events.
Two numbers, agreed with the business
Recovery time objective — how long you can be down. Recovery point objective — how much data you can afford to lose. These are commercial decisions, not technical preferences, and they must be agreed with people who own the consequences. Incident retrospectives published across the industry, including the summaries at the resilience coverage on this site, show that recovery failures usually trace back to these numbers never having been set at all.
What a real plan contains
- An ordered dependency list — what must be running before anything else can start
- Named roles, with deputies, because incidents ignore holiday schedules
- Credentials and runbooks accessible when the primary environment is down
- Communication templates for customers and regulators, written in advance
- A restore test on a schedule, with the result recorded
Ransomware changed the requirements
Backups reachable with production credentials are part of the blast radius. Modern practice separates them: immutable storage with retention locks, separate accounts and credentials, at least one copy that cannot be deleted by any operational identity. If an attacker with administrative access could destroy your backups, you do not have backups — you have copies.
Test the restore, not the backup job
A successful backup job proves data was written somewhere. Only a restore proves it can come back, and the first attempt always reveals something: a missing dependency, an expired certificate, an undocumented configuration file. Do it quarterly, time it, write down what broke, and fix those things while the building is not on fire. That exercise is the entire difference between a policy and a capability.