An immutable backup is a copy of data that cannot be modified or deleted for a defined retention period, by anyone, including an administrator with full privileges. The retention period is set when the data is written and enforced by the storage layer rather than by permissions, which is what makes it different from a backup that is merely protected by access control.
The reason it matters is narrow and important. Ransomware operators target backup repositories, because an organization that can restore does not need to pay. Immutability removes deletion as an option during the window it covers, which means a known-good copy still exists when the negotiation would otherwise begin.
That is the whole value, and it is worth being precise about the boundaries of it, because immutability is sold as a great deal more than that.
How immutability actually works
The mechanism is retention enforced at the storage layer. When an object is written to a repository with immutability enabled, a retention period is applied to it. Until that period expires, delete and overwrite operations against the object fail, regardless of who issues them or what credentials they hold.
Object storage is the most common implementation, using object lock. Backup platforms including Veeam support this natively against object storage repositories, and Veeam’s documentation sets out which repository types support it and how the retention period is applied. Hardened Linux repositories and purpose-built appliances offer equivalent behavior by different means.
The important design principle is that immutability is enforced below the level an attacker operates at. Access control can be defeated with sufficient privilege. A storage-layer retention period cannot, which is why immutability is a meaningfully different control rather than a stricter version of an existing one.
Immutable is not the same as air-gapped
These get used interchangeably and they solve different problems.
Immutable means the copy cannot be changed or deleted for a period. It is typically online and reachable.
Air-gapped means the copy is isolated from the production network, physically or logically, so an attacker who is inside your environment cannot reach it at all.
Immutability protects a copy an attacker can see. An air gap means they cannot see it. The 3-2-1-1-0 rule calls for one copy that is immutable or air-gapped, and organizations with a serious ransomware posture generally end up with both, applied to different copies.
What immutability does not protect against
This is the section the rest of the internet leaves out.
It does not prevent an intrusion. Immutability is a recovery control, not a preventive one. An attacker with access to your environment still has access to your environment.
It does not prevent data exfiltration. Double extortion, where data is stolen as well as encrypted, is unaffected. Your ability to restore does not stop anyone publishing what they took, which means immutability reduces the operational impact of an attack without removing the commercial or regulatory one.
It does not help if what you captured was already compromised. If encrypted or corrupted data was backed up before anyone noticed, immutability faithfully preserves it. This is precisely why the zero in 3-2-1-1-0, verified recovery, exists alongside the immutable copy. Immutability guarantees the copy survives, not that it is any good.
It does not shorten your recovery time. A protected backup you can restore from is not the same as a fast recovery. Restoring a large estate takes as long as it takes, and immutability changes nothing about that number.
It does not cover what you did not back up. Immutability applies to the copies in the repository. Anything outside the backup scope is outside the protection, and backup scope tends to drift as environments change.
None of this makes immutability less valuable. It makes it a specific control with a specific job, which is the only way to deploy anything properly.
The four ways immutability fails in practice
The retention period is shorter than the dwell time. Attackers frequently remain in an environment for weeks before triggering encryption. If your immutable retention is seven days and the compromise began five weeks ago, every immutable copy you hold may already contain compromised data. Retention should be set against how long you might realistically take to detect an intrusion, not against how much storage you want to pay for.
The credentials that write the backups can also change lifecycle policy. Immutability enforced by a retention setting is only as strong as the permissions governing that setting. An account that can shorten a retention policy, or move objects to a bucket without one, can undo the protection. This is the most common misconfiguration and it is invisible until tested.
Immutability is applied to the wrong copy. Enabling it on a local repository an attacker can reach, while the off-site copy has no retention lock, produces a protection that does not survive the scenario it was bought for.
Nobody has tested a restore from the immutable copy. Restoring from an immutable repository sometimes behaves differently from a routine restore. If the first time you find out is during an incident, immutability has bought you a copy and not a recovery.
How long should the retention period be?
There is no universal number, and anyone who gives you one without asking questions is guessing.
The useful way to arrive at it is to work from detection rather than from storage cost. Ask how long a compromise could plausibly go unnoticed in your environment, given your monitoring and your team’s capacity. Your immutable retention needs to be longer than that, or the clean copy expires before you know you need it.
Then check it against any regulatory retention obligation you carry, which may set a longer floor. And then check the cost, which is where the conversation usually starts and should not.
Frequently asked questions
What is an immutable backup? A backup copy that cannot be modified or deleted for a set retention period, enforced by the storage layer rather than by permissions, so that not even an administrator can remove it during that window.
Is immutable backup just a marketing term? No. The underlying mechanism, storage-layer retention that rejects delete and overwrite operations, is real and verifiable. What is oversold is the scope: immutability protects the copy, it does not prevent intrusion, exfiltration or a slow recovery.
What is the difference between immutable and air-gapped backups? Immutable means the copy cannot be changed for a period. Air-gapped means the copy is isolated from the network. Immutability protects a copy an attacker can reach; an air gap means they cannot reach it.
Can ransomware delete immutable backups? Not during the retention period, if immutability is configured correctly. The realistic risk is not that the lock fails but that it was applied to the wrong copy, given too short a retention period, or left changeable by the same credentials the attacker obtained.
How long should immutable retention be? Longer than the time it would plausibly take you to detect an intrusion, and at least as long as any regulatory obligation you carry. Setting it from storage cost alone is the common mistake.
Does immutability replace testing? No. Immutability guarantees the copy still exists. Verified recovery testing is what tells you the copy is usable, which is why 3-2-1-1-0 includes both.
Where Opti9 fits
Opti9 delivers managed backup built on Veeam as a Veeam Platinum VCSP Partner, with immutable copies configured as part of the design rather than as an option to enable later. Opti9 Observr adds ransomware prevention, verified by CyPROS, alongside the recovery layer. The distinction that matters is that immutability is designed against a retention period derived from the customer’s environment, and tested, rather than switched on and assumed.
