An untested backup isn't a backup. It's a belief about a backup, and the two feel identical right up until the moment they don't.
This isn't hypothetical caution. Backup failures are common, and nearly all of them are silent — the software reports success, the drive shows the right amount of used space, and the data isn't recoverable. The only way to know is to try.
Three levels of test, escalating in effort. Do level one today.
Level 1: The five-minute file restore
Do this now, and then quarterly.
- Pick a file you'd care about — a real document, not a test file you just made.
- Open your backup software or drive.
- Restore it to your desktop, not over the original.
- Open it.
- Confirm the contents are correct and complete.
That's it. Five minutes.
What this catches:
- Backup software that reports success while writing nothing
- A drive that's failing and can't be read
- Encrypted backups whose password no longer works
- Files that backed up as zero bytes
- Backup software you can no longer run because of an operating system update
- A backup that's been pointed at the wrong folder for two years
Every one of those is a real, common failure. Every one of them is invisible without this test.
Choose the file deliberately. Pick something from a folder you rarely open, and pick something old. Recent files from your main documents folder are the ones most likely to be fine. The photo library from three years ago is where problems hide.
Level 2: The folder test
Do this annually.
- Pick an entire folder — a project, a year of photos, a client folder.
- Restore the whole thing to a separate location.
- Compare it against the original: file count, total size, folder structure.
- Open five files from different parts of it, including different file types.
What this catches beyond level 1:
- Partial backups where some subfolders were silently skipped
- Path length or filename problems that caused specific files to fail
- Permission errors that blocked whole directories
- Exclusion rules that are broader than you intended
- Files that restore with corrupted contents rather than not at all
The file count comparison is the useful part. Backup software that skipped 300 files because of a filename issue will show a smaller count, and nothing else would have told you.
Restore something large enough to be inconvenient. A folder of ten files proves nothing about a backup of a hundred thousand.
Level 3: The disaster rehearsal
Do this once, when you set up a new system, and after any major change.
The question this answers: if your computer were destroyed tonight, could you actually get back to work — and how long would it take?
Rehearse it properly:
- Write down what you'd do, step by step, without looking anything up. If you can't, that's the finding.
- Restore to a different machine — a spare, an old laptop, a borrowed one — or to a wiped partition. Restoring onto the machine that's already working proves less than you'd think.
- Time it. Full restores take hours. Knowing whether it's four hours or two days changes what you plan around.
- Check what's missing. After the restore, work for an hour. Note everything you reach for that isn't there.
That last step is the whole value of level 3. The gaps are always the same categories:
- Application licences and activation keys
- Passwords, if your manager's vault was only on the dead machine
- Two-factor authenticator codes — this one strands people badly, because without them you can't get into the accounts you'd need
- Browser bookmarks, extensions, and saved sessions
- Application settings and customizations that took years to accumulate
- Fonts, plugins, and presets
- Cloud-only files never downloaded
- Email, if it lived only on a server
- Anything on a second drive that wasn't in the backup scope
Write the list. Fix the gaps. That's the deliverable.
The specific things worth testing individually
Some data has its own restore path and needs its own test:
Phone backup. The real test is restoring to a device, which is disruptive. A lighter version: verify the last backup date, check what's included, and confirm your photos exist somewhere other than the phone. Do the full test when you next replace the phone — and if the restore fails then, you'll still have the old device.
Cloud backup service. Restore a file through their interface. Also check how a large restore works: some services ship a drive, some require a download that takes days, and some charge for it. Knowing which applies before you need it matters.
Website and business data. Restore the database to a staging environment. Website backups fail at a notably high rate, and a database backup that won't import is a common and expensive discovery.
Encrypted archives. Open them. Confirm the password works and that you have it somewhere other than the encrypted archive.
Off-site drive. When you swap it, plug it in and open a file. A drive that's been in a garage for six months may have suffered from temperature or humidity.
Build a test file trail
A small trick that makes future tests trivial:
Create a file called BACKUP-TEST.txt in your documents folder. Each time you test, add a line with the date:
2025-01-12 — restored OK, Time Machine, 2 min
2025-04-08 — restored OK, cloud backup, 6 min. Noted: video folder not included, FIXED
2025-07-15 — FAILED, drive not readable. Replaced drive, new backup started.Two benefits. When you restore this file in a future test, the dates tell you immediately how current the backup is — a restored copy showing only entries from 2023 means the backup stopped in 2023. And the log shows you the pattern of what keeps going wrong.
What to do when a test fails
Don't panic and don't delete anything.
- Try a different file. One corrupt file is different from a broken backup.
- Try a different backup set or date. Most systems keep multiple restore points.
- Check the drive's health with your system's disk utility.
- Check whether the source data still exists. If the original is fine, you have time.
- Start a fresh backup to a different drive immediately, before diagnosing. Getting a working copy is more urgent than understanding the failure.
- Then diagnose. Replace the drive if it's suspect — they're cheap relative to the problem.
If a backup fails a test, treat yourself as having no backup until you have one that passes.
The schedule
- Quarterly: level 1. Restore one file. Five minutes.
- Annually: level 2. Restore a folder, compare, open several files.
- Once, and after major changes: level 3. Full rehearsal, write the gap list.
- Monthly: just check that backups are still running and the last success date is recent.
Put these in your calendar. The monthly status check is the one that catches most problems, because the most common failure is simply that the backup stopped and nobody noticed.
Why this is the highest-value item in the category
Everything else in backup — choosing drives, configuring software, following 3-2-1 — is investment. Testing is the only thing that tells you whether the investment worked.
And the failure rate is high enough that this matters. Plenty of people discover, at the worst possible moment, that the thing they've been relying on for years was never working. Five minutes, four times a year, is what stands between you and that.
Next in this series: Backup vs Archive vs Sync: Know the Difference