"We have a backup" is one of the most common things we hear - right before we discover the backup hasn't actually worked in three months, or the data restores but the application won't start, or the recovery takes 48 hours when the business needed to be back online in two.
A backup you've never tested is a guess. This guide walks through how Perth businesses should approach backup testing, what to check, and how often to do it.
Why backups fail silently
Backup jobs fail for lots of reasons that generate no alarm:
- The destination drive filled up and new data stopped being written
- A software update broke the backup agent
- A file was locked open during the backup window and skipped
- Credentials for a cloud backup expired
- A database was backed up but not in a consistent state - it restores as corrupt
In every case, the backup job log shows green. Everything looks fine until you actually try to restore.
Three types of backup tests
1. File restore test
The quickest and simplest. Pick a handful of files at random - a Word document, a spreadsheet, a PDF - and restore them to a test folder. Confirm they open and look correct. This takes 15 minutes and should be done monthly.
It doesn't tell you if your entire server is recoverable, but it confirms the backup is running and data is accessible.
2. Full system restore test
A full recovery of a server or workstation into an isolated virtual environment. You bring the machine up, log in, confirm all services start, check that the database opens, and verify that the system would actually function if it were live.
This is the test that catches the scenarios file restores miss - corrupt OS images, application licensing issues, missing dependencies. It should be done quarterly for any business-critical server.
3. Disaster recovery scenario test
A full walkthrough of your disaster recovery plan as if the incident actually happened. Who calls who? How long does the restore take? What's the order of priority - which systems come back online first? Who handles communication to staff and clients?
This is a broader exercise that goes beyond the backup itself. It's recommended annually for businesses where downtime has a serious financial or reputational cost.
What to document after each test
Every restore test should produce a short record that includes:
- Date and time of the test
- What was restored (specific files, a server, a mailbox)
- The restore point used (e.g. "backup from Tuesday 6am")
- How long the restore took
- Whether the restored data was usable and complete
- Any issues found and what was done about them
This documentation matters for cyber insurance claims, compliance requirements, and your own confidence that recovery will work when you need it.
What good backup testing reveals
Every time we run structured backup tests with a new client, we find something. Common findings:
- Backup jobs running but not covering a key server or application that was added after setup
- Restores that work but take 6+ hours - unacceptable for a business that needs to be back in 2
- Backups running only once per day when the business generates many hours of unbacked transactions
- Cloud backup credentials expired 6 weeks ago; data has been backing up locally only
- SQL databases backed up at file level only - restoring successfully produces an unusable corrupt file
How often should Perth businesses test their backups?
| Test type | Recommended frequency |
|---|---|
| File restore test | Monthly |
| Full system restore test | Quarterly (per critical system) |
| DR scenario exercise | Annually |
If you have a managed IT provider, backup testing should be part of your monthly reporting - not something you have to ask for.
What to do if you've never tested your backup
Start with a file restore test today. Pick five random files from your most important shared drive and ask your IT team or provider to restore them to a test location. See how long it takes, whether the files are intact, and whether anyone on your team actually knows how to run it.
That single test will tell you more about your backup reliability than any number of green status emails.
Frequently Asked Questions
How often should a business test its backups?
At minimum, run a file restore test monthly and a full system restore test quarterly. If your business relies heavily on a specific server or application, test that system's restore more frequently.
What's the difference between a backup test and a restore test?
A backup test confirms data was written to the backup destination. A restore test confirms you can actually recover usable data from it. You need both, a successful backup job does not guarantee a successful restore.
Does testing a restore affect my live systems?
A well-run restore test should not affect live systems. File-level restores can go to a test folder, and full system restores can be done in an isolated virtual environment. Your IT provider should handle this without any production disruption.
What should be documented after a backup restore test?
A short record of the date, what was restored, which backup point was used, how long the restore took, and whether the data came back complete and usable. This documentation matters for cyber insurance claims and gives you real evidence recovery will work, not just a green status email.
When did you last test your backup?
We run structured backup testing for Perth businesses and give you a plain-English report on what's working, what's not, and what your real recovery time looks like.
Book a backup review →For related reading, see our guides to Microsoft 365 Backup - What's Actually Covered (and What Isn't) and Running an Incident Response Drill: Stress-Test Your Team First.