Most business owners I talk to believe they're protected because someone, somewhere, set up a backup. The job runs. The dashboard says “successful.” The bill gets paid. So the box is checked and nobody thinks about it again — until the day they need it.
Here's the problem. A backup existing and a business being able to recover are two completely different things. The first is a copy of your data sitting somewhere. The second is your team back to work, invoices going out, payroll running, in a realistic amount of time. Plenty of businesses have the first and assume it guarantees the second. It doesn't.
“We have a backup” answers the wrong question
When an owner tells me “we're covered, we have backups,” I treat it as the start of a conversation, not the end of one. “We have a backup” doesn't tell me whether the business can recover. It tells me a copy might exist.
The questions that matter are more specific. What exactly is being backed up — files, or the full server? How often does it run? How far back can you restore? Who gets alerted when a job fails? Has anyone ever tested a restore? Can you recover the whole system, or just a folder? And how long would all of that actually take?
That last one catches people off guard. A backup that takes three days to restore technically protected your data. It did not protect your business from three days of downtime. When owners answer these questions honestly, the confident “we're covered” usually gets a lot quieter.
A file copy is not a recovery plan
The most common gap I see isn't a missing backup. It's a backup with no recovery plan behind it.
A file backup is fine if someone deletes a spreadsheet. It does very little when the server dies, when ransomware encrypts everything, when the office floods, or when your accounting system — not just a document — has to come back from scratch. Those are the events that actually threaten a business, and they demand more than a copy of some files.
Recovery is a set of practical questions a file backup never answers. How fast can we restore? Where are we restoring to while hardware is being replaced? Can people keep working in the meantime? Are the backups isolated so ransomware can't reach them too? Do we have full image-based backups of the servers, or only files? Is Microsoft 365 protected separately? What order do systems need to come back in, and who's responsible for each step? Most weak setups fail not because the backup is missing, but because nobody thought past the word “backup.”
“It's in the cloud” can mean almost anything
“Cloud backup” is the phrase that makes me want to verify the most, because it covers an enormous range. It might mean a proper business-continuity platform with local and cloud copies. It might mean OneDrive. It might mean someone dragged files into Dropbox two years ago. It might mean a backup product nobody has logged into in months.
Cloud isn't magic. Done right, it's excellent — monitored, tested, fast to restore. But “it's in the cloud” by itself tells you nothing about whether servers are imaged, whether workstations are included, whether Microsoft 365 is covered, how long retention runs, or whether the backups are protected from ransomware. And here's the one most owners miss entirely: Microsoft does not back up your 365 data for you the way people assume. If that's your only copy, you have less protection than you think.
A “successful” job is not a successful restore
This is the one that costs businesses the most. A backup job reporting “successful” only means the job ran. It does not mean the data is complete, that the image will boot, or that you can actually get it back. The only way to know is to test a restore — and almost nobody does.
I'd want to see restore testing at least quarterly for the systems that matter, more often for critical environments. At a minimum, there should be proof — not an assumption — that files come back and key systems can be rebuilt.
The reason testing gets skipped is simple: it's boring until it's urgent. Nobody feels the pain of an untested backup on a normal Tuesday. The dashboard looks green, the invoice is paid, everyone moves on. Testing takes time and someone who cares enough to verify instead of assume. But that's exactly the work that separates managed IT from reactive IT — finding the corrupt, incomplete, or misconfigured backup during a quiet week instead of during the disaster.
What actually separates the businesses that survive
If I had to name one thing, it isn't luck and it isn't even the backup itself. It's preparation.
The businesses that come through a disaster tend to already know what data and systems matter most, how those are protected, how quickly they need to be back, who owns each step of recovery, how people will keep working during the outage, and who to call. They know because they decided all of it in advance and tested it.
The businesses that don't survive learn all of that during the emergency — that the image won't boot, the internet circuit has no failover, the 365 data was never protected, or nobody knows the admin passwords. And disasters aren't only hurricanes and fires. More often it's ransomware, a failed server, a bad software update, a deleted mailbox, a lost laptop. The cause varies. The thing that determines the outcome doesn't.
Backup is the tool. Recovery is the outcome. Preparation is what connects the two — and it's the part most setups skip.
A simple gut check
You don't need to become a backup expert. You just need to stop accepting “we have backups” as the whole answer — from your team, your vendor, or yourself. Ask what's protected, ask when it was last tested, and ask how long recovery would actually take. If the answers get fuzzy, that's worth knowing now, while it's a quiet week.
If you'd like a straight answer to those questions about your own setup, that's the kind of review we do for Rhode Island businesses — no jargon, no pressure, just a clear picture of whether you could actually recover.
