Backup vs Disaster Recovery: Why Your Backups Won't Save You From Ransomware

I’ve sat in on a lot of post-ransomware conversations. There’s a moment in almost every one of them where the owner says some version of “but we have backups.” And the response from the recovery team is always some version of “yes, and that’s not the same as disaster recovery.”

That’s the conversation this post is trying to prevent.

Backup and disaster recovery are not the same thing. They overlap, they share tooling, and most vendors sell them together, but the gap between them is exactly where small businesses get hurt. Ransomware is the most painful place that gap shows up. Hardware failures and accidental deletions are the others.

Let me walk through the difference, the math that matters, and why most SMB “DR plans” don’t survive contact with reality.

What Backup Actually Does

A backup is a copy of your data at a point in time. That’s it. It exists so that if you lose the original, whether through hardware failure, accidental deletion, file corruption, or malicious encryption, you can put a copy back.

Backups answer one question: “can I get this file or this database back?”

Backups don’t answer the question that matters when the building is on fire: “how long until we are fully operational again?”

You can have perfect backups and still be down for two weeks.

What Disaster Recovery Actually Does

Disaster recovery is the broader process of restoring business operations after a disruptive event. Backups are one ingredient. The other ingredients are the things small businesses underestimate.

A real DR plan has answers to:

• Where do we run if the office or the server room is gone? Cloud failover, hot site, spare hardware ready to deploy.
• How fast can we be running again? Your Recovery Time Objective. Hours? A day? A week?
• How much data are we willing to lose? Your Recovery Point Objective. Last night? Last hour? Last 15 minutes?
• Who does what? Names, phone numbers, and a sequence of operations.
• How do we communicate with employees and clients while systems are down? Without using email, because email is what’s down.
• How do we know it works? A tested, documented restore, not a hopeful one.

That’s disaster recovery. Backups are step one of about twelve. We covered some of this in the incident response planning post, and the two plans are siblings, but DR is specifically about getting operational again, not just stopping the bleeding.

The RPO and RTO Math Most SMBs Skip

Two acronyms that matter more than any vendor brochure.

RPO, Recovery Point Objective. How much data can you lose without serious harm? If you back up nightly at 11 PM and ransomware hits at 4 PM the next day, your RPO is roughly 17 hours. That’s how much work your team will have to redo. For a 50-person company, 17 hours of lost work is a real number. For a finance team mid close, it can be catastrophic.

RTO, Recovery Time Objective. How long can you be down before the business takes lasting damage? Two hours? Two days? Two weeks? Most SMBs have never put a number on this, and when they do the answer is much shorter than what their current setup can deliver.

Here’s the math that surprises people. If your RTO is 4 hours and your only backup is a USB drive in a fireproof safe, your real RTO is closer to 4 days. You have to source replacement hardware, rebuild the operating systems, restore data, reconfigure applications, and verify everything. That’s not 4 hours. That’s not even the same order of magnitude.

The cost of meeting an aggressive RTO is real, but so is the cost of downtime. The right move is to set the RTO and RPO based on what the business actually needs, then build the DR plan to hit those numbers.

Why Backups Alone Lose to Ransomware

Modern ransomware is not stupid. The first thing it does, before encrypting anything visible, is hunt for backups. It looks for backup repositories on the network. It looks for cloud sync folders that are backups in disguise. It looks for backup software’s admin console and tries to delete or encrypt the backup catalog.

If the attacker has been in your environment for two weeks, which is the average dwell time, they have time to do this thoroughly. They don’t push the encryption button until they’re confident your backups are also gone or worthless.

The number of small businesses we’ve seen with backups they couldn’t restore from after ransomware is sobering. Common reasons:

• Backup target was a shared folder on the network. Encrypted along with everything else.
• Backups went to cloud sync (Dropbox, OneDrive sync folder). The sync replicated the encrypted files to the cloud copy. Game over.
• Backup credentials were compromised and the attacker deleted the cloud backup before encrypting locally.
• Backups existed but had been silently failing for six months. Nobody was checking the reports.
• Backups were technically successful but had never been test-restored. When it came time to restore, half the files came back corrupted.

