Your Backup Isn’t a Backup Until You’ve Restored It

Technical Briefing | 10/21/2026

We all set up backups. Script it, cron it, ship it off to S3, whatever. We see files accumulating in the destination, and there’s this warm, fuzzy feeling that we’re safe. Then, one day, the unthinkable happens. Production is down, data’s gone, and you need that backup. Only to find out the archives are corrupted, half-empty, or full of zero-byte files from that one time the disk filled up silently. I’ve seen this bite otherwise smart people in prod, and believe me, it’s a painful lesson to learn mid-crisis.

The Lie of “Files Are There”

Just because rsync reports it copied a gazillion files, or your object storage bucket shows terabytes of data, doesn’t mean those files are actually *good*. Bits flip. Processes get killed mid-write. Filesystems can quietly get inconsistent. You can copy a corrupted file perfectly. And that’s not a backup; that’s just a perfectly replicated problem waiting to ruin your day. Most backup tools focus on transfer, not on deep integrity checks. So you’ve got to bake that in yourself.

find /path/to/source_data -type f -print0 | xargs -0 sha256sum > /tmp/source_checksums.txt
find /path/to/backup_copy -type f -print0 | xargs -0 sha256sum > /tmp/backup_checksums.txt
diff -u /tmp/source_checksums.txt /tmp/backup_checksums.txt

That little `diff` command, right there, can save your skin. Run it regularly, compare your active data against its backup copy’s checksums. If you see differences, you know you’ve got a problem long before you’re in an emergency. It won’t catch everything, but it’s a hell of a lot better than just trusting the file count.

The Acid Test: Mock Restoration

Checksums are good, but they’re not the full picture. The only way to truly know your backup works is to *restore it*. You don’t need a full-blown disaster recovery drill every week, but you should be doing mock restores of critical components regularly. Can you restore your database to a staging environment and bring it online? Does your restored web app actually start up and serve requests? Do the permissions and ownerships line up the way they should? Because I’ve seen ‘perfect’ file restorations fail because `chmod` and `chown` weren’t preserved properly.

• Spot-restore a random selection of critical config files from different backup points.
• Attempt a database restore to a separate, isolated environment at least monthly.
• Periodically perform a full operating system restore to a test VM or spare hardware.
• Validate not just file content, but also permissions, ownership, and extended attributes after a restore.
• Run basic application-level tests against your restored data to confirm functionality.

This isn’t about paranoia; it’s about pragmatism. Your data is literally your business’s lifeblood. Don’t leave its recovery to chance or a wish and a prayer. Make verification an integral part of your backup strategy, not an afterthought. It’s continuous work, yes, but it’s the kind of work that truly distinguishes a professional operation from one waiting for the next catastrophe.