Why Perimeter Security Is Failing - Zero Trust Microsegmentation Explained



Immutable Backups and Ransomware Recovery: Why the 3-2-1 Rule Is No Longer Enough

Ransomware operators don't just encrypt your production data anymore. They go after your backups first.

According to Veeam's 2025 Ransomware Trends Report, 89% of ransomware attacks now target backup infrastructure. Attackers spend a median of 5 days inside a network before triggering encryption, per Mandiant's M-Trends 2025 report, systematically identifying and destroying backup systems before locking anything down.

The 3-2-1 backup rule — 3 copies, 2 media types, 1 offsite — was the standard data protection strategy for decades. It was built for hardware failures and natural disasters, not for adversaries who study your infrastructure before they strike.

Immutable backups change that equation. They are storage snapshots or backup copies that cannot be modified or deleted for a defined retention period, even by administrators with full access. They are the single most important defense when ransomware targets your recovery points.

On The Security Podcast of Silicon Valley, Anand Ganesh, Founding Software Architect at Hammerspace, described the architectural shifts needed to make ransomware data recovery reliable — not just hopeful. The full conversation covers encryption, metadata-driven security, and storageless data architecture.

What Is the 3-2-1 Rule for Ransomware?

The 3-2-1 backup rule specifies keeping three copies of data, on two different media types, with one copy stored offsite. It was designed for disaster recovery — hardware failure, fire, flooding — not for an adversary actively trying to destroy your ability to recover.

For ransomware specifically, the rule has evolved into the 3-2-1-1 rule, adding one copy that is either immutable or air-gapped:

Rule

Copies

Media Types

Offsite

Immutable/Air-Gapped

3-2-1

3

2

1

Not required

3-2-1-1

3

2

1

1

That additional "1" is what separates organizations that recover from ransomware from those that pay the ransom. The data from Sophos' 2025 State of Ransomware report is striking: 53% of organizations recovered within one week when using backups, while only 49% of those that paid ransom actually got their data back.

But even the 3-2-1-1 rule has blind spots. It treats backup as the complete answer, leaving three critical questions unanswered:

  • How fast can you actually restore? Having an immutable backup doesn't guarantee fast recovery if restoration requires rebuilding infrastructure and manually verifying consistency across systems.

  • Can you restore consistently across distributed storage? If data spans five platforms across three cloud providers, per-volume restores cannot guarantee a consistent point-in-time state.

  • Can the business keep running during recovery? Traditional disaster recovery requires failover — and failover means downtime.

Why Immutable Backups Are Necessary but Not Sufficient

Immutable backups solve a specific and critical problem: they prevent ransomware from destroying your recovery points. Without immutability, an attacker with admin credentials can delete backups before encrypting production data. With it, those copies survive regardless of the attacker's access level.

That said, three gaps remain after you've implemented immutable backups.

Gap 1: Volume-Level Snapshots Can't Cross Storage Boundaries

Traditional immutable snapshots are tied to individual storage volumes. That's a problem in the real world. According to Flexera's 2025 State of the Cloud Report, 70% of enterprises run hybrid cloud environments. A typical organization has data spread across NetApp, Pure Storage, AWS S3, Azure Blob, and on-premises object storage simultaneously.

Restoring a consistent state across all of these means running separate backup processes for each system, manually coordinating restore points, and verifying data consistency between them after the fact. During a ransomware incident, that coordination overhead can stretch recovery from hours into days.

Ganesh described a fundamentally different approach:

"You have a share that has your data, and that share's data could be sitting on any and all infrastructure. Some on NetApp, some on Pure Storage, some in AWS, some in object storage. We have share-level snapshots where you take a snapshot across all the storage systems, and that becomes pretty powerful."
— Anand Ganesh, Founding Software Architect, Hammerspace (The Security Podcast of Silicon Valley, Episode 1)

Share-level snapshots that span all underlying storage turn ransomware data recovery from a multi-day, multi-team coordination effort into a single restore operation.

Gap 2: Failover-Based DR Costs Hours You Don't Have

Traditional disaster recovery relies on active-passive architecture: a primary site handles production traffic while a standby site waits. When ransomware hits, the organization "fails over" — changing replication direction, converting passive to active, verifying data integrity, and redirecting users. Every step takes time, and time is what you don't have.

Ganesh described the alternative:

"If you lose a site, you're not waiting to convert one side from passive to active. You're not changing the direction of replication. It's active-active. One goes down, you just mount from another site and continue running."
— Anand Ganesh, Founding Software Architect, Hammerspace

Active-active architecture eliminates failover entirely. Every site serves live production traffic. If one site is compromised, users connect to another and keep working. Recovery time drops from hours to minutes — no conversion, no replication direction to flip, no manual verification.

Gap 3: Backups Don't Detect Threats

Immutable backups protect your recovery points, but they don't detect ransomware before it executes. By the time you need the backup, the damage is already done. Storage-layer detection can catch threats earlier in the kill chain.

Ganesh described integrating threat detection directly into the storage platform:

"You put an objective on your data that says process data through this Lambda function. That's it. We orchestrate everything on the back end, derive the metadata, and if a file is found to be a threat, we prevent access to the content of that file."
— Anand Ganesh, Founding Software Architect, Hammerspace

Metadata-driven threat detection at the storage layer can quarantine suspicious files as they're written — before ransomware spreads across the filesystem. This turns storage from a passive target into an active line of defense.

What Is the Best Method to Recover from a Ransomware Attack?

Every ransomware recovery guide on the internet recommends the same playbook: 3-2-1 backups, incident response plans, employee training, and patching. That advice is necessary but generic. Here is what those guides leave out — the architectural decisions that determine whether recovery takes minutes or weeks.

Step 1: Isolate and Identify (Minutes 0–30)

Disconnect affected systems from the network to stop lateral spread. Identify the ransomware variant using file extensions, ransom notes, or tools like ID Ransomware. Check No More Ransom for free decryption tools — some older variants (GandCrab, certain Dharma strains) have known decryptors.

Step 2: Assess Backup Integrity (Minutes 30–60)

Verify that your immutable backups exist and are uncompromised. Check the timestamp of the most recent clean snapshot. If using air-gapped backups, confirm they predate the initial compromise — which may be days or weeks before encryption triggered, given the median 5-day dwell time.

Step 3: Restore from Immutable Snapshot (Hours 1–4)

Restore from the most recent clean immutable snapshot. With cross-infrastructure snapshots (share-level), this is a single operation. With per-volume snapshots, you'll need to coordinate restores across all affected storage systems and verify inter-system consistency — a significantly slower and more error-prone process.

Step 4: Enable Self-Service Recovery Where Possible (Concurrent)

Don't funnel every restore request through a single admin team. Ganesh described a self-service approach that lets affected teams recover files immediately:

"We want to make it as self-service as possible. The end user basically just fat-fingered something or deleted a bunch of files, they can just go into the undelete location under the share and bring back the files."
— Anand Ganesh, Founding Software Architect, Hammerspace

In a ransomware scenario affecting thousands of files across multiple departments, self-service recovery eliminates the bottleneck that turns a four-hour recovery into a four-day one.

Step 5: Verify, Monitor, and Harden (Hours 4–24)

Verify data integrity post-restore. Monitor for indicators of reinfection. Patch the vulnerability that enabled initial access. Update access controls and rotate all credentials. The goal is to close the door before declaring the incident resolved.

Air-Gapped Backups: When and How to Use Them

Air-gapped backups are physically or logically isolated from the production network. No network path means ransomware cannot reach them, no matter what access the attacker has gained.

Air Gap Method

Restore Speed

Cost

Protection Level

Tape stored offsite

Slow (hours to days)

Low

Highest (true physical isolation)

Cloud object storage with WORM policies

Medium (minutes to hours)

Medium

High (logical isolation)

Dedicated backup network with one-way data flow

Fast (minutes)

High

High (network isolation)

Removable drives on rotation schedule

Slow (hours)

Low

High (physical isolation)

The strongest approach is layered: use immutable snapshots as the primary recovery mechanism (fast restore, minutes-to-hours RTO) and air-gapped backups as the last line of defense (slower restore, but guaranteed survival even if every connected system is compromised).

CISA's StopRansomware Guide recommends maintaining at least one air-gapped backup copy, tested quarterly for restoration integrity.

Crypto-Shredding: Secure Deletion After Recovery

After recovering from ransomware, compromised data needs to be securely destroyed. BYOK (Bring Your Own Key) encryption enables crypto-shredding: destroy the encryption key, and the associated data becomes permanently irrecoverable — even if the ciphertext persists on disk.

Ganesh explained why this matters:

"As soon as you remove it from the namespace and destroy the key, you've lost all capability to decrypt what's on your storage. You have logically deleted the data."
— Anand Ganesh, Founding Software Architect, Hammerspace

Crypto-shredding is faster, more thorough, and more auditable than trying to locate and wipe every copy of compromised data across a distributed storage environment. For organizations facing data breach notification requirements, the ability to prove that exposed data has been cryptographically destroyed can mean the difference between a regulatory fine and a clean report.

Ransomware Recovery Plan Checklist

A data protection strategy that actually works against modern ransomware needs more than backups. Based on the podcast insights, SERP analysis, and industry best practices, here is a consolidated checklist:

  • Immutable snapshots enabled on all production storage with retention exceeding typical dwell time (30+ days recommended)

  • Air-gapped backup maintained and tested quarterly

  • Cross-infrastructure snapshot capability for consistent state restoration across all storage systems

  • Active-active replication to eliminate failover downtime (where budget permits)

  • Self-service undelete enabled for end users to reduce recovery bottlenecks

  • Storage-layer threat detection integrated via DLP and antivirus scanning

  • BYOK encryption for crypto-shredding capability post-incident

  • Full recovery drill executed annually, measuring actual RTO and RPO against targets

  • Incident response plan documented, distributed, and rehearsed quarterly

What is the 3-2-1-1 backup rule?

How long does ransomware data recovery take?

Can ransomware be reversed?

Should you pay the ransom?

Meet the hosts

Jon McLachlan

Co-Founder, YSecurity & Cyberbase

Questions founders and engineers actually ask, with decisions not theater.

Questions founders and engineers actually ask, with decisions not theater.

Sasha Sinkevich

Co-Founder, YSecurity & Cyberbase

Pushes past surface answers into architecture, tradeoffs, and what scales.

Pushes past surface answers into architecture, tradeoffs, and what scales.

The Security Podcast of Silicon Valley

jon@thesecuritypodcastofsiliconvalley.com

The Security Podcast of Silicon Valley

jon@thesecuritypodcastofsiliconvalley.com