Your backup tool says it ran. That's a statement about the tool, not about your files. The part that proves anything is the restore, and the good time to find out whether it works is while nothing is wrong.
This is for anyone whose work lives in files — documents, code, client projects, photos — and who has a backup they have never pulled a single thing out of. It takes one sitting.
The verdict
Restore three things today, into a new empty folder, and open each one in the app that made it:
- A file you deleted a while ago
- A whole folder, with its subfolders intact
- Something that came from a device you no longer use
If all three come back and open, you have a backup. If any of them stalls, you have a scheduled job that produces a green checkmark.
Restore to a new location rather than over the original. A restore that overwrites live files turns a test into an incident.
The three restores
| Restore this | What it proves |
|---|---|
| A file deleted months ago | Retention outlives your mistake |
| A whole folder, structure intact | Bulk recovery works, not just single files |
| A file from a device you no longer use | The copy outlived the machine |
The file you deleted a while ago
Single-file restores from yesterday are the easy case, and they're the case a backup tool is most likely to pass. The interesting question is retention: how far back the history goes, and whether deleted files stay recoverable or fall out of the window.
This matters because you often don't notice a loss on the day it happens. You notice when you go looking for something — a contract, an old draft, a config file — and it isn't there. Pick something you know you deleted, not something you deleted this morning.
The whole folder
Restoring one file and restoring a project directory are different operations, and some tools are noticeably better at one than the other. Check three things when it lands: the subfolder structure, the file count against what you expect, and whether files that live in pairs came back together — a design file and its linked assets, a database and its sidecar, a document and the images it references.
Nested folders, very long paths, and filenames with unusual characters are where this one tends to break.
The file from a device you no longer use
This is the test of whether your backup is a backup or a mirror. If your only copy of a file lived on a laptop you sold, and the backup was tied to that laptop's client, the file may have gone with it. The same goes for a phone you traded in or a work machine you handed back.
Try to retrieve something that predates your current hardware. If you can't, your recovery horizon is the age of the device on your desk.
How long each should take
There's no number to give you here, and anyone who quotes one is guessing: it depends on file size, connection speed, whether the archive has to be rehydrated from cold storage, and how the tool packages things. What you're testing is different.
Does it finish? Do you know where to click without reading documentation? Does the tool tell you what it's doing, or does it just sit there?
Time the restore while you run it and write the number down. That's your baseline. The next time you do this — and the time that counts is the time something has actually gone wrong — you'll know whether a slow restore is normal or a symptom.
Where restores fail
Sync that stopped syncing. A sync client can be paused, signed out, out of storage, or quietly excluding a folder, and the folder on your screen still looks exactly the same. Sync also propagates deletion: remove a file on one machine and it leaves the others too, which is the behavior you asked for and not a safety net. Check the service's own file list, not the folder icon on your desktop.
Corruption, faithfully preserved. Backup software copies what's there. If a file was already damaged — a truncated write, a failing drive, a database saved mid-transaction — the damage gets copied on schedule, and each run can push the last clean version further toward the edge of your retention window. This is why opening the restored file matters. A file that exists and has a plausible size can still be unreadable.
Archives nothing on hand can open. Some tools write proprietary or split archive formats that need the same tool, sometimes the same version, to unpack. Encrypted backups need the key, and a key stored only inside the tool you're trying to recover is a circular dependency. During your test, note what you needed to open the archive and where that thing lives. If the answer is "on the machine that died," fix it now.
The 3-2-1 rule — three copies, two kinds of media, one off-site — is about how many copies exist. It says nothing about whether any of them opens.
Who can skip this
If your work lives entirely inside a hosted service you'd be willing to lose, or you're working on something you could recreate from scratch without much pain, a restore test is more ceremony than it's worth. Same if everything you care about is already duplicated somewhere you actively use — you're restoring from it constantly without calling it that.
And if you'd rather not build a backup system at all: a plain copy of your working files onto an external drive you can plug into any computer is a weaker backup than a real tool, but it's one you can verify in a minute. A verified weak backup beats an unverified good one.
The next action
Open your backup tool and restore one file you deleted months ago into an empty folder. Then open it. Everything else in this article follows from what happens in the next few minutes.