August 5, 2026 · by David Gilbert · 3 min read · Cyber Security
A client once told me, with complete confidence, that their backups were solid — set up years earlier, running automatically, nothing to worry about. When I actually checked, the backup job had been silently failing for months, quietly producing empty or corrupted files while everyone involved believed everything was fine. This is one of the most common, most dangerous gaps I find in small business systems, and it's almost always discovered at the worst possible moment.
How a Backup Quietly Stops Working
Backup failures are rarely dramatic. A storage destination fills up and new backups silently stop landing. A login credential expires and nobody notices because the failure produces no visible symptom in daily operations — nothing breaks, nothing changes, work continues completely normally right up until the day you actually need the backup and discover it isn't there. The system that's supposed to protect you against disaster fails in a way that itself causes zero disaster on its own, which is exactly why nobody catches it in time.
Why "It's Running" Isn't the Same as "It's Working"
A backup job can run successfully, on schedule, exactly as configured, and still produce a file that's empty, corrupted, or missing the specific data you'd actually need to recover. Confirming a backup exists and confirming a backup is genuinely usable are two completely different checks, and most people, entirely reasonably, only ever do the first one — because the second one requires actually trying to restore something, which feels like unnecessary extra effort until the day it very much isn't.
The Test Everyone Skips
The only way to actually know a backup will save you is to test a real restore from it, occasionally, deliberately. Not constantly — that's overkill for most small businesses — but periodically, on a real but unimportant file, confirming the whole chain genuinely works end to end rather than just trusting that "it's been running for years without complaint" means anything useful about its current, actual state.
What I Actually Recommend
- Automated backups, but verified ones — confirm the system actually alerts you on failure, rather than silently doing nothing and hoping someone notices.
- At least one backup copy stored somewhere genuinely separate from your main systems, so a single disaster — theft, fire, ransomware — can't take out the backup at the same time as the original.
- A real test restore, at least occasionally, treated as a genuine, scheduled task rather than something that only happens by accident when curiosity strikes.
What Happened With That Client
We caught it during a routine check, not during an actual emergency, which is about the best-case version of discovering a problem like this. We fixed the underlying cause, set up genuine failure alerts, and built in a periodic test restore as an ongoing habit rather than a one-off fix. They got lucky with the timing. Plenty of businesses in an identical situation don't get that same lucky timing, and find out their backup was empty during the exact week they actually needed it.
The Uncomfortable Question Worth Asking Yourself
If your business lost everything on its main systems tomorrow — theft, fire, hardware failure, ransomware — are you certain, not hopeful, that your backup would actually get you back up and running? If there's any hesitation at all in that answer, that hesitation is worth acting on now, while it's a calm Tuesday afternoon problem, rather than waiting for it to become a genuine crisis instead.