Ask a small business owner if they have backups, and almost every one of them says yes.

Ask when they last actually restored something from those backups (a real file, a real mailbox, a real server) and you get a much longer pause.

That pause is the whole problem. A backup you’ve never tested isn’t a backup. It’s a hope.

A laptop dies. Ransomware hits. Somebody deletes the wrong folder.

It doesn’t really matter which one happens to you. What matters is what happens next.

If the honest answer to “can we get this back” is “I think so” or “our IT guy handles that,” you don’t have a backup strategy. You have a backup product sitting somewhere that nobody has verified actually works.

I’ve seen this exact moment play out with a client: a folder full of years of project files, gone in an afternoon, and the backup that was “definitely running” turned out to have silently failed four months earlier. Nobody noticed because nobody had ever needed to look.

That’s the thing about backups. They’re the one piece of your security stack you can be completely wrong about and not find out until the exact day you can least afford it.

“Isn’t it already in the cloud?”

This is the question I get the most, and the honest answer surprises most business owners.

If you’re running Microsoft 365, Microsoft keeps your email, files, and Teams data highly available. Their infrastructure isn’t going down. But “highly available” is not the same thing as “backed up.”

Microsoft’s own terms are explicit about this: protecting your data long-term, recovering from accidental deletion after it clears the recycle bin, and defending against ransomware that syncs its way through every connected device is your job, not theirs.

It’s called the shared responsibility model, and the short version is: Microsoft keeps the lights on. You’re responsible for making sure that if something in your data goes wrong, you can undo it.

That means if an employee deletes a folder and nobody notices for 90-plus days, or ransomware spreads through OneDrive before anyone catches it, “it’s in the cloud” doesn’t save you. You need a real backup of that cloud data, sitting somewhere Microsoft’s own default retention settings don’t control.

The rule that actually works: 3-2-1

You don’t need an enterprise backup budget to do this right. You need a structure, and it’s older than cloud computing:

  • 3 copies of your data
  • 2 different types of storage
  • 1 copy kept offsite, or offline and disconnected from your network

That last one is the part people skip, and it’s the part that matters most right now. Modern ransomware doesn’t just encrypt your files, it goes looking for your backups first, specifically because attackers know that’s how you’d recover without paying them.

If your “backup” is a second drive sitting on the same network as everything else, it’s not a backup. It’s just a second copy of the thing about to get encrypted.

A real backup has at least one copy that ransomware sitting on your network literally cannot reach: offline, air-gapped, or immutable, meaning even someone with admin access can’t alter or delete it once it’s written.

Backups aren’t the goal. Recovery is.

Here’s the distinction that matters: nobody’s actual business goal is “have backups.” The goal is “get back to work.” Those are different problems, and the difference is whether anyone has ever tested a restore.

A backup that’s never been restored is a theory. You don’t want to find out whether a theory holds up during a crisis. That’s the worst possible time to discover your backup software has been silently failing, or that your last three months of backups are all corrupted the same way, or that the restore process actually takes four days and your business can’t survive four days offline.

Two questions worth asking, even informally. The industry has names for these, and they are Recovery Time Objective and Recovery Point Objective. You don’t need the vocabulary to understand the ideas:

How long can your business survive without this data? A day? A week? That’s your recovery time: how fast you need to be back up and running.

How much data can you afford to lose? If your last good backup is from last night, that’s a day of work gone in the worst case. If it’s from last week, that’s a week. That’s your recovery point: how far back you’re willing to lose ground.

Neither number needs to be exact. But if you’ve never asked the question, you don’t actually have a recovery plan. You have a backup job running in the background that nobody has thought about since the day it was set up.

Your homework

Pick one system, your file server, your M365 tenant, whatever holds the data that would actually hurt to lose and do a real test restore. Not a glance at a dashboard to confirm the backup ran. An actual restore of a real file or mailbox, timed, so you know two things: that it works, and how long it takes.

If that test fails, or nobody at your business knows how to run it, that’s the most useful thing you’ll learn from this whole article. Better to find out now than during an actual bad day.

Locking down passwords, email, and backups covers the technical side. The next weak point usually isn’t technology at all, it’s whether the people responsible for managing all of this are actually doing their job.