3 September 2026LANTEK Computers
Nearly every business we speak to has backups. A much smaller number have ever restored from them. The gap between those two sentences is where most of the bad days live.
This is not a criticism of anybody. A restore test takes deliberate effort, it produces no visible benefit when it succeeds, and there is always something more urgent. But a backup nobody has restored from is not yet a control. It is an intention with a schedule attached.
What a green tick actually confirms
A successful backup job means the software read the files it was told to read and wrote them where it was told to write them, without erroring.
That is genuinely useful and it is not nothing. Here is what it does not confirm.
That the right things are in scope. A job that has been running successfully for two years is backing up what it was configured to back up in that year. The database that moved to a new server, the folder somebody created for a new department, the machine that replaced the old one: none of those are included unless somebody added them. This is the most common finding of all, and the failure mode is silent, because the job still succeeds.
That the data is usable. A file copied while it was being written to may be captured mid transaction. This matters most for exactly the things you least want to lose: accounting data, databases, anything multi user. The copy exists and it is intact as a file. It may not open.
That anybody knows how to restore it. If the person who configured it has left, or the process is documented nowhere, the restore itself becomes a research project conducted under pressure.
How long it would take. Almost always longer than people assume. Downloading a large amount of data over a business internet connection has a floor set by physics, and that floor is often measured in days rather than hours.
That the backup would survive the event. If it is reachable from the same network with the same credentials, then whatever encrypted your files can encrypt it too.
The test, and it fits in a morning
You do not need a disaster recovery exercise to get most of the value. Do this once a quarter.
One. Pick something real and somewhat awkward. Not a text file you created yesterday. Something like a folder from three months ago that has since been changed, a mailbox belonging to somebody who has left, or a copy of the accounting data file. The point is to test the case you would actually face, not the easiest one.
Two. Have somebody else do it. Not the person who built it. If your provider normally handles backups, ask them to restore it while you watch, or better, ask whether one of your own people could follow the documentation. This is how you find out whether the process depends on one individual.
Three. Restore it somewhere separate. A different folder, a test machine, a spare mailbox. Never over the live copy. Restoring over production during a test is how a test becomes an incident.
Four. Open it. The step people skip. Open the document. Open the data file in the actual application. Read the messages in the mailbox. A restored file that will not open has failed the test while looking like a success.
Five. Time it, and write the time down. From asking to usable. This number is the only honest basis for any recovery expectation you set, and it is usually the most surprising output of the exercise.
Six. Write down what you did. Date, what was restored, from when, how long it took, who did it, what went wrong. One paragraph. This is your evidence that the control exists, and it is what somebody would ask for.
The awkward questions to ask while you are there
Since you have somebody’s attention on backups anyway.
Can the backup be deleted using credentials from our normal network? If yes, that is the priority fix. A backup that a compromised administrator account can destroy is not a backup against the thing most likely to destroy your data. What you are looking for is either separate credentials or storage that cannot be altered for a set period.
Is there a copy that is not in this building? Fire, flood and theft are unfashionable risks that have not gone away.
What is the oldest restore point we have? This matters because problems are not always discovered promptly. If your retention is short, something deleted or corrupted months ago is already gone. Applies particularly to Microsoft 365.
What is not backed up, deliberately? There will be things, and that can be perfectly reasonable. The problem is when nobody knows which things.
What to do when the test fails
Expect it to, the first time. In our experience a first restore test finds something in a clear majority of cases, and that is exactly why it is worth doing.
Common outcomes, and none of them are disasters if found now: something important is not in scope, the retention is shorter than anybody thought, the restore works but takes far longer than the business would tolerate, the documentation is out of date, or the only person who could do it has left.
Each of those is a manageable piece of work on a Tuesday. Each of them is a serious problem discovered at the moment you need the backup.
Where this connects to the bigger question
A restore test proves the data comes back. It does not prove the business can operate while that is happening, which is a different and larger question about recovery order, dependencies and how long you can be down. That distinction is the subject of backup is not the same as disaster recovery, and the two numbers that frame it are in RPO and RTO in plain English.
Start with the restore test though. It is smaller, it can be done this quarter, and it is the thing most likely to change what you believe about your own position.
What we cover is on Backup and Disaster Recovery. If nobody can tell you when the last restore test was, that is the answer, and it is worth a conversation.