One File, One Stopwatch: The Quarterly Restore Drill Nobody Sends You a Certificate For

The dashboard said green. It had said green for eleven months. Then a contracts manager needed a supplier agreement from March, and the restore took four hours, two phone calls to the managed service provider, and handed back the wrong version anyway.

Nobody was hacked. Nothing was lost for good. But for half a working day, that team genuinely did not know whether it could get its own files back — which is the exact thing a backup is meant to guarantee.

That is the case for the restore test. Not the backup report. The test.

A green tick proves almost nothing

Every backup product on the market will show you a reassuring tick. That tick means an agent ran and some data landed somewhere. It does not mean the data is readable, that it belongs to the right tenant, that you hold the keys to decrypt it, or that anyone on your team can find one file among millions before the client rings back.

Cloud backups hide the awkward parts especially well. Snapshots expire quietly. Retention settings get changed during a support call and never changed back. A leaver's mailbox stops being covered because nobody updated the licence count. The SaaS tool you bought in June has a 'version history' tab that everyone treats as a backup, even though nobody has ever restored from it.

An MSP contract makes it worse in a subtle way. The responsibility is real, but it sits in a different building. You are paying for a recovery capability you have never once measured, and the only people who know whether it works are the ones who are not you.

The drill itself: four steps, fifteen minutes

You do not need a project plan, a change advisory board or a consultant. You need one file, one clean machine, a stopwatch, and somebody honest writing down what happens.

Pick one business-critical file. Not a document called restore-test.docx. Something that would actually hurt: the live payroll spreadsheet, the master supplier list, the signed lease, this month's invoice run. Write the filename and the date down before you start.

Restore it to a clean device. Not the machine it came from, and not a folder sitting on the same server. Use a spare laptop, a test VM or a freshly wiped PC with nothing on it but a browser. If your only option is the original device, that is already a finding worth writing down.

Time it. Properly. Start the clock when the person who needs the file asks for it, not when the technician begins. Include the time spent finding the right backup set, waiting for a call back from the MSP, hunting for the encryption passphrase and explaining to the finance director why it is taking so long. Real recovery time is measured in how long the business waits, not how long the software takes.

Open the file. A restored file that will not open, or opens as a zero-byte ghost, is not a restore. Check it renders, check the date inside matches the date you asked for, and check that whoever requested it agrees it is the right document.

The five questions your backup provider hopes you skip

Once the file is back, ask these while the person who owns the contract is still on the phone.

• How long do you actually keep our data, and when did that last change?
• Who holds the encryption keys, and can we get the file back if your support desk is offline?
• What is the documented restore time for a single file versus a whole server? Are they the same promise?
• If we part ways, how do we get our data out, in what format, and how long does that take?
• Which of our systems are out of scope, and did anyone tell us?

You will get at least one sheepish answer. That answer is the whole point of the exercise.

Write it on one page, or it didn't happen

After the drill, fill in a single sheet: date, file tested, who requested it, who performed it, total elapsed time, what went wrong, what it will cost to fix, and who owns the fix. Keep the last four quarters in a folder.

That page does several quiet jobs at once. It gives you evidence for your cyber insurer if they ever ask how you validate backups. It shows an auditor you are doing more than ticking a box. And it turns a vague argument about budget into a specific sentence: the last restore took three hours because the retention window was set to seven days, and here is the invoice for fixing it.

What usually breaks

In small teams, the same handful of failures turn up again and again. The person who knew the admin password left in the spring. The backup covers the file server but not the shared mailbox. The retention window is shorter than the finance team's month-end run. The offsite copy exists, but it lives in the same cloud tenant as the thing it is protecting, so a compromised account takes both.

None of these are dramatic. All of them are cheaper to find on a quiet Tuesday in November than at 6pm on the day before a bank holiday.

Put it in the calendar and leave it alone

One file, once a quarter, same four steps, different person each time if you can manage it. Fifteen minutes of someone's afternoon, plus whatever it takes to fix the thing you find.

That is the whole programme. No certificate, no badge, no vendor webinar. Just the boring, repeatable proof that when someone asks for a file, you can hand it over.