Restore one file from your backup and prove it opens
“Success” is the most load-bearing word in your backup system, and almost nobody has tested what it means. It means the copy job finished. It doesn’t mean anything came back.
Those are two different claims and the green tick only makes the first one. A job can complete every night for two years while writing something that won’t open, or that’s missing the folder you actually care about, or that’s encrypted with a key nobody kept. None of that shows up in the log, because the log is reporting on the writing, not the reading.
The gap gets discovered in exactly one situation, which is the situation where you needed it. That’s a bad time to learn a new thing about your own systems.
So the fix is small and slightly boring. Take one file out. Open it. Once you’ve done that, you know something you currently only assume.
A backup is a claim. A restore is evidence.
Before you start
Twenty minutes. Access to wherever your backups actually live, which for a lot of people is the first small discovery of the exercise.
This works the same on a cloud drive’s version history, a managed backup service, or an external disk. The steps below stay deliberately provider-neutral, because the point is the drill rather than any one product’s menus.
Pick a file you’d actually miss
Not a test file. Not something you just made. Those prove the system can round-trip a thing it already has warm.
Pick something real and old enough to have been through a few backup cycles. Last year’s accounts. A client’s signed contract. The design source for something you shipped. The test is simple: if this vanished, would your week get worse?
Note where it lives now, and note what’s in it, because you’ll be checking that in step 4.
Find it in the backup, and note the date
Go into your backup and locate that specific file.
This step is the first place people get stuck, and getting stuck here is a finding. If you can’t work out how to browse what you have, you don’t have a recovery process, you have a payment going out monthly.
When you find it, look at the version date. Ask whether that’s recent enough to be useful. A backup running weekly means up to a week of work is gone in a real recovery, which may be completely fine. It should be a fact you know, not a number you discover afterwards.
Restore it somewhere else
Restore to a scratch folder. Never over the original.
mkdir -p ~/restore-test
This matters. Restoring over your live copy in the middle of a drill is how a test turns into an incident, and it’s an easy mistake because most tools offer to put it back where it came from as the default.
You want the restored copy sitting next to the real one, so you can compare them and then delete it.
Open it, and check it’s usable
This is the actual test and it’s the step people skip, because the file appearing in the folder feels like the answer.
Open it in the application that made it. A spreadsheet should open without a repair prompt and have its formulas. A design file should render its layers. A database dump should restore into a scratch database and answer a query. A PDF should show all its pages, not the first one and then an error.
Then check the contents against what you noted in step 1. A file that opens but is missing the last three months is a partial success, which is worth knowing about precisely because it looks like a full one.
Restored is not the same as readable, and readable is not the same as current. Three checks, not one.
Write down how long it took
Look at the clock. Write the number down.
That number is your real recovery time for one file, and it’s the only honest input you have for the bigger question. If a single document took twenty-five minutes because you had to find a login and work out the interface, then a bad morning involving forty files is not a morning, it’s a week.
Nobody can plan around a recovery time they’ve never measured. You now have one measurement, which is infinitely more than none.
Delete the copy and book the next one
Delete the scratch folder, so a stale duplicate doesn’t turn up in six months looking authoritative.
Then put the next drill in the calendar. Quarterly is a reasonable rhythm for a small operation, and attaching it to something you already do beats setting a reminder you’ll dismiss. Rotate which system you test, so over a year you’ve pulled a file from each of them at least once.
Write down what you tested, the date, and the time it took. Three lines. That file becomes the only real evidence you have that any of this works.
A boundary worth knowing about
One file proves the mechanism. It doesn’t prove the disaster.
Restoring a document tells you the system holds data and gives it back. It says nothing about whether you could rebuild a working environment: the machine, the software versions, the credentials, the settings, the pieces that live in somebody’s head. The full version of that is a bigger exercise and most small operations never do it, which is a reasonable trade as long as it’s a trade you know you’ve made.
The other edge, and it’s the one worth watching: most backups protect against loss, not against a change you didn’t want. A file quietly corrupted, or encrypted by something hostile, gets faithfully copied into the backup on the next run. If your retention only keeps recent versions, the good copy can age out before anyone notices the bad one. Knowing how far back you can actually reach is a separate question from whether a restore works, and it’s worth asking on the same afternoon.
If you have staff
The person who runs the drill shouldn’t be the person who set the system up. Someone who already knows where everything is will complete a restore that a colleague couldn’t, and the second case is the one that matters at 7am on a bad day.
Write it down where somebody else would find it. Which system, which login, which steps, how long. A recovery process living in one person’s memory is a single point of failure that no amount of redundant storage fixes.
The short version
- Pick a real file you’d miss, not a test file
- Find it in the backup and check the version date is recent enough to be useful
- Restore to a scratch folder, never over the original
- Open it. Check it opens, is readable, and is current
- Write down how long the whole thing took, because that’s your real recovery time
- Delete the copy, book the next drill, and note what you tested
Sources
This one is a drill rather than a tool, so there’s no vendor documentation to cite and the guide deliberately doesn’t name products. The evidence it produces is your own: the file that opened, and the number of minutes it took.
Written August 2026. Nothing here depends on a particular product or version, so it should age better than most of the library. The thing to re-check is your own retention window, which changes when your plan does.
Prints to PDF from your browser — colours and all.