How often should backups be tested?
Quarterly, at minimum — the cadence we hold every backup under our care to. Test sooner after anything that changes what is backed up or how: a new server, a new system, a move to the cloud. That is when a backup quietly stops covering what it used to.
The Australian Cyber Security Centre’s guidance on regular backups says the same thing in its own words: regularly test that your backups can restore your important data, software and configuration settings.
Why is testing backups important?
Because a backup that has never been restored is an assumption. Backups fail silently: a job that stopped months ago, a drive that filled up, credentials that expired, a system added after the backup was set up and never included. None of it shows until the day you need the restore.
A snapshot nobody has pulled back is a rumour with a filename.
How do you test a backup?
The same six steps, every time:
- Choose a backup at random — not the latest, and not the one that worked last time
- Restore it somewhere safe: a separate machine, folder or environment, never over live data
- Open what came back — documents, a database, a mailbox, a whole system if that is what is backed up
- Check it against the source: file counts, sizes, a sample of records, and the date it claims to be from
- Time it, from the decision to restore to a working result
- Write down the result, and fix what failed before the next test
Pick the backup at random
If you choose the backup, you will choose one you expect to work. A random pick tests the whole arrangement — older snapshots, other machines, the retention you believe you have.
Over a year of quarterly tests, four random picks cover far more ground than four restores of last night’s copy.
How do you know a restore worked?
When the restored data can be used, not when the software says the job completed. For files, open a sample and compare them with the originals. For a database or an application, start it and use it: sign in, run a report, find a recent record. For a whole server, boot it.
A green tick on a backup dashboard confirms something was copied. Only a restore confirms it can come back.
What is the 3-2-1 backup rule?
Three copies of your data, on two different types of storage, with one copy off site. It is a rule of thumb rather than a standard, and a good one: it survives a failed drive, a stolen laptop and a building you cannot get into.
It describes where the copies live, not whether they work. Testing is what tells you that.
Should backups live on a NAS, in the cloud, or both?
Usually both. A NAS on site restores quickly when the work is heavy and local; cloud storage keeps a copy out of the building and reachable from anywhere.
The line between them should be decided deliberately — by what has to come back quickly and what has to survive the office — rather than by whichever was easier to buy.
What a restore test should leave behind
A record: which backup was chosen and how, what was restored and where, whether it matched, how long it took, and what was fixed as a result. Kept over time, those records are the only honest answer to the question every business eventually asks — would we actually get it back?
It is also why restore testing belongs inside ongoing IT management rather than as an occasional project. In our IT & Digital Security practice, patching, monitoring and restore testing are the retainer, not extras.