Backup restore testing for small business
When someone tells me "we have backups", my first question is always: when did you last restore one? Usually there's a pause. Backup restore testing is the one-hour habit that turns "we think we're covered" into "we restored everything in two hours last month".
Why backups fail silently
Backup jobs run at night. The email says "completed". Nobody opens it. Months pass. Then a server dies, a laptop is stolen, or ransomware encrypts the shared drive, and the restore fails. These are the failures a success email never shows:
- The wrong folder. A path changed months ago, so the job has been copying an empty folder ever since.
- The lost key. The backup is encrypted, which is good, but nobody saved the encryption key anywhere else.
- The slow restore. It works, but it takes three days over the office internet, not three hours.
- The same blast radius. The backup drive was plugged in and writable, so the ransomware encrypted it too.
- The missing piece. Files came back, but not the database, the email, or the settings that make the software run.
I have seen versions of every one of these in real systems. The only way to find them is backup restore testing: actually bringing data back and checking it works.
A monthly backup restore testing routine
Put a recurring hour in the calendar. Each month, rotate what you test so every important system gets a turn within a quarter.
- Pick a target. One shared folder, one mailbox, one database, or a whole server, in rotation.
- Restore to a safe place. A spare computer, a test virtual machine or a separate folder. Never over the live data.
- Time it. Note when you started and when the data was usable. That number is your real recovery time.
- Check the data, not just the files. Open five random documents, run a report from the restored database, log in to the restored app.
- Check the date. How old is the newest restored change? That is how much work you would lose.
- Write it down. One line in a log: date, what was tested, time taken, result, and anything to fix.
What to record each time
| Field | Example |
|---|---|
| Date and tester | 3 Nov · Sarah (office manager) |
| What was restored | Accounts shared folder, 14 GB |
| Restore source | Offsite copy, not the local drive |
| Time to usable | 1 h 40 min |
| Newest data in restore | Previous night, 11:00 pm |
| Result and follow-up | Pass · one folder excluded by mistake, fixed |
This log is also your evidence. Insurers and auditors increasingly ask "when did you last restore?", not "do you have backups?".
Regular backups and the Essential Eight
In Australia, regular backups are one of the eight strategies in the ASD's Essential Eight. At maturity level 1, backups are expected to be kept according to how critical the data is, protected so ordinary accounts can't change or delete them, and restores tested as part of disaster recovery exercises. A monthly routine and a written log cover that requirement. The Essential Eight checklist explains the other seven.
Ransomware recovery needs an immutable backup
Attackers go after backups first. If every copy is online and writable, they encrypt those too. For ransomware recovery you need at least one copy they cannot touch:
- The 3-2-1 backup rule: three copies of the data, on two different kinds of storage, with one copy offsite.
- One immutable backup: object storage with a retention lock, or a drive that is disconnected after each run, so nothing can delete or change it for a set number of days.
- Separate credentials: the backup system's password is not the same as any staff or admin password.
Test a restore from that protected copy at least once a quarter, because that is the one you will need on the worst day.
If you only take one thing from this post: put a recurring hour in your calendar called "restore something", and keep the log. It is the cheapest insurance a business can buy. For the bigger picture of how I set backups up, read the small business backup solution I'd build, or see how I do it for clients in backup and recovery.