Immutable Storage: What Actually Makes a Restore Point Unalterable

Someone types immutable storage into a search box for one of two reasons. Either an auditor has asked them to demonstrate that a set of records cannot be altered for seven years, or they have just finished reading an incident write-up and want to know whether their own restore points would have survived it.

Both readers tend to get the same answer from the market, and it is the wrong shape: a list of products with the word immutable on the feature page. The word is doing very little work there. Nearly every backup product and nearly every storage platform can set an attribute that means do not delete this yet. Very few of them can tell you what happens to that attribute when the account that set it is the account the attacker is now using.

That is the whole subject. Immutability is not a property of a file format, a snapshot type, or a checkbox. It is a property of a trust boundary: the copy is unalterable exactly to the extent that destroying it requires a credential the person trying to destroy it does not have. Everything else is naming.

What a restore point has to survive to be called immutable

Before comparing anything, it is worth writing down what the comparison is for. Four questions separate the claims that hold from the ones that only sound protective, and they are worth asking in this order.

Can the credential that manages the data also destroy the copy? This is the question that decides most real incidents. An intruder who reaches your virtualization platform or your Kubernetes control plane with administrative rights does not start by encrypting data. They start by finding the recovery path and removing it, because a victim with working restore points does not pay. If your protection copies are governed by the same identity provider, the same console and the same admin group as the primary data, they are part of the blast radius rather than a boundary around it.

Can the retention window be shortened after the fact? A ninety day retention policy that can be edited to zero days is a ninety day policy only until someone edits it. The relevant property is not the length of the window but whether the window can be reduced at all, by whom, and whether reducing it leaves a record.

Does the copy survive the loss of the environment that made it? Immutability and locality are separate properties that get conflated constantly. A locked copy in a cluster that has been encrypted end to end is locked and useless. A copy is only a recovery option if it lives in a failure domain that can stay up while the primary is down, which in practice means a different cluster, a different site, or a different account.

Can you prove any of the above to somebody who does not trust you? This is the auditor’s question, and it is different from the other three. An auditor is not asking whether the data was altered. They are asking what mechanism made alteration impossible, and what evidence exists that the mechanism was in force for the whole retention period. A screenshot of a policy page answers neither.

A copy that passes all four is immutable in the way the word implies. A copy that passes the last one only, which describes a surprising amount of what gets attested to, is a compliance artifact rather than a recovery capability.

Where retention is actually enforced

There are four places the retention decision can live, and they differ enormously in what they survive. The differences are not vendor differences. They are structural, and they follow from which trust domain holds the enforcement.

In the backup catalogue. The backup product records, in its own database, that a given restore point is retained until a given date, and its own scheduler declines to reap it. This is the most common form of immutability in the field and the weakest. The software that enforces the rule is the software that can rewrite the rule, and the administrator who operates one operates both. It is genuinely useful against accident, which is most data loss, and it is close to worthless against an adversary who has taken the backup console.

In the storage control plane. The copy is a snapshot, and the storage system holds a policy that prevents deletion before an expiry. This is better than the catalogue case in one specific respect that matters: a copy-on-write snapshot is not rewritten in place, so the historical blocks are not modified by later writes to the live volume. The snapshot is genuinely a point in time rather than a file that something keeps appending to. But durability of the data layout is not the same as durability of the object. The snapshot still exists because the storage control plane says it does, and a credential that can drive the storage API can usually still delete it or shorten its policy.

In an object store, with a lock. Object stores implement retention as a property of the object itself rather than of a scheduler, and they distinguish two modes that are much more important than their names suggest. In governance mode, retention is enforced against ordinary callers but a sufficiently privileged principal can bypass it. That is a deliberate design for organisations that need an escape hatch, and it means governance mode does not survive the compromise of that privileged principal. In compliance mode, no principal can shorten or remove the retention, including the account owner. There is no bypass permission to steal. Separately, a legal hold pins an object indefinitely with no expiry date, to be released explicitly. Compliance mode is the first option on this list that survives an attacker holding your highest-privilege credential, and that is precisely because the enforcement sits in a trust domain your administrators cannot reach into.

