The most dangerous thing on a business network isn’t a virus. It’s a green light.
Every morning, in thousands of Sacramento businesses, a backup job completes and reports success. Somebody glances at it, or more likely doesn’t, and gets on with their day. The system says everything is fine. The system has said everything is fine for years.
Then one Tuesday it matters, and roughly a third of the time the business discovers that “backup completed successfully” and “your data can be recovered” were never the same statement.
What the green light actually confirms
A backup job reporting success confirms exactly one thing: the job ran and wrote data somewhere.
It does not confirm the data is readable. It does not confirm the data is complete. It does not confirm that a server could be rebuilt from it, or that the database inside will open, or that anyone knows how long the process would take.
Corrupted files back up perfectly well. So do encrypted ones, which is how businesses occasionally discover their backup contains three weeks of ransomware-scrambled data, faithfully copied every night without complaint.
The gap between what a green light means and what people assume it means is where a great many businesses lose a fortnight.
Six reasons this never gets addressed
Nobody deliberately ignores their backups. The reasons this slides are more human than that, and most businesses will recognise at least two of them.
“It’s on the list”
It genuinely is. It has been for a while.
Backup testing produces no visible benefit on an ordinary Tuesday. Nothing improves, nobody notices, and no client is served better because of it. Against a week containing actual deadlines, it loses every time — and it loses again the following week, and the one after.
Eighteen months pass this way without anyone making a decision to let it.
“Our provider handles that”
They may. Or they may run the backup software and have never attempted a restore either.
There’s a specific question that resolves this, and it’s worth asking directly: when did you last restore something, and what did you send us afterward? If testing produces no document, it either isn’t happening or isn’t being recorded — and those amount to the same thing when an insurer asks.
Plenty of capable providers do backups without doing backup testing, because the arrangement never explicitly included it.
“We restored a file once and it was fine”
This is the most understandable one, and the least reassuring.
Recovering a deleted document proves that the backup contains documents. It says nothing about whether an entire server would come back — with its operating system, applications, licences, configurations, and the relationships between systems that make a business function rather than merely storing files.
Businesses that have only ever restored files are often surprised by what a full recovery involves.
“We’d lose a day at most”
This assumption usually goes untested, and it tends to be optimistic by a factor of several.
Full recovery isn’t one action. It’s containment first — establishing whether an attacker still has access, because restoring into a compromised environment simply hands them a fresh copy. Then assessment, then restoration in a specific order, servers before workstations, with verification at each step.
Businesses that have rehearsed this know roughly how long it takes. Those that haven’t are estimating while clients ask for updates.
“We’re too small for this to be a priority”
Size affects consequences, not exposure.
Attacks on businesses this size are overwhelmingly automated — bulk scanning, mass phishing, attention following whatever responds. Nobody assessed your company and decided it was worth the effort. And hardware doesn’t check headcount before failing.
What size genuinely changes is the recovery capacity. A larger business has staff who can absorb a bad fortnight. A twelve-person firm frequently doesn’t.
“Nothing’s ever gone wrong”
The most common reason of all, and the hardest to argue with, because it’s true right up until it isn’t.
Every business that has lost data had, until that week, an unbroken record of nothing going wrong.
What actually gets missed
When we do test backups at businesses that had assumed they were covered, certain omissions come up repeatedly. They’re rarely the obvious things.
| Usually backed up | Frequently missing |
| File server documents | Line-of-business application databases |
| Shared drives | Email settings and mailbox rules |
| Desktop folders | Software licences and activation keys |
| Accounting data files | Accounting system configuration |
| Point-of-sale settings | |
| The workstation running a scheduled task nobody documented | |
| Cloud data assumed to be Microsoft’s responsibility |
That last row surprises people regularly. Microsoft 365 keeps your data available. It is not a backup service in the sense most businesses assume, and its retention windows are shorter than people expect. Deleted or maliciously encrypted content past those windows is gone.
Restore your documents on Tuesday and discover you still can’t invoice on Wednesday — that’s what this table describes.
Where the backup lives matters as much as whether it exists
One detail decides more outcomes than any other, and it’s frequently the one nobody thought about.
Modern ransomware specifically hunts for connected backup storage. Attackers established early that a business able to restore doesn’t pay, so locating and encrypting the backup is now standard procedure rather than an afterthought.
A backup drive sitting in your server room, reachable from any workstation on the network, will be encrypted along with everything else. It will keep reporting success until the moment it no longer exists.
What separates businesses that recover from businesses that negotiate is a copy somewhere the office network cannot reach — cloud replication or genuinely offline storage — with enough recovery points to reach back past the date an infection began.
That last part matters more than it sounds. Attackers routinely sit inside a network for weeks before triggering anything. If your only clean copy is from last night, it may already contain their tools. Businesses restore, resume, and get encrypted again a week later from the infection they carefully preserved.
What a genuine test involves
“We test our backups” spans an enormous range. Three versions, roughly.
The weakest checks that jobs completed and files appear in the backup set. This confirms almost nothing, for reasons covered above.
Better restores a handful of individual files to confirm they open. Useful, but silent on whether a server would come back or how long it would take.
A real test restores complete systems into an isolated environment and confirms they function — the server boots, the database opens, the application launches, users can log in. It records how long each stage took, which converts your recovery time from a guess into a number. And it produces documentation: what was tested, when, by whom, with what result.
That documentation has become genuinely valuable beyond peace of mind. Cyber insurers ask for it. Larger clients ask for it during due diligence. A test that happened but wasn’t recorded is nearly as unhelpful as one that never happened.
Quarterly suits most businesses. Environments change — new applications, new systems, new dependencies — and a recovery plan validated eighteen months ago describes a company that no longer exists.
Our backup and disaster recovery service handles verification daily and testing on schedule, with a written result each time, so the answer to “when did you last test?” is always a date.
A Sacramento-specific note
Businesses here carry an obligation profile that’s slightly unusual, and it’s worth naming.
The regional economy runs heavily on professional services connected to state government, healthcare systems, education, and regulated industries. That means an unusual proportion of Sacramento businesses hold data belonging to organisations with their own compliance requirements — and those requirements flow downstream through contracts.
The practical consequence is that a backup failure here frequently isn’t only your problem. If you hold client records, patient information, or public-sector project data, an inability to recover becomes a conversation with whoever entrusted it to you.
It’s also why security questionnaires arrive more often in this market than elsewhere in the region. Backup testing dates are on nearly all of them.
Prevention, since it’s cheaper
None of this argues for accepting incidents and preparing to recover. Recovery is the last line.
Multi-Factor Authentication on every account prevents the substantial majority of intrusions, since stolen credentials remain the most common route in. Endpoint detection and response catches suspicious behaviour rather than known threats — which is how ransomware gets identified during the weeks it spends mapping a network. Email filtering removes most attempts before anyone has to judge them. Automated patching closes the vulnerabilities that get exploited.
And continuous monitoring is what makes those quiet weeks visible at all. Without it, an attacker’s reconnaissance produces no symptom whatsoever.
Our cybersecurity and managed IT services run these together, because they’re one problem rather than several.
The short version
If you skim nothing else, this is the substance of it:
A completed backup job proves the job ran, not that your data is recoverable. Testing a single file recovery proves considerably less than most people assume. A backup reachable from your network is a target rather than a safety net. One recovery point is insufficient given how long attackers wait before acting. Cloud services keep your data available but are not a backup in the sense you’re imagining. And the documentation produced by proper testing has become something clients and insurers actually ask to see.
None of that is complicated. It’s just nobody’s job, which is a different sort of problem and a considerably more solvable one.
One test, and you’ll know
Here’s a straightforward suggestion rather than a pitch.
Whatever your current arrangement, ask for a full restore test on one system this quarter. Not a file — a system. Ask what it took, how long it ran, and what the written result says.
You’ll get one of two outcomes. Either it works, you have a number for your recovery time, and you can stop wondering. Or it doesn’t, and you’ve found that out on a quiet Tuesday with time to fix it rather than during a week when everything else is already going wrong.
Both outcomes are worth having. Only one of them is worth waiting for.
We’ll run that test for you. No agreement required and no obligation afterward — we’ll take whatever backup you currently have, attempt a genuine restore, and give you a written result telling you exactly where you stand. Call 209-920-4077 or tell us what you’re running and we’ll
