Testing your backups: the practice that separates real backups from wishful thinking

There is a specific moment in the life of almost every backup system where the owner realizes their backup doesn’t work. It happens after a data loss — a failed drive, a ransomware incident, a bad accidental delete — when they go to restore. They log in to the backup service, or they plug in the external drive, or they open the backup application, and they discover that something along the chain has been silently broken for weeks. Sometimes months. Sometimes since they originally set it up.

This is the specific disaster that a five-minute quarterly habit prevents. It is also the disaster that most people never test for.

Why backups fail silently

Backups fail for a depressingly consistent set of reasons, almost none of which announce themselves:

• The backup stopped running. The backup software’s authentication expired, or the service’s credentials rotated, or an OS update broke the background agent.
• The backup destination filled up. The external drive is full; new backups are silently dropped; the old backups age out and aren’t replaced.
• The encryption key is lost. The backup was encrypted with a password that has been forgotten, or with a keychain entry that was deleted when you restored from a previous machine.
• The backup software is backing up the wrong folders. You moved your working files to a new folder, but the backup is still watching the old one.
• The backup media is failing. Spinning drives fail silently for years before dying; a drive with silent bit-rot produces backups that “succeed” but contain corrupt data.
• The vendor is broken. A bug in the backup service means files are uploaded but not retrievable, or are encrypted with the wrong key, or are in a format that the newer client version can’t read.
• The file format moved on. The backup has files in a format your current applications no longer open. Restore works; the file is unusable.

None of these announce themselves. They all announce themselves at restore time — which, for most people, is a moment of maximum stress.

The thirty-second quarterly test

The smallest useful version of backup testing is embarrassingly small. It is also, by a wide margin, the single highest-leverage security practice most readers will adopt.

Once a quarter, do this:

1. Open your backup tool (Time Machine, File History, Backblaze restore page, Arq, etc.).
2. Pick a random file from several months ago — not one you just modified. Something that has been sitting in the backup undisturbed. A photo from last summer. A PDF from last year’s tax folder. Anything.
3. Restore it to a new location — your Desktop, a temporary folder, anywhere that’s not the original location.
4. Open the restored file. Not just “does the file exist” — does it actually open in the application that’s supposed to read it? Does the photo display? Does the PDF render all its pages? Does the spreadsheet look right?
5. If yes, delete the test restore. You’re done.
6. If no, you’ve just found the problem while the house is not on fire. Figure out why and fix it.

The entire cycle takes thirty seconds to a minute, once you’ve done it a couple of times. It catches the overwhelming majority of silent-failure modes in any backup system.

Put the reminder in your calendar now

The hardest part of the thirty-second test is remembering to do it. A recurring calendar reminder is the fix. Title it something specific — “Test restore one random file from Backblaze” — not “Check backups” (which feels vague and is easier to ignore).

What to test, in order of ambition

Level 1: The single-file test (everyone)

The thirty-second test above. Do this quarterly. If you do nothing else, do this. It’s worth more than any backup software upgrade you could make.

Level 2: The multi-era test (quarterly, for the paranoid)

Restore one file from each of a few different eras:

• A file from last month (recent backup working).
• A file from 6 months ago (mid-term retention working).
• A file from last year (long-term retention working).

If your backup retention is supposed to go back 12 months and the year-old restore fails, you’ve discovered your retention isn’t actually what you thought. That’s common; backup services sometimes have retention windows shorter than their marketing suggests, or change them quietly.

Level 3: The full-device test (annually, for small businesses)

Once a year, simulate a full device loss:

• Borrow or repurpose a different computer.
• From scratch, pretend your primary machine is gone.
• Restore from your backup to the borrowed machine.
• See if the critical working files are accessible and usable.

This is the test that catches problems that only show up when you’re trying to restore an entire environment, not just one file: missing credentials, missing application data, missing configurations, broken permissions.

Level 4: The tabletop test (annually, for any regulated practice)

For a small business with regulated data (HIPAA, GDPR, PCI, CPA professional standards), a documented annual tabletop exercise is both a compliance expectation and a good idea:

• Pick a plausible disaster scenario (ransomware on the main laptop, fire in the office, cloud provider outage).
• Walk through how you would respond, step by step.
• Time it. How long before you’re back to a working state? Does the answer match what you told clients your recovery time is?
• Note the gaps. Fix them before the real thing.

Specific tests by backup type

Time Machine / File History (local external drive)

• Plug in the drive. Open the backup browser.
• Navigate to a date from several months ago.
• Right-click a file → restore to a new location.
• Open the restored file.

Specific failure modes to watch for:

• “The backup disk is full” — Time Machine pruning stopped; old backups are gone.
• Drive not recognized — the drive may be failing.
• Password prompt fails — you’ve forgotten the encryption password.

Backblaze / Carbonite / IDrive (continuous cloud backup)

• Log in to the provider’s website.
• Go to the restore interface.
• Browse by date or folder.
• Download a single file.
• Open it.

Specific failure modes:

• “No backup found” — the agent stopped months ago.
• Files missing from recent dates — the backup stopped but older data is still there.
• Slow download — normal for full restores; a red flag if a single small file takes minutes.

Arq / Duplicati / Restic (your own backup to object storage)

• Open the backup client.
• Browse the backup repository.
• Restore one file to a temporary location.
• Open the file.

Specific failure modes:

• Authentication fails — credentials rotated, storage account expired.
• Encrypted repository can’t be opened — key lost.
• Corrupted block — backup repository integrity check needs to run.

Arq and Restic specifically have a check subcommand (restic check, Arq’s “Validate backup set”) that you should run annually to verify repository integrity without doing a full restore.

Online services that sync rather than back up (Dropbox,

iCloud Drive, Google Drive)

For the third time on this site: these are sync, not backup. But if you’re using them as a partial backup layer, the test is:

• Delete a file from your laptop. Wait a few seconds.
• Can you recover it from the service’s trash / version history?
• After the retention window (usually 30 days), is it still recoverable?

The answer to the second question is usually no, which is the point — it’s why you also need real backups.

When a test reveals a broken backup

If the thirty-second test fails, that’s the backup working — at catching its own failure. Now:

1. Don’t panic. Your working files are still on your laptop. You are not in a crisis; you’re in a warning.
2. Diagnose. Is the backup software failing to run? Is the drive failing? Is the password wrong? Each has a specific fix.
3. Fix the specific cause. Reinstall the backup agent, swap the drive, recover the password, update the credentials.
4. Run a full backup once it’s working. Let it complete.
5. Test again. Restore one file. Confirm it works now.
6. Note what broke, in the calendar reminder. Next quarter, check for the same symptom first; failures often recur.

For small businesses: document the test

If you have any regulatory obligation, document each test:

• Date of the test.
• Which backup system was tested.
• What file was restored.
• Whether the test succeeded.
• Any issues found.
• Remediation steps taken.

A simple text file works. Compliance auditors ask for exactly this kind of evidence and will accept a low-ceremony log of real tests over a high-ceremony plan that was never exercised.

The HIPAA and GDPR articles cover the specific documentation expectations under those regimes.

Testing a backup is the least fun part of owning one. It is also the part that turns the whole exercise from insurance you never cashed in into a security control that actually works. Thirty seconds, once a quarter. Put it in your calendar. Do the first one today.