Proof of Life: The 30-Minute Restore Test That Tells You Whether Your Backup Is Real

Every small business in the country has a backup. Ask for evidence that it works and the room goes quiet.

Nobody's lying. It's just that the backup has joined that category of office things — the fire extinguisher on the wall, the first aid kit in the kitchen, the defibrillator in reception — that everyone is pleased to own and nobody has ever actually used. The dashboard says success. The invoice gets paid. Everyone moves on with their day.

Except a backup you've never restored isn't a backup. It's a hope with a monthly direct debit attached.

What the green tick is actually telling you

When your backup console flashes up a cheerful confirmation, it's reporting one very narrow fact: the job ran. Files were copied from A to B. Nothing about whether those files are readable, complete, or useful in a crisis.

It's the difference between posting a parcel and knowing it arrived intact. The tracking number proves you handed something over. It doesn't prove what's in the box.

I've seen firms with five years of immaculate backup logs discover — at the worst possible moment — that the encryption key lived in the head of an IT contractor who'd moved to Australia, that the "backup" was a second folder on the same server, or that the restore of a 400GB file share takes eleven hours rather than the twenty minutes everyone had assumed.

None of those are exotic failures. They're the standard ones. Which is exactly why the test is worth doing.

Why this matters a bit more in 2026

Two things have shifted for UK SMEs. First, ransomware crews stopped simply encrypting data and started stealing it first, so "we'll just restore from backup" no longer ends the conversation — you still have a breach to assess and, potentially, a 72-hour reporting clock to the ICO ticking while you work out what's gone.

Second, the people asking about backups have multiplied. Cyber insurers want to know when you last tested a restore. Cyber Essentials assessors are increasingly interested in evidence rather than assertion. Larger clients putting you through supplier due diligence ask the same question in their own language.

"We back up nightly" is an answer. "We restored a finance folder to a test machine on 14 October 2026 and it took 47 minutes" is a much better one.

The drill: three things, once a quarter

Block out half an hour. Put it in the calendar as a recurring event so it doesn't quietly vanish. Then pick three items.

One file

Choose a single document at random — ideally something you'd genuinely miss, like a signed contract or the latest payroll spreadsheet. Restore just that file. It sounds trivial, and that's the point: you're checking the plumbing works before you need to drain the whole system.

One folder

Next, a shared folder with real structure inside it — the finance drive, a client project folder, your HR records. Restore it somewhere harmless and open a handful of files. Do the permissions come back? Are the subfolders intact? Do the dates look sane, or has everything arrived with the timestamp of the restore?

One critical system

This is the one people skip. Your accounts package. The line-of-business application. The database behind your booking system. Whatever it is that would stop the business dead if it disappeared for a day.

You're not aiming for a full production rebuild here. You're aiming to find out whether the backup of that system is even usable — whether the application data can be attached, whether the config files are included, whether anyone knows the sequence.

Restore onto something disposable

A hard rule: do not test a restore over live data. Use a spare laptop, a virtual machine, or an isolated machine that isn't on the main network. This matters for two reasons — you don't want to overwrite something real by accident, and if you're restoring from a backup taken before a compromise was discovered, you really don't want to reintroduce anything nasty to the estate.

Keep a notebook or a shared document open while you work. Note the start time, the finish time, and every point where you had to stop and hunt for something.

The five things that usually break

In no particular order, here's where these drills tend to fall over:

• The keys. The backup is encrypted, which is good, and the password is stored in a filing cabinet nobody has opened since 2021, which is not.
• The gaps. The server was covered. The Microsoft 365 mailboxes, the shared cloud drive, the phone system configuration and the website weren't — and nobody had noticed.
• The clock. The restore took nine hours. That's your real recovery time, not the figure in your head, and it changes what you'd do on a Monday morning.
• The location. The backup drive sat on a shelf next to the server it was protecting, on the same domain, with the same admin credentials. One intruder, both copies gone.
• The staleness. The last good version was three days old because a job had been failing quietly since Thursday and the alert went to an inbox nobody reads.

Any of those is a useful discovery. All of them are cheaper to find on a quiet Tuesday than at 6am on the morning of an incident.

Turn it into one page

After the drill, write a single page with five columns: what we tested, how long it took, who did it, what went wrong, and what we're changing. Keep it somewhere the whole leadership team can see it. Update it next quarter rather than starting from scratch.

That page does three jobs at once. It's your evidence for insurers and assessors, your instruction manual for the person who has to do it under pressure, and your early warning system for the kit that's quietly stopped working.

Start smaller than you think

If a full drill feels like a lot, do the smallest possible version this week: pick one file, restore it somewhere safe, and time it. Thirty minutes, one person, no budget.

You'll either end up mildly bored — which is the ideal outcome — or you'll find something that would have hurt badly later. Either way, you'll know. And knowing is rather the whole point.