On media that cannot be rewritten, or on no network at all. Certified write-once media and genuinely offline copies enforce retention physically. Nothing beats them on the first three questions and nothing is slower to restore from. This is the tier that exists for the obligations you cannot risk, not the tier you recover Tuesday’s database from.

Table 1 puts the same four options against the four questions. It is worth reading the third column first, because the ability to shorten a window is the property most often assumed and least often checked.

The practical conclusion is not that everyone needs compliance mode. It is that a protection design should be explicit about which of these rows each copy occupies, because most designs contain exactly one row and describe themselves in the language of another.

Not sure which of your restore points would survive a compromised platform administrator? Bring your current protection design and we will walk through which copies sit inside the blast radius and which sit outside it. Talk to a storage architect

WORM, and the question compliance asks that ransomware does not

WORM, write once read many, is the older vocabulary for the same mechanism, and it is worth keeping separate because the two audiences want different guarantees.

The ransomware reader wants a copy that an intruder cannot destroy during the window between compromise and detection. That window is the whole design input. Detection lag is measured in days to weeks far more often than in hours, so a retention window sized to the last two nightly runs is sized to lose.

The compliance reader wants something narrower and stricter: evidence that specified records were non-rewriteable and non-erasable for a defined period, produced by a mechanism rather than by a promise. Financial-services record-keeping rules have historically required exactly that phrasing, and several regimes now also accept an audit-trail based alternative that proves alterations are detectable rather than impossible. Which regime applies to you, and whether a given configuration satisfies it, is a determination for your compliance function and your auditor. No storage vendor, including this one, can make that determination on your behalf, and treating a product datasheet as a compliance opinion is how organisations end up re-doing the work.

Two practical notes that matter more than the terminology.

• WORM is a property of a specific copy, not of a system. A platform that supports locked object storage does not make your snapshots WORM. The copy you want to be unalterable has to be the copy that is actually written to the locked target, on a schedule, with restores tested from it.
• Retention costs capacity, and capacity is where immutability quietly dies. You cannot delete a locked copy early, which is the point, so a retention policy is a standing commitment to hold every restore point for its full window. Teams under capacity pressure shorten windows rather than buy hardware, and the window they shorten is the one that would have covered a slow-detection incident. Sizing the capacity honestly at design time is part of the immutability decision, not a separate procurement conversation.

What the storage layer contributes, and what it does not

This is the part where a vendor post usually overstates, so here is the boundary first.

Simplyblock is not a backup product and does not replace one. The catalogue, the index that finds a single file inside a VM disk, granular file-level restore, the retention policy engine, long-term tiering and compliance reporting are backup-product functions and they stay that way. Nor does the block layer issue a compliance attestation: if your auditor requires certified non-rewriteable retention, the enforcement point is a locked object store or certified media, and the honest architecture puts it there rather than claiming the block layer covers it.

What the storage layer does decide is the quality and the cost of the point-in-time copy everything else is built from, and that turns out to matter in four specific ways.

• The primitive itself. CSI snapshots and clones give a consistent point-in-time image at the volume layer, which is what a backup product needs in order to read a coherent copy in the first place. Because it sits at the volume, it behaves identically under KubeVirt, Red Hat® OpenShift® Virtualization, bare-metal Kubernetes and containerised workloads, so a protection design is rebuilt once rather than once per platform.
• The cost of keeping more restore points. Erasure coding at roughly 1.25:1 overhead at FTT1, against three-way replication’s 3:1, changes how many restore points a given hardware budget holds. That ratio is the difference between a retention window you can defend and one you shorten under pressure. Based on publicly available information as of September 2026, and not independently verified.
• The blast-radius boundary. Cross-cluster replication puts a copy in a second cluster, which is a second failure domain. Whether it is also a second trust domain is a decision you make, not a property you inherit: separate credentials, separate identity scope and separate administrative groups are what turn a replica into a boundary. Replication with shared administrative access is high-availability engineering, not ransomware protection, and it is worth being clear internally about which one you have built.
• Getting back. Policy-based fallback to an earlier snapshot, and live migration of volumes on fail-back, decide whether recovery is a routine operation or a project. A recovery path that nobody rehearses because rehearsing it is expensive is a recovery path with an unknown success rate.

On price, because it interacts with retention directly: simplyblock is priced like the platform it runs on, by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. For a retention decision that mostly means the pricing model does not itself argue against holding more restore points.

For comparison, ODF and Ceph are a reasonable place to look if your priority is a broad open-source data platform and performance is not the main goal, which is a genuine and defensible position. What they do not ship is backup and restore as a native platform capability, and several of the DR capabilities buyers assume are included sit behind ODF Advanced, a separate licence included in neither OpenShift Container Platform nor OpenShift Platform Plus. If the retention plan depends on capabilities that turn out to be a second purchase, that is better discovered during design than during the first restore test.

The short version of all of it: decide which trust domain holds each copy, write it down, then test a restore from the copy you are counting on. If you have already worked through ransomware recovery for Kubernetes storage or rebuilt a backup estate after a VMware® exit, this is the layer underneath both of those decisions.

Questions and Answers

What is immutable storage, and what actually makes a restore point unalterable?

Immutable storage is storage where a written copy cannot be modified or deleted before a defined retention period expires. The property that makes it real is not the file format or the snapshot type, it is the trust boundary: a copy is unalterable exactly to the extent that destroying it requires a credential the attacker does not hold. A retention flag set in a backup catalogue and enforced by the same admin account that manages the data is immutability in name only. Retention enforced by an object store in compliance mode, or by write-once media, survives the compromise of your highest-privilege account because there is no bypass permission to steal.

Is an immutable snapshot the same thing as an immutable backup?

No, and conflating them is the most common design error in this area. A copy-on-write snapshot is a genuine point in time, because later writes to the live volume do not rewrite the snapshot’s blocks, but the snapshot object still exists at the discretion of the storage control plane and can usually be deleted by a credential that can drive the storage API. An immutable backup is a copy written out to a target that enforces retention independently, ideally in a different trust domain. Use snapshots for fast, frequent, local recovery points, and treat a locked off-platform copy as the thing that survives a bad day.

What is WORM storage, and do I need it?

WORM stands for write once read many: once written, a record cannot be rewritten or erased for its retention period. You need it when a regulator or a contract requires demonstrable non-erasability of specific records, which is a narrower requirement than ransomware resilience. Many teams need strong ransomware protection and do not need certified WORM; teams in regulated record-keeping usually need both, for different data, with different retention. Whether a given configuration satisfies a given regime is a determination for your compliance function and your auditor, not something a storage datasheet settles.

Does simplyblock provide immutable storage?

Simplyblock provides the pieces the storage layer is responsible for and is explicit about the ones it is not. It supplies the consistent point-in-time primitive through CSI snapshots and clones, S3 backup and restore as a native platform capability, cross-cluster replication so a copy can live in a separate failure domain, and policy-based fallback to an earlier snapshot for the recovery path. It is not a backup product: catalogue, indexing, file-level restore, retention policy engine and compliance reporting remain backup-product functions. If you need certified non-rewriteable retention for an auditor, put that enforcement in a locked object store or on certified media and let the block layer supply the copy.

How long should the immutability window be?

Size it against detection lag, not against your backup schedule. Intrusions are commonly discovered days or weeks after initial access, so a window that covers only the last few nightly runs can expire before anyone knows there is a problem. A frequently cited baseline is somewhere between thirty and ninety days for the locked copy, with more frequent short-lived snapshots in front of it for routine recovery. The real constraint is capacity, because a locked copy cannot be deleted early by definition, so decide the window and buy the capacity for it together rather than discovering the conflict when the pool fills.

Are ODF or Ceph a good choice for immutable restore points?

Ceph, and ODF built on it, are a good option when you want a broad open-source data platform and performance is not the main goal. For this particular job the thing to check is what ships and what is licensed separately: neither ODF edition includes backup and restore as a native platform capability, and DR capabilities such as metro synchronous and regional asynchronous replication require ODF Advanced, which is a separate per-two-core licence included in neither OpenShift Container Platform nor OpenShift Platform Plus. Those are the rows to verify against your own retention plan before the design is fixed. Based on publicly available information as of September 2026.