A backup you have never restored is not a backup. It is a hypothesis. The job ran, the dashboard is green, the retention policy looks sensible. None of that is evidence that you can get your business back. The only evidence is a restore you have actually performed.
This is the least glamorous part of managed IT. It is also the control that organisations are most confident about and least able to demonstrate, which is a bad combination.
”The job succeeded” is not evidence
A backup job reports on its own execution. It tells you that a process started, read some bytes, wrote them somewhere, and exited without an error code. That is a useful signal, and it is the signal almost every organisation monitors.
What it does not tell you is whether those bytes are a complete, coherent, restorable copy of a working system. A job can succeed while silently excluding a directory that somebody added six months ago. It can succeed while writing to a destination that is full in a way the agent never surfaces. It can succeed while capturing a database mid-write, producing a file that restores into a state the application will not start against.
Monitoring the job tells you nothing about any of that. You have to attempt the restore.
So: when did you last restore from a backup to prove it works, rather than confirm it ran? Our Essential Eight checklist poses that question in one line. This article is the long answer.
What actually breaks
These are the failure modes we see repeatedly. None of them are exotic, and all of them stay invisible until somebody attempts a restore.
The encryption key was only on the machine that died. Encrypting backups at rest is correct. Storing the key exclusively on the system being backed up turns a recoverable incident into an unrecoverable one, because the moment you need the backup is the moment the key is gone. The same trap catches encrypted databases and filesystems: the data volume is dutifully copied every night, and the key that decrypts it is not in the backup set at all. Anything encrypted needs its key held separately, tested, and written down somewhere that survives the loss of the primary system.
The backup captured the data but not the system. A database dump is not a mail server. A file-level copy of a web root is not a website. Restoring a working service usually needs configuration, certificates, cron jobs, firewall rules, service definitions and database permissions, and those things commonly live outside whatever directory the backup was originally pointed at. A data-only dump that omits user grants restores cleanly and then refuses every connection, which is a miserable thing to debug under pressure.
The backups were reachable from the thing that got compromised. If ransomware can reach and rewrite the backup share using credentials found on the infected machine, you have one copy of your data in two places rather than two copies. Backups need to be offline, immutable, or held in an account whose credentials do not exist on the production system.
The restore works and takes four days. This one surprises people most, because nothing is broken. Restoring several terabytes over a domestic upload link, or rehydrating from cold archival storage with a retrieval delay, can be technically flawless and commercially useless. If your business cannot survive four days offline, a four-day restore is a failed restore. Better to learn that now than during the outage.
Nobody has done it before, and there is no procedure. The first restore should not be performed for the first time during an incident, at 2am, by whoever happens to be awake, with a customer on the phone. Recovery involves decisions. Which snapshot? Restore in place or onto new hardware? What happens to the data written since the last good backup? Those decisions get much worse when made on adrenaline with nothing written down.
Where the 3-2-1 rule stops helping
Three copies, two media types, one offsite. It is a sound baseline and worth meeting.
It is also purely a rule about storage. It says nothing about whether any of the three copies can be restored, how long a restore takes, whether the encryption keys are available, or whether the copies contain enough to rebuild a working service. An organisation can satisfy 3-2-1 completely and still be unable to recover.
Treat it as the shape of your storage, then test recovery separately.
How to actually test a restore
A test has to produce evidence. That means restoring somewhere real and confirming the result works, not confirming that a restore process started.
- Pick the system that would hurt most. Not the easiest one. If losing it would stop you invoicing or stop you serving customers, that is where the test belongs.
- Restore to separate hardware or an isolated VM, never over the top of production. A test that risks the live system will keep being postponed, and a test everyone is afraid to run is not a control.
- Restore from the backup alone. No copying a config file off the running server, no grabbing the certificate from production because it is right there. The moment you reach across to the live system, you have stopped testing recovery and started testing your ability to improvise while the original still exists.
- Start the service and use it. Log in. Send a message. Run a report. Query the database as the application user rather than as an administrator, because permission gaps hide behind admin credentials.
- Time it, end to end. From “we decide to restore” to “the service is usable.” That number, not the figure on your backup vendor’s datasheet, is your actual recovery time.
- Write down what was missing. There is almost always something. The list is the point of the exercise.
- Fix the gaps and record the procedure, in enough detail that a competent engineer who was not there could follow it.
How often
Once a year for a full restore of your most critical system. Once a quarter for partial restores, which in practice means a single mailbox, file or table, and which is by far the most common real request anyway.
Then test again after anything structural changes: a database version upgrade, a server migration, a new backup product, a change to what is included in the backup set. Backups tend to fail quietly after the environment moves and the backup configuration does not.
What to record
Keep a short, boring log. For each test: the date, who ran it, which system, which snapshot, the end-to-end restore time, whether the service actually worked afterwards, and what was missing. Half a page is plenty.
That log is what turns “we have backups” into something you can show an auditor or an insurer. More usefully, it is what tells you next year whether your recovery time is improving or quietly getting worse.
Where this fits
Backups are one of the eight controls in the ASD’s Essential Eight, and the framework is specific that restoration must be tested rather than assumed. If you are working through it, the Essential Eight checklist covers the other seven in the same plain terms, and our Essential Eight readiness page explains how the maturity levels apply to a small Australian business.
We run backups with verified restores as part of managed services, which means monitoring the jobs, testing the restores on a schedule, and keeping the recovery procedure current as the environment changes. If you would rather do it in-house, the procedure above is the whole method. The only step you cannot skip is performing the restore.