An untested restore does not exist

What a green light does not say

A backup can finish without an error while containing only part of the data: a database added after the script was written, a volume mounted too late, a table excluded by a filter that has become obsolete.

• The file exists, but it is truncated: the write failed silently for lack of space.
• The dump is complete, but it does not contain the files uploaded by users.
• The data is there, but the encryption key only lives on the machine that was lost.
• Everything is correct, but nobody has the right to reach the backup store.

Measure three things during the drill

A useful drill does not stop at “it worked”. It produces three measurements: the real time until the service is back, the amount of data actually lost, and the list of obstacles encountered.

The third is the most valuable. It reveals the procedures written for an earlier version, the expired access and the steps only one person knows.

Check the business, not just the service

A restored database that starts up says nothing about functional integrity. Check a complete journey: create an order, submit it, find it in the management tool, receive the confirmation.

That check reveals the forgotten dependencies: an empty message queue, a search index to rebuild, files stored outside the database, webhooks still pointing at the old environment.

A realistic cadence

One full drill a year, with a partial restore each quarter, is enough in most contexts. What matters is less the frequency than the record: each drill leaves a dated report, with the gaps against the objectives.

1. Choose a representative scope rather than the entire system.
2. Restore into an isolated environment, from the backups alone.
3. Time it without outside help: the procedure is what is being tested.
4. Record the gaps and fix the documentation straight away.

The question is not “do you back up?” but “when did you last restore, and how long did it take?”