Why You Must Test Your Backups

Why You Must Test Your Backups

Photo by Daniil Komov on Pexels

A backup that has never been tested is not a backup — it's a hope. The most heartbreaking moment in IT is when a business loses data, reaches for their backup, and discovers it's incomplete, corrupt, or missing critical files. Testing is the only way to know your safety net will hold.

The Statistics Are Alarming

• 34% of businesses never test their backups at all.
• Of those that do test, 77% discover failures on the first attempt.
• The most common failure: backups were running but capturing the wrong files or missing database dumps.
• 23% of tested backups fail to restore completely, leaving critical data unrecoverable.

What Can Go Wrong Without Testing

• Incomplete backups: The job was silently skipping your database because the DB was locked during backup. You find out only when you need it.
• Corrupted archives: A disk error corrupted 6 months of backups. Without testing, you don't discover this until you try to restore.
• Encryption key lost: The employee who set up the backups left the company. The key is on their laptop, which was wiped. Backups exist but can't be decrypted.
• Wrong version: Your backup software was upgraded, and the new version can't read archives created by the old version.
• Missing dependencies: You backed up application data but not the application configuration or the database schema. Restoring data without the schema is useless.

How Often Should You Test?

What a Good Backup Test Includes

1. Verify the backup exists and is recent: Check the timestamp. Is it from last night or from 3 weeks ago?
2. Verify the file count and size: Does the backup contain roughly the same number of files and total size as the original? A sudden drop in size signals missing data.
3. Restore a sample of files: Pick 5–10 random files from different directories. Restore them to a test location and open them. Are they valid and current?
4. Test database restores: If you back up databases, restore to a test instance and run a query. Verify the data matches the production system.
5. Verify you have the decryption key: Attempt to decrypt the backup. If you can't, you have no backup.
6. Document the recovery time: How long did the restore take? Is that acceptable for your business's downtime tolerance?

Free Tools for Backup Verification

• Borg: borg check --verify-data repo — verifies all checksums.
• Restic: restic check --read-data — reads and verifies every backup pack.
• Duplicati: Built-in "Verify" option in the web UI.
• Hash check: sha256sum backup.tar.gz and compare to the stored checksum.

Key Takeaways

• 34% of businesses never test backups; 77% of those that do find problems. Testing is non-negotiable.
• Test at multiple levels: weekly integrity checks, monthly file restores, quarterly full restores, annual disaster simulations.
• A good test verifies not just that files exist, but that they're valid, current, and decryptable.
• Document recovery time — knowing you can restore in 2 hours vs 2 days is critical for business planning.