Backups Are Dead; Long Live Recovery: Rethinking World Backup Day for the Ransomware Era

Every year on March 31st, the security community celebrates World Backup Day. Vendors tweet reminders. IT teams run awareness campaigns. Someone in marketing makes a clever graphic about the 3-2-1 rule.

And every year, organizations that had backups still lose everything to ransomware.

That’s because we’ve been celebrating the wrong thing. We’ve been celebrating the act of copying data when we should be celebrating the ability to come back from the dead.

The Uncomfortable Truth: Attackers Hunt Your Backups First

Let’s talk about what modern ransomware actually does before it encrypts a single production file. The operators are patient. They spend days — sometimes weeks — inside your environment before they detonate. During that reconnaissance phase, they’re mapping your infrastructure. And one of the first things they look for is your backup architecture.

Backup servers. Backup agents. Backup schedules. NAS shares with backup repositories. Cloud sync targets. Snapshot policies. They find all of it. And when they’re ready to execute, they encrypt or delete your backups before they touch production.

This isn’t a hypothetical attack pattern. It’s the default playbook for nearly every major ransomware operation. Groups like LockBit, BlackCat, and Cl0p have been systematically targeting backup infrastructure for years. The logic is simple: if the victim can restore from backup, they won’t pay. So the attackers make sure they can’t.

If your backup strategy doesn’t account for the fact that your backup server is a primary target, you don’t have a backup strategy. You have a false sense of security.

The “Backup Successful” Lie

Here’s a question that should make every IT and security leader uncomfortable: when was the last time you actually restored from your backups?

Not ran a backup job. Not saw a green checkmark in a dashboard. Not received a “Backup Successful” email notification. Actually restored a system, a database, or an application from backup and confirmed it was functional, consistent, and current.

For a disturbing number of organizations, the answer is “never” or “I’m not sure.” The backup job runs. The log says it succeeded. Everyone assumes it’s fine. Nobody tests it until the day they actually need it — which is the worst possible time to discover that your database backup has been silently corrupting for six months, or that your restore process takes 72 hours when your RTO is 8.

A backup that hasn’t been tested is a hope. It’s not a control.

Immutable Backups: Write Once, Read Many, Delete Never

This is where the conversation needs to shift. The concept of immutable backups — also known as WORM (Write Once, Read Many) storage — is the most important evolution in backup strategy in the last decade.

Immutable backups cannot be modified, encrypted, or deleted once they’re written — not by administrators, not by attackers, not by ransomware, and not by compromised service accounts. The data is locked for a defined retention period. Period.

Here’s what makes immutability a game-changer against ransomware:

Credential Compromise Proof: Even if an attacker compromises your backup server’s admin credentials, they cannot modify or delete immutable backup data.
Encryption Resistant: Ransomware that targets backup repositories will fail to encrypt WORM-protected data.
Tamper-Evident: Immutable copies can’t be quietly corrupted by malware dwelling in your environment during a long reconnaissance phase.

Most modern backup platforms — Veeam, Commvault, Cohesity, Rubrik, and the major cloud providers — now support immutability natively. If you’re running a backup solution that doesn’t offer WORM capabilities, that alone should trigger a vendor evaluation.

Air-Gapped and Offline: The Belt to Immutability’s Suspenders

Immutable backups are essential, but a defense-in-depth approach to recovery adds one more layer: air-gapped or offline backup copies. These are backup copies that are physically or logically disconnected from the production network.

An air-gapped backup can’t be reached by an attacker who has compromised your domain, your cloud tenant, or your backup server, because there’s no network path to it. Think tape media stored offsite, or cloud object storage in a completely separate account with no trust relationship to your production environment.

Is it inconvenient? Yes. Is it slower to restore from? Sometimes. Does it guarantee you have a clean copy when everything else is burning? That’s the point.

Building a Recovery-First Strategy

If you’re rethinking your backup program this World Backup Day, here’s the framework that matters:

Test Restores, Not Backups: Don’t just test that backup jobs complete. Test that you can restore critical systems within your stated RTO and RPO. Do it quarterly. Document the results. Fix what’s broken.
Implement Immutability: Enable WORM on your backup repositories. Set retention locks. Ensure that no single account — including backup admin — can override immutability.
Air-Gap a Copy: Maintain at least one backup copy that is physically or logically disconnected from your production environment.
Simulate the Worst Case: Run backup recovery drills that simulate ransomware scenarios, not just hardware failure. Include the scenario where your backup server itself is compromised.
Align to BCP/DR Commitments: Verify that your actual recovery times match your business continuity commitments. If your RTO says 8 hours and your restore takes 36, your BCP is fiction.

Backups Are a Feature. Recovery Is the Product.

The shift I’m asking for isn’t complicated, but it is cultural. Stop celebrating that backups ran. Start celebrating that you proved you can recover.

Every board presentation, every QBR, every BCP review should include the question: “When did we last test a full restore, and how long did it take?” If the answer makes people uncomfortable, that’s the point. Discomfort now is infinitely cheaper than paralysis during an incident.

This March 31st, don’t just back up your data. Prove you can bring it back.

Discussion Questions

1. When did your organization last perform a full restoration test of critical systems? Did the results align with your documented RTO and RPO?

2. Are your backup repositories protected with immutability (WORM) today? If not, what’s the gap — technology, budget, or awareness?

3. If ransomware operators compromised your backup admin account tonight, how many of your backup copies would survive?

CODY KELLER