A backup is not a recovery

Almost every organization has backups. Far fewer have ever restored a whole environment, in order, with the people who would have to do it on a bad day. The gap between the two is the gap between a copy and a capability.

What a backup does not tell you

• How long restoration will really take, end to end, including identity, network and the applications that depend on them.
• Whether restored data is consistent and usable by the application, not just present on a disk.
• Whether the backup itself would survive an attack: isolated or immutable copies, separate administration accounts.
• Whether anyone other than the person who set it up knows how to restore it.

A simple test to start with

Pick one important service. Set a recovery time objective with its business owner. Then time a restoration in a separate environment, using the documentation as it exists today. Write down everything that got stuck: a missing password, a forgotten dependency, a step that was written down nowhere.

The first test almost always fails, and that is exactly its value. Every blocker found in an exercise is one you will not have to discover during an incident.

Takeaways

Measure recovery, not backup. Repeat the test after every significant change, and keep the result: it is the evidence that your objectives are realistic.