Your Backups Won't Save You If Attackers Get to Them First

Most small-business owners I talk to believe the same comforting thing. They have backups, so ransomware can't really hurt them. I understand why that feels safe. But I've watched that assumption come apart more than once, and the gap between "we have backups" and "we're back to work" is where businesses lose real money.

Here is the part that surprises people. Attackers know you have backups. They plan for it.

The backups are the target, not an afterthought

When ransomware lands on a network, it doesn't just scramble the files people are actively using. Many strains go hunting. They look for your backups, and then they delete them or encrypt them too. The federal advisory on the Medusa ransomware spells this out plainly: the encryptor shuts down every service tied to backups and wipes the system's shadow copies before it encrypts a thing, precisely so you have no clean copy to recover from without paying.¹

Think about what that means from the attacker's side. A business that can restore its own data is a business that can say no. A business that can't is a business that pays. That is why the backups get attacked directly. Destroying them is how the attacker makes sure you pay.

I've seen backups encrypted. I've seen them simply wiped. And in those moments, the plan everyone was counting on was just gone.

A copy they can't reach

So what actually protects you? One idea, and it's simpler than it sounds. At least one copy of your critical data has to live somewhere an attacker who is already inside your systems still can't touch.

That usually means a copy that's offline, or off-site, or locked against changes and deletion for a set period of time. That last one has a technical name, immutable, but the plain version is easier to hold onto: it's a copy you can't alter or delete, even on purpose, until the lock expires. If you can't change it, neither can someone who stole your admin password.

The federal guidance makes two points here worth keeping. Keep offline, encrypted backups of the data that matters.¹ And test them, regularly, so you know they'll actually restore when you need them.² Some cloud providers offer immutable storage. Have someone who knows what they're doing set it up correctly.

Here's the test I'd put to any backup arrangement. If your file server went down this afternoon, where is your copy, and is it somewhere the thing that took down the server can also reach?

Hours versus weeks

Now for the part nobody warns you about.

I've been in recoveries where the data was fine. Genuinely backed up, sitting there, recoverable. And it still took days to get people working normally again. Sometimes a couple of weeks. Management had been told it would take hours.

How does that happen? Three things ate the time, every time.

First, the servers themselves had to be rebuilt before any data could go back on them. Second, the software that runs the business had to be reinstalled, piece by piece, before anyone could actually use the restored files. And third, the one that still gets me. Nobody knew what to restore first. People stood around a conference table debating which system mattered most while the clock ran.

The data being safe is only the first hurdle. Having a backup is not the same as being back in business. The restore is a project, and if nobody has thought it through in advance, it's a project you're inventing under the worst possible pressure.

Decide now what comes back first

So decide the order now, while nothing is on fire.

Start with one question. What does your business need to take an order and get paid? Rank your systems against that, honestly. Not everything is equally urgent, and the guidance on recovery agrees. You rebuild and restore by priority of critical services, not everything in one undifferentiated rush.³ The thing that lets you invoice a customer comes back before the thing that schedules the office holiday party.

Then, for each system near the top of that list, know what it actually needs to run again. There are four things. The data itself. The software it runs on. The login that unlocks it. And a person on your side who can actually run the recovery. Miss any one of those and the system sits there, restored and useless, while you hunt for a password or wait on a vendor.

This is where you find the honest measure of a backup. A backup is only as good as how fast it gets your people back to work. Everything else is bookkeeping.

If you want to go a step further, there are two questions worth working through: how you'd confirm a restore actually works before you're depending on it, and how long your team could keep running on paper while systems come back. I wrote about both in how to survive and prevent an IT emergency, so I won't repeat it here. Go read that one when you've finished this.

What to do this week

You don't need a big project to start. You need a few answers.

This week, find out where your backups live and whether at least one copy sits somewhere an attacker inside your network couldn't reach. Then sketch the recovery order. Write down the two or three systems you'd need back first to keep taking orders and getting paid. That's an afternoon, not a quarter.

After that, talk to whoever handles your IT. The point of these questions isn't to catch anyone out. It's that a vague answer tells you as much as a clear one.

• Do we have a backup that's offline or locked against deletion, and when was the last time someone actually restored from it to confirm it works?
• If every one of our servers were gone tomorrow, what's our order for bringing systems back, and who runs that recovery?
• How long, realistically, from attack to my team working normally again? Not the data being recovered. People working.
• What do we need on hand to rebuild a server from scratch, and do we have it ready right now?

If the answers come back specific, with dates and names and a real sequence, that's a good sign. If they come back as "don't worry, we've got backups," you've just learned something important, and you learned it today instead of during the worst week of your business year.

The businesses that recover well are the ones who decided, calmly and in advance, what comes back first.