Storage and Ransomware: Immutability, Air Gaps and Real Resilience

For a long time, ransomware recovery was treated as a backup problem and the array just held the data. That has changed, and it changed because the attackers changed. Modern ransomware crews go after the backups first. They delete snapshots, they encrypt or corrupt the backup repository, and they dwell quietly for weeks so that every clean copy ages out before anyone notices. Once the recovery path is gone, the ransom is the only path left. That is the whole strategy.

So the storage layer, the array and the copies it holds, became a control surface in its own right rather than a passive bystander. Every serious vendor now ships immutability and air gap features, and they are genuinely valuable. The difficulty is that the marketing has raced ahead of the engineering, and a checkbox labelled immutable is being sold as a recovery strategy. Those are not the same thing, and the gap between them is exactly where organisations get hurt.

Immutable snapshots: what they really are

An immutable snapshot is a point in time copy of your data that cannot be altered or deleted for a defined retention window. Not by an administrator, not by the vendor, and crucially not by an attacker who has stolen administrator credentials. That last point is the entire value. An ordinary snapshot is only ever as safe as the account that can delete it, and by the time ransomware is detonating, the attacker usually holds domain or storage administrator rights. At that point a normal snapshot is trivially removed. A properly implemented immutable snapshot is locked by the array itself, governance enforced, so even a full administrative compromise cannot shorten or delete it inside the protected window.

The detail to check is how the lock is actually enforced, because implementations vary more than the datasheets admit. Some are genuinely governance locked at the array, with no path to remove the copy early under any circumstances. Others keep a support or break glass route that a determined attacker could social engineer or abuse, which quietly reopens the door you thought you had closed. The retention model matters just as much. A copy you can only hold for a short window may age out before you have even detected the intrusion, and dwell times before detonation are routinely measured in weeks, sometimes longer. Immutability that expires inside your likely dwell time is protection in name only.

Air gaps, logical and physical

Air gap is the other word that gets stretched. In its strict sense, an air gap means the protected copy is not reachable over the network, so malware and stolen credentials simply cannot touch it. In practice the market uses the term for two quite different things, and it is worth knowing which you are being sold.

A logical or operational air gap keeps a copy on a target that is normally disconnected and only opened for a brief, controlled replication window. It is not truly offline, but the exposure window is small and the management plane is separated, which defeats most attacks. A physical air gap means the copy genuinely leaves the network, classically to tape or to removable media that is then stored offline. It is slower to recover from and more operationally awkward, but it is the hardest thing in the world for a remote attacker to reach. Neither is wrong. The point is to know which one you have, because a logical air gap with a shared management plane and shared credentials is far closer to an ordinary replica than the brochure suggests.

The part everyone underweights: recovery at scale

Most of the attention goes on the copy. Far less goes on the restore, and the restore is where real incidents are won or lost. A protected copy you cannot bring back fast enough is an academic comfort while the business is down. There is a reason the discipline separates the recovery point, how much data you lose, from the recovery time, how long you are out, and ransomware punishes the second one hard.

This is where the storage architecture earns its place. Snapshot rollback on the primary array can return a volume to a clean state in minutes, which is transformational if the clean point is on the same system and has survived. Restoring tens or hundreds of terabytes from an isolated or offline copy is a different exercise entirely, gated by the restore throughput of the target and the network between you and it. The organisations that recover well are the ones that worked out, in advance and in a test, how long a full restore of their most critical systems actually takes, and then engineered that number down. The ones that suffer are the ones who discovered the answer for the first time during the incident.

The dormant payload problem

There is a failure mode that pure immutability does nothing to solve, and it catches people out. If an attacker has been inside your environment for weeks, then your recent protected copies may already contain the dormant malware, the backdoor, or the compromised account that let them in. Restore one of those copies and you have faithfully, immutably, restored the intrusion along with the data. The encryption is gone, the attacker is back.

This is why a chain of clean restore points matters more than a single recent one, and why recovery from a serious incident is a forensic exercise, not just a button press. You need restore points that predate the compromise, a way to identify which ones are clean, and ideally a staged recovery into an isolated environment where systems can be validated before they are trusted back onto the network. Storage immutability is what makes those clean points survive. It is not what tells you which point is clean. That is a different job.

What storage genuinely cannot do

It is worth being blunt about the limits, because the honest version is more useful than the pitch. Storage resilience protects the data copy. It does not detect the intrusion, it does not stop the initial compromise, it does not clean an infected host, and it cannot tell a poisoned restore point from a clean one. It is a recovery control, not a prevention control, and it sits downstream of everything that should have caught the attacker earlier.

So immutable storage is necessary, but it is not sufficient, and any vendor implying otherwise is selling you a false sense of safety. It belongs alongside endpoint detection and response, network segmentation that stops lateral movement, hardened identity so credentials are harder to steal in the first place, a separate and equally immutable backup tier, and an incident response runbook that has been rehearsed. Storage is one strong layer in that stack. On its own it is a locked safe in an unlocked building.

How to think about it

A sensible way to frame the storage contribution is to ask three questions of every important dataset. First, do we hold a copy that an attacker with full administrative rights cannot destroy, and does its retention comfortably exceed our realistic detection time. Second, is at least one copy genuinely isolated, logically or physically, rather than a replica sharing the same credentials and management plane. Third, have we proven, by test, that we can restore the critical systems from a known clean point inside the time the business can tolerate. If the answer to all three is a confident yes, your storage layer is doing real work. If any answer is a maybe, that is where the next pound of effort should go, regardless of which logo is on the array.

Worried your storage resilience would not hold up?

Send us your situation and we will give you an independent, vendor neutral read: whether your immutable copies are genuinely locked, whether your isolation is real, and whether you could actually recover in time. We have architected and sold these platforms, so we know which protections are solid and which are marketing. No platform to sell, just the honest answer.

Name *

Company *

Work email *

Phone (optional)

Details

Send us your situation

Prefer email? Reach us directly at hello@c4cgroup.co.uk.

How C4C helps

This is exactly the kind of question we exist for. We spent years architecting and selling enterprise storage and its data protection from the inside, so we know how each vendor's immutability is really enforced, where the break glass paths hide, and which air gap claims are genuine isolation versus a replica with a friendly name. We will review your storage resilience honestly against the way ransomware actually behaves, test the assumptions that matter, and help you close the gaps that count, as one layer of a wider resilience plan. Our independence is the point. We have no array to defend and no preferred logo, so the recommendation is the one that genuinely protects your data.

Frequently asked questions