CISA’s #StopRansomware Guide asks organizations to “regularly test the availability and integrity of backups in a disaster recovery scenario.” Plenty of small businesses never do, often for a fair reason: they worry the test itself will break something.
It will not, if you keep two rules. Never restore over the original. Never let a restored system talk to the live network. Everything else in this article is detail on top of those two.
Why a finished job proves little
Backup software reports that a job finished. That tells you data was copied. It does not tell you the copy opens, that it holds what you think it holds, or how long getting it back would take.
Common findings in a first real test include:
- a folder that was never selected for backup
- a database copied while it was open, which will not mount
- a server image that restores but will not boot on different hardware
- an encryption key that nobody can find
- a restore that works, but takes two days instead of two hours
None of these shows up as a failed job. They only show up when someone restores.
Sophos’s State of Ransomware 2025 found that “only 54% of companies used backups to restore their data,” the lowest share in six years. The survey covered 3,400 IT and cybersecurity leaders at organizations of 100 to 5,000 employees, and it does not say why the rest did not. Either way, a backup nobody has restored from is a weak thing to stake a recovery on.
Work up through four levels
Start small and add one level at a time. Each level proves something the one before it cannot.
- A single file. Proves the backup is readable and the restore tool works.
- A folder or a mailbox. Proves folder structure, permissions and mail items come back intact.
- An application’s data. Proves a database or app file opens in its own program, not just that it exists.
- A whole system. Proves you can rebuild a machine, and shows how long it takes.
Level 1 is where most informal testing stops. The serious surprises tend to live at levels 3 and 4.
Restoring files safely
For files, folders and mailboxes, the rule is simple: restore to a new place.
- Restore files to a new folder named with today’s date and “restore test.” Never choose overwrite, or restore to the original location.
- Restore a mailbox item to a separate folder, or to a test mailbox set up for the purpose.
- Pick something from at least a few weeks ago, not this morning. That tests retention as well as the copy.
- Open every restored file. A file that copies is not the same as a file that opens.
- Compare it with the original where you can: size, date and a quick look inside.
- Delete the test copy when you are done, so nobody works in it by mistake.
Restoring a whole system safely
Whole systems need more care. A restored server is a twin of the live one, with the same name, the same network address and the same scheduled tasks. Put it on the office network and it may clash with the original, or simply start doing its job: emailing invoices, pulling bank feeds, sending appointment reminders.
So a full-system test happens somewhere isolated:
- No route to the live network. Use a separate virtual network, or a cloud machine with outbound traffic blocked.
- No outbound email. Block mail at the network level, so scheduled reports and reminders cannot reach anyone.
- Keep directory servers apart. A restored copy of a domain controller must never meet the live one, or old changes can flow back.
- Log in and check the work. Boot it, sign in, open the main application and look at the newest records. Their date and time is your real recovery point.
- Shut it down and delete it. Test copies hold real data and should not linger.
Who should run the test
If you can, have someone other than the person who set up the backup run the test, working only from the written steps. That checks two things at once: the backup, and the instructions.
On the day of a real outage, the person who knows the system best may be on holiday, ill or gone. A test that only works when one particular person runs it from memory has found a gap, even if every file came back.
Time it, and write it down
A test that is not timed and written down is soon forgotten. Six months later nobody remembers whether it took 20 minutes or 6 hours.
For every test, record:
- what was restored, and from which backup date
- when the request was made, and when the data was usable
- who did it, and which steps they followed
- what failed or surprised you, and what you changed
The time that counts runs from the request to usable data, not the length of the progress bar. If it took an hour to find the right login, that hour counts. Compare the result with your recovery time (how long that system can be down); recovery point and recovery time, explained shows how to set it.
Example: a distributor’s quarterly test
Imagine a 60-person regional wholesale distributor with an ERP server, a file server, laptops and Microsoft 365. Its quarterly test might run like this:
- Monday, 10 a.m. Restore 25 files from a sample of shared folders, dated six weeks back, into a dated test folder. All of them open. Time to usable: 18 minutes.
- Monday, 11 a.m. Restore one manager’s mailbox, as it was at the end of last month, into a test mailbox. Every folder is present. Time: 40 minutes.
- Tuesday, 9 a.m. Boot last night’s ERP server image as a virtual machine on an isolated network. It starts in 50 minutes, but the ERP application refuses to open. Its license service checks in with the software vendor and cannot reach the internet.
- Tuesday afternoon. The team adds a step to the runbook (keep an offline license file on hand, or allow that one address outbound during a restore), retests, and the ERP opens with the previous evening’s orders on screen.
The test found a problem on a quiet Tuesday that would otherwise have surfaced in the middle of an outage. That is the whole point of the exercise.
How often to test
Quarterly suits most small businesses: often enough that results stay current, rare enough that each test is done properly. Test again after any big change, such as a new server, a new backup tool, a move to the cloud or a change of IT provider.
Rotate what you test, so that over a year every important system gets one full restore.
If you would rather not run this yourself, the Restore Drill plan does it each quarter. We restore a sample of files, one mailbox and one full system to an isolated environment, time each one, and send a written result within 3 business days. Anything that fails is fixed and re-tested the same quarter. The plan starts from $240 per quarter (indicative), and it is included free for clients with 3 or more servers on Server Backup.
It sits within our fast data recovery service, alongside written recovery runbooks and standby servers. What a restore drill report should show covers how to read the written result.
A restore test checklist
- Choose a sample: some files, one mailbox and one full system.
- Choose backup dates, including at least one from weeks ago.
- Prepare the targets: a dated folder, a test mailbox and an isolated network.
- Block outbound email and network routes for any restored system.
- Start the clock when you make the request.
- Restore, open and check every item.
- Note the newest record in each restored system.
- Stop the clock when the data is usable.
- Write down the results, the timings and anything that failed.
- Fix the failures, retest them, then delete the test copies.
Our 3-2-1 backup checklist covers where the copies should live. This checklist covers the proof. Keep both with your recovery runbook.
Watch one first
If you have never tested a restore and would rather watch one first, the free backup check includes one. It takes 45 minutes, remotely, and you get a written page of findings afterwards. Book a free backup check and bring a file you would like to see come back.