Each of those is a backup problem. None of them are a DR problem in isolation. A real DR plan assumes attackers will go after backups and is built so the recovery still works anyway.

The Three Things That Actually Survive Ransomware

If you take nothing else from this post, take these three.

1. Immutable Backups

Immutable means write-once, can’t-be-modified-or-deleted by anyone, including an admin with stolen credentials. The backup target is set up so that for a defined retention window, the data physically cannot be erased or overwritten. Ransomware can’t delete what it can’t modify.

Immutability is now table stakes for any serious backup product. Axcient, Datto, Veeam, and others all support it in modern versions. The configuration matters. Some setups call themselves immutable but have admin override paths the attacker can find. The right configuration locks even the highest-privilege account out for the retention window.

2. Off-Network, Off-Account Copies

The old 3-2-1 rule said: 3 copies, 2 different media, 1 offsite. The 2026 update is 3-2-1-1-0. Three copies, two media types, one offsite, one immutable, zero recovery errors verified.

The “off-account” part is the new piece. Your offsite copy needs to be in a different security boundary than the rest of your environment. Different cloud account, different credentials, ideally a different identity provider. If the attacker compromises your Microsoft 365 tenant, they should not also have a path into your backup vault.

3. Tested, Documented Restore

A backup that has never been restored is a hope, not a plan. We test client restores quarterly at minimum. Pick a server, pick a database, pick an entire site. Restore it to an isolated environment. Verify the data is correct, the application starts, the services come back up. Document how long it took.

The first test restore is usually painful. Something is missing. Permissions are wrong. The application has a license key tied to the original hardware. The database needs a transaction log replay nobody documented. Better to discover that during a test than during a real incident at 2 AM.

After two or three test cycles, the runbook is solid and the restore actually works the way the brochure promised.

The DR Plan Components People Forget

Beyond backups, a working DR plan covers:

• A current asset inventory. Servers, applications, data flows, dependencies. You can’t restore what you can’t list.
• A communication plan. Where do employees go for updates when email is down? Texted phone tree? An out-of-band Teams or Slack? It needs to exist before the day you need it.
• Defined recovery priorities. Not everything comes back at once. What’s first? Domain controllers, then ERP, then file shares, then email, then everything else. Or some other order. Decide now, not during the outage.
• Vendor contact list. Internet provider, line-of-business application support, hardware vendors, your cyber insurance carrier, your MSP. Phone numbers. Account numbers. After-hours escalation paths.
• Spare or surge capacity. If your servers are gone, where do you run? A cloud DR site that boots from backups in 60 minutes? A pre-staged VM environment? Something has to exist before the disaster, not be ordered after it.

What “Good” Looks Like for a 50-Person Business

A reasonable BCDR posture for a typical SMB looks roughly like this. RPO of 1 to 4 hours for critical systems, achieved with frequent snapshots or continuous data protection. RTO of 4 to 8 hours for the core stack, achieved through cloud failover or rapid bare-metal recovery to virtual environments. Immutable backup retention of at least 30 days. Off-account copies in a separately secured cloud vault. Quarterly test restores documented and tracked. A written runbook updated annually and after every test.

That’s the standard we build to for clients running our BCDR service. It’s achievable for small businesses today. The technology is mature, the costs are reasonable, and the alternative is the conversation I described at the start of this post.

The Bottom Line

Backups are necessary, but they are not disaster recovery. They are one ingredient in a recovery plan that also includes recovery time targets, immutable copies, off-network architecture, tested restores, communication plans, and a documented runbook. The businesses that get hit by ransomware and survive intact are the ones that built the full plan, not just the backup job.

If you don’t know your RPO, your RTO, or the last time someone successfully test-restored a critical system, you are running on hope. Hope is not a recovery strategy.

We do real BCDR work for businesses across the Inland Empire, with immutable backups, defined recovery targets, and quarterly tested restores. If you want to know where your real exposure sits today, schedule a free assessment. We’ll walk through your current setup, identify the gaps that ransomware would expose, and tell you exactly what it takes to close them.