Backups are evidence, not assurance
A completed job proves that a program wrote something. A restore drill shows whether the result contains the right data and can be used within the time available.
Choose a representative restore
Pick one database, one directory with permissions and symbolic links, and one configuration secret. Restore into an isolated location; never test over the live copy.
Capture four pieces of evidence
- The snapshot identifier and creation time.
- The exact restore command and elapsed time.
- Integrity checks for restored files or records.
- The cleanup result for the temporary restore.
Test assumptions around the backup
Confirm that credentials are accessible, encryption keys exist outside the failed system, retention includes the required date and enough free space exists at the restore target.
find restored/ -type f -print0 | sort -z | xargs -0 sha256sum
stat restored/etc/example/config.ymlSchedule the next drill
A useful cadence depends on change rate and recovery objectives. The important property is regularity: documentation, access and tooling should not drift silently for years.
Write down whether the recovery objective was met. “Restore succeeded” is incomplete without elapsed time and validation.