The Backup You Haven’t Tested Is a Guess
Most organizations believe they are backed up. That belief holds right up until the moment they need to restore — and then, too often, it does not.
We see this pattern in nearly every foundation-layer audit we run. The backup jobs exist. The nightly confirmation emails arrive. Everyone assumes the safety net is there. And then a ransomware event or a failed server puts the assumption to the test, and the restore takes six times longer than anyone expected, or recovers the data but not the configuration, or fails on the one system that mattered most.
A backup you have not tested is not a control. It is an assumption wearing the costume of a control.
The difference between having backups and being able to recover
These sound like the same thing. They are not.
Having backups means jobs are running and data is being copied somewhere. Being able to recover means you have proven, recently and specifically, that you can turn those copies back into working systems inside a timeframe your business can survive. The gap between the two is where recovery plans quietly fail.
A backup job reporting success tells you the copy was made. It tells you nothing about whether the copy is complete, whether it is free of the same ransomware that may already be dormant in your environment, or whether restoring it produces a usable system rather than a pile of files with no way to run them.
Three principles of a backup you can actually trust
The 3-2-1 rule. The durable standard is three copies of your data, on two different types of media, with one copy kept off-site. The logic is simple: no single failure — a dead drive, a site fire, a spreading infection — should be able to reach every copy at once. Many small environments have three copies in name but all reachable from the same place, which defeats the purpose.
Immutable copies. An immutable backup cannot be altered or deleted for a defined period, even by an administrator account. This matters enormously against ransomware, because modern ransomware actively hunts for and destroys backups before triggering encryption. If your backups can be deleted by the same credentials the attacker just stole, they are not a recovery plan. Immutability puts at least one copy beyond the attacker’s reach.
Off-domain access. If your backup system authenticates with the same domain credentials as your production environment, a compromise of that environment can reach the backups too. Keeping backup access separate — off-domain — means the keys to production are not also the keys to your last line of defense.
A backup you haven’t tested is an assumption. And an assumption is not something you want to discover the truth about during a ransomware incident.
— Steve Vogler, Founder & CEO
The test most organizations skip
Here is the uncomfortable part. Almost every organization can tell you their backups are running. Very few can tell you the last time someone performed a full restore and timed it.
That test — restoring a real system, from a real backup, and confirming it works — is the only thing that turns a backup from a hope into a control. It answers the questions that matter: How long did it actually take? Was the data complete? Did the restored system function, or did it need hours of additional work to become usable?
A quarterly discipline anyone can adopt
You do not need to test everything at once. Pick one system this quarter — not the most critical, not the least, just a representative business system. Ask your IT team or MSP to perform a full restore in a lab environment and document three things: the time it took, whether the data was complete, and whether the restored system was actually usable.
Then do it again next quarter with a different system. And the quarter after that. Within a year, you will have real, tested knowledge of your recovery capability across your environment — which is a fundamentally different thing from having backup jobs that finish overnight.
This discipline also produces a quiet secondary benefit. The documentation you generate — tested restore times, confirmed recovery points — is exactly the evidence cyber insurance carriers now ask for at renewal. You will be building your insurance case and your operational confidence at the same time.
Ask your current MSP:
- When was our last documented full restore test, and which system did it cover?
- What is our actual recovery time — the tested reality, not the target?
- Are any of our backups immutable and kept off-domain, or could ransomware reach them?
The businesses that recover cleanly from a serious incident are almost never the ones that got lucky. They are the ones that tested. They treated recovery as a discipline to be proven rather than a product to be purchased, and when the bad day came, their backups did what backups are supposed to do.
Test the assumption before the incident tests it for you.
The Calysto Group is a veteran-owned, woman-owned, cybersecurity-first managed IT firm serving businesses across Michigan from offices in Saint Clair and Troy. If it has been more than a quarter since your last restore test, that is a good place to start a conversation.
