A friend called me at 11pm two winters ago because his Synology had eaten a shared folder full of family photos. He had Hyper Backup running nightly for three years. Three years of green checkmarks.
The restore failed. The backup task had silently switched to a full-but-empty state after a drive swap, and nobody ever checked.
That night is why I test restores on a schedule now, and why I nag everyone I help to do the same. A backup job that reports success is telling you it finished writing, not that the data can come back. Those are very different claims.
Why a green checkmark lies to you
Backup software checks whether it copied bytes without an error. It almost never checks whether those bytes reassemble into a working file. Corruption in the destination, a broken chain of incremental snapshots, or a wrong encryption key can all sit undetected for months.
The only honest test is a real restore. You pull data out, open it, and confirm it is the thing you expected. Everything else is guesswork wearing a nice progress bar.
Step 1: Restore a handful of individual files
Start small. Pick three or four files you know well: a specific PDF, a photo from a known date, a spreadsheet you edited last week. Mixing file types matters because a corrupt backup sometimes ruins one format and not another.
Open your backup tool, browse into the most recent recovery point, and restore those files to a fresh folder like D:restore-test or a spare folder on the NAS called restore_check.
Then actually open each one. Look at the photo. Scroll the PDF. Open the spreadsheet and check that a formula still calculates. On my Synology this takes about four minutes start to finish, and it catches the most common failure: an incremental chain that no longer stitches together.
- Choose 3-4 files across different formats and dates.
- Restore them to a brand new folder, not the original path.
- Open every single one and confirm the contents look right.
- Delete the test folder when you are done.
Step 2: Restore a whole share and check the size
Individual files prove the plumbing works. A full share restore proves the backup is complete, which is a different worry entirely.
Pick a smaller share first, maybe your Documents folder rather than the 4TB Plex library. Restore the entire thing to an empty folder, then compare the restored size and file count against the source.
I keep a note of the expected numbers. If my Documents share is usually around 42,000 files and 61GB, and the restore comes back with 38,000 files, something got skipped. That gap is the whole reason to do this.
For a NAS, most of us run this restore over the network, so budget time accordingly. A 60GB share over gigabit Ethernet takes roughly 10-15 minutes at real-world speeds of 90-110 MB/s. Do it while you make coffee.
Step 3: Restore a Docker volume and start the container
This is the step people skip, and it burns them the hardest. A running container holds live state: a database, config, uploaded files. Backing up the folder while the container writes to it can produce a snapshot that looks fine and restores into a broken database.
The safe pattern is to stop the container, back up its volume, and only then trust it. To test the restore, spin the whole thing up from the restored data in isolation.
- Restore the volume folder to a test path, for example /volume1/docker/test-restore/vaultwarden.
- Copy your compose file and point the volume mount at that test path.
- Change the host port so it does not clash with the live service, say 8081 instead of 8080.
- Run docker compose up and watch the logs.
If the app loads and your data is there, that backup is genuinely good. When I did this for a Vaultwarden instance, the container threw database disk image is malformed on first boot, which told me my backup was grabbing the SQLite file mid-write. I fixed it by scripting a stop, backup, start sequence instead.
How often should you actually do this
You do not need to test everything every week. Match the effort to how much the data would hurt to lose.
| What to test | How often | Roughly how long |
|---|---|---|
| A few individual files | Monthly | 5 minutes |
| One full share | Quarterly | 15-30 minutes |
| Docker volumes and databases | Quarterly, and after any config change | 20-40 minutes |
| Full disaster recovery drill | Once a year | Half a day |
Put it on the calendar as a recurring event. The single biggest predictor of whether someone's backups work is whether they have a reminder that forces them to look.
The 3-2-1 rule only counts if the copies restore
Most guides tell you to keep three copies of your data, on two different media, with one offsite. That advice is solid, and Backblaze has a good plain-English write-up of it. The catch is that people count copies they have never verified.
An offsite copy in Backblaze B2 or a rotated USB drive at a relative's house only helps if you have actually pulled data back from it at least once. Test the offsite copy too, even if it is slow. You can read more about the origins of that rule in Backblaze's guide to the 3-2-1 backup strategy.
Common failures a restore test catches
- Broken incremental chain: one missing snapshot makes everything after it unrecoverable.
- Wrong or lost encryption key: encrypted backups are useless without the key, and you find out at the worst possible moment.
- Excluded folders: a filter set months ago silently drops your most important directory.
- Live database corruption: volumes copied mid-write that restore into a mangled state.
- Destination bit rot: the backup drive itself develops read errors over time.
Every one of these looks like a passing backup right up until you try to restore. That is the whole point.
Keep a short restore log
Write down the date, what you restored, and whether it opened cleanly. Three lines in a text file is plenty. When you upgrade your NAS or swap a drive two years from now, that log tells you the last time your safety net was proven, not assumed.
My own log is a boring plain-text file with entries like 2026-06-14, restored Documents share, 61GB, 42,109 files, all opened fine. Boring is exactly what you want from a backup.
Run the file test this weekend. It takes five minutes, and it is the cheapest peace of mind you will buy all year.
Frequently asked questions
How often should I test my backup restores?
Test a few individual files monthly, a full share quarterly, and any Docker volumes or databases quarterly plus after any config change. Run one full disaster recovery drill once a year. Setting a recurring calendar reminder is the single best way to make sure it actually happens.
Do I really need to test restores if my backup software says success?
Yes. A success message means the software finished copying bytes without an error, not that those bytes reassemble into working files. Corruption, broken incremental chains, and wrong encryption keys all pass the backup check but fail the restore. The only honest test is pulling data back out and opening it.
Where should I restore test data to?
Always restore to a brand new, empty folder such as a spare directory on the NAS or a folder like D:restore-test on your PC. Never restore on top of your live files, because a flawed test could overwrite the very data you are trying to protect. Delete the test folder once you have confirmed the files open correctly.
Why did my Docker volume backup restore into a broken database?
File-level backups of a running container often copy the database while it is being written, producing a snapshot that looks complete but is internally inconsistent. You typically see errors like 'database disk image is malformed' on first boot. Fix it by stopping the container before backup, or by using a proper dump such as pg_dump or mysqldump into a file that you then back up.
How do I know if a full share restored completely?
Compare the restored folder's file count and total size against the source. On Windows use the Properties dialog on both folders; on a NAS shell use find /path -type f | wc -l. If the numbers do not match, some files were skipped, often because of an exclusion filter set months earlier.
Should I bother testing my offsite backup copy?
Absolutely, even though it is slower. An offsite copy in something like Backblaze B2 or a USB drive at a relative's house only counts if you have actually restored from it at least once. Untested offsite copies are the most common false sense of security in a 3-2-1 setup.
