Ask almost any business whether it has backups and the answer is yes. Ask when it last restored from one, in full, and watched the recovered system come back to life, and the room usually goes quiet. This is the gap that quietly undoes companies. Having a backup and being able to recover from it are two entirely different things, and the distance between them is only ever discovered at the worst possible moment: during a real failure, when the business is already down and the backup is supposed to be the thing that saves it. A backup you have never restored is not a backup. It is a hope, written to disk.
The reason this matters is that backups fail in ways that are invisible right up until you need them. A nightly job reports success for a year while quietly excluding a system that was added months ago. Files are written faithfully but turn out to be corrupted, or encrypted with a key nobody can now find. The data restores perfectly but the process takes four days, and the business could only survive one. None of these problems announce themselves. They sit silently inside a green tick on a dashboard, and they surface only when someone finally tries to restore and finds that the safety net has a hole in exactly the place they are falling.
A backup is a promise you have not checked
A backup job finishing successfully tells you that some data was copied somewhere. It does not tell you that the data is complete, that it is uncorrupted, that it includes the systems you would actually need, or that anyone knows how to turn it back into a running business. All of those are separate promises, and a successful backup checks none of them. Treating a completed backup job as proof of safety is like keeping a fire extinguisher for a decade without ever checking the pressure gauge, and assuming it will work because it is hanging on the wall. The object is present. Whether it functions is a different question, and one you do not want to ask for the first time during the fire.
Untested backups fail in quiet, specific ways
The failures are not mysterious; they are predictable, which is what makes not checking for them so avoidable. Scope drifts: a new server, database, or SaaS system gets added to the business but never added to the backup, so it is simply missing when you go looking. Integrity rots: backup files corrupt over time or during transfer, and a corrupted backup is indistinguishable from a good one until you try to open it. Knowledge evaporates: the restore depends on steps and credentials that lived in one person's head, and that person has left. And time betrays you: the restore works, but it takes far longer than the business can tolerate, because nobody ever measured how long recovering everything, in the right order, actually takes. Each of these is ordinary. Each is invisible until a restore. Each is found the hard way by companies that had backups the whole time.
The metric that matters is recovery time, not backup existence
Most organisations track whether backups are running. Very few track how long it would take to get back to working, which is the number that actually decides whether a disaster is an inconvenience or an extinction event. The useful questions are two: how much data can you afford to lose, and how long can you afford to be down. The first sets how often you must back up; the second sets how fast you must be able to restore. A business that can tolerate an hour of downtime and a business that can tolerate a week need completely different arrangements, and neither can know whether it meets its target without having actually restored and timed it. Owning backups is not the goal. Being able to recover inside a time you can survive is the goal, and that can only be proven, never assumed.
Ransomware turned this from prudent to urgent
There was a time when untested backups were a quiet risk you might get away with. Ransomware ended that. Modern attacks deliberately seek out and destroy or encrypt backups before they trigger, precisely because they know an organisation that can restore will not pay. This means backups are now both more essential and more actively targeted than ever, and the ability to recover cleanly is often the single thing standing between a bad week and a paid ransom. A business that has never tested its restore, and never confirmed its backups are isolated from the systems an attacker would reach, is making an expensive bet that it will never be attacked. That is not a bet the current environment rewards.
Test the restore, like a fire drill
The fix is not more backups; it is proving the ones you have. Treat recovery like a fire drill: on a fixed schedule, take a real backup, restore it to a separate environment, open the data, confirm it is complete and correct, and time how long the whole thing took. Do it for the systems the business genuinely cannot run without first. Write down the steps so recovery does not depend on one person, keep at least one backup copy isolated so an attacker or a bad change cannot reach it, and review each drill for what broke and what needs fixing. The point of the drill is to move the discovery of every hidden failure out of the real disaster and into a controlled test, where finding a problem is a good day rather than a catastrophe.
A worked example
A company came to us after a scare rather than a full disaster, which made them lucky. A server had failed, and when they went to restore it, the most recent backup they could actually open was six weeks old, even though the backup job had been reporting success every night. When we looked, the cause was mundane and entirely typical: a configuration change months earlier had quietly narrowed what the job captured, and because nobody ever tested a restore, nobody noticed. They had been running for weeks with backups that looked perfect and would have cost them six weeks of data in a real loss. We set up a regular restore test, timed it, and used the first few drills to fix the scope gap, document the recovery steps, and isolate a copy of the backups from the main environment. The backups themselves were barely changed. What changed was that the business now knew, from having done it, that it could actually recover, and roughly how long it would take. That knowledge is the entire point, and they had been missing it while believing they were covered.
Hope is not a recovery plan
It is comforting to see backup jobs succeed, and easy to treat that green tick as safety. But safety is not that a copy exists somewhere; it is that you can turn that copy back into a working business inside a time you can survive, and the only way to know you can is to have done it. The businesses that come through a serious data loss or a ransomware attack intact are not the ones with the most backups. They are the ones that treated recovery as something to be proven and practised, not assumed. Before the next crisis makes the decision for you, it is worth asking the uncomfortable question plainly: not do we have backups, but have we ever actually restored from them, and do we know how long it would take.
Making sure the data you are protecting can actually be recovered, on a timescale the business can survive and safely out of an attacker's reach, is part of what our cybersecurity and compliance work is built around: treating resilience as something you test, not something you hope for. Book a discovery call and we will help you find out whether your backups would actually save you.
Frequently asked questions
What does it mean to test a backup?
Testing a backup means actually restoring from it and confirming that the recovered data is complete, correct, and usable, rather than simply checking that a backup job ran and reported success. A backup job can finish without error and still produce something you cannot recover from, because the files are corrupted, the scope was incomplete, or nobody knows the steps and credentials needed to bring the data back. A real test takes a backup, restores it to a separate environment, opens the data, and verifies it works, ideally while timing how long the whole process takes. Until you have done that, you have confirmed only that a backup was written, not that it can save you.
Why do untested backups so often fail when they are needed?
Because a backup can fail silently in many ways that a successful job report will never reveal. The backup may have quietly stopped including a critical system months ago. The files may be corrupted or encrypted with a key nobody can find. The restore may depend on a person who has left or on steps nobody has written down. The recovery may technically work but take days when the business can only survive hours. None of these show up until the moment you actually try to restore, which is usually during a real crisis, and that is the worst possible time to discover that your safety net has a hole in it.
How often should you test your backups?
Often enough that a failure is found in a drill rather than in a disaster, and on a fixed schedule rather than whenever someone remembers. For most businesses that means a full restore test at least a few times a year, and more frequently for the systems the business cannot run without. The test should be treated like a fire drill: scheduled, run end to end, timed, and reviewed afterwards for what went wrong and what needs fixing. What matters is not the frequency number itself but the discipline of proving, on a regular basis, that you can actually recover, so that the first real restore is never also the first restore you have ever attempted.
What is the difference between having backups and being able to recover?
Having backups means copies of your data exist somewhere. Being able to recover means you can turn those copies back into a working business within a time you can survive. The gap between the two is where most disasters actually happen. Recovery depends on far more than the backup file: the restore process, the people who know it, the order systems must come back in, the dependencies between them, and the total time it all takes. A business with untested backups often has the data and still loses days or weeks it cannot afford, because nobody had ever proven the path from a backup to a running system. The goal is not to own backups; it is to be able to recover.