Immutable backups are copies the storage refuses to change or delete for a set retention period, regardless of who asks. Object lock has two modes: governance can be bypassed by anyone with the permission, compliance cannot be bypassed by anybody. For ransomware, only one of them is a control.
- Enforced by the storage, below the permission layer
- Governance mode has a bypass. Compliance mode does not
- Retention must outlast the time to notice an intrusion
- It is not retroactive: only data written after it was enabled
- It answers availability, and nothing about exfiltration
On this page
The mechanismWhat makes a backup immutable
Ordinary backups are protected by access permissions. Somebody has the right to delete them, which means somebody's stolen credentials also have that right. That is the entire problem the 3-2-1 rule cannot solve on its own: three copies of the data protected by one account are three copies an attacker can reach.
Immutability moves the decision out of the access control system. The storage platform is told that this object may not be modified or deleted until a stated date, and it enforces that regardless of the credentials presented. There is no administrative override in the strong version, which is the point of the protection rather than an inconvenience.
Three properties follow, and the third is the one that catches people.
It is enforced below the access control layer. No role, no policy and no compromised key changes the answer.
It is time bound, not permanent. Immutable backups carry a retention date, after which the data becomes an ordinary object again. Choosing that date is the real decision.
It cannot be undone early. Deleting the data before the retention expires is impossible by design, which means the storage cost is committed for the whole period. That is a budget consequence and it is the usual reason organizations choose too short a window.
The two modesThe two modes, which are not interchangeable
Cloud object lock offers two retention modes. Vendor documentation presents them as options. For ransomware protection they are not options, and choosing wrongly produces immutable backups that are not.
Governance mode. The data is protected from ordinary deletion, and a user with a specific bypass permission can remove the lock and delete it anyway. It exists so that a mistake, a wrong retention date or a test dataset, can be corrected without waiting years.
Compliance mode. The object cannot be deleted or modified by anybody until the retention expires. Not by an administrator, not by the account owner, not by the root credentials, and not by the vendor's support team. The retention period can be extended and never shortened.
The difference matters because of who you are defending against. A ransomware operator who has compromised your environment has, in the usual case, obtained administrative access. Governance mode assumes the person holding those credentials is you.
| Governance mode | Compliance mode | |
|---|---|---|
| Protects against accidental deletion | Yes | Yes |
| Protects against a compromised admin | No | Yes |
| Retention can be shortened | Yes, with the bypass | No |
| Retention can be extended | Yes | Yes |
| A wrong setting can be corrected | Yes | No, you wait it out |
| Appropriate for ransomware defense | No | Yes |
There is a third control worth knowing, the legal hold: an indefinite lock with no retention date, applied and removed by a user with permission. It is for litigation rather than for ransomware, and it can be lifted by whoever holds that permission, so it is not a substitute.
RetentionChoosing the retention period
The retention window is the setting that decides whether an immutable backup helps, and the reasoning is not about storage cost even though the storage cost is what people optimize.
Retention has to outlast detection. Ransomware operators are commonly inside a network for weeks before they encrypt anything, and during that time the backups run normally and capture the compromise. A fourteen day lock on a network compromised for thirty days holds fourteen days of already encrypted data, perfectly protected and useless for recovery.
Thirty days is a floor, not a target. Long enough to cover a typical dwell time and short enough that the storage bill stays reasonable. Sixty to ninety days is a better answer for any data you could not rebuild.
Different data deserves different windows. The daily backups of a busy file server and the monthly archive do not need the same retention, and treating them separately is how most organizations keep the cost sensible.
The trap is doing this arithmetic on the backup schedule instead of on the threat. A retention that covers your restore point objective is a retention that covers accidents. Covering an attacker means covering the time between the intrusion and the moment somebody noticed.
The limitsWhat immutability does not do
It is a strong control with a narrow scope, and four things sit outside it.
It does not stop data exfiltration. A copy of the data was taken before anything was encrypted, and the threat to publish it is unaffected by how well the backups are protected. Immutability answers the availability half of the attack and none of the security half.
It does not protect data that was never locked. Objects written before object lock was enabled, or into a bucket without it, are ordinary objects with ordinary access rules. Enabling it is not retroactive.
It does not protect the account. Depending on the platform, an entire account or subscription may still be closable, which takes the storage with it regardless of what is locked inside. Account level protections are a separate control.
It does not make the backup correct. An immutable copy of broken data is broken data that cannot be deleted. Verifying that recovery works is still a separate step, and the one people skip.
One more thing does not count, despite appearing in search results: the immutable attribute on a Linux filesystem, set with chattr +i. Root can remove it with one command, which makes it a guard against accidents and not against an attacker who is already root.
VerificationVerifying it, which takes five minutes
An immutable backup is a configuration claim until somebody tests it. The test is short and worth scheduling.
| Check | What it catches | How often |
|---|---|---|
| Try to delete a locked object | A lock that is not enforced at all | Quarterly |
| Read the retention mode, not the label | Governance where you assumed compliance | Once, then after any change |
| Read the retention date on a real object | A policy that never applied | Quarterly |
| Confirm the backup software sets a lock | Objects written with no retention at all | Once, then after an upgrade |
| Restore something | Locked data that does not come back usable | Quarterly |
Try to delete a locked object, and confirm you cannot. Use the account with the most access you have. A delete that succeeds means the lock is not what you think it is, which is the finding worth having before a ransomware incident rather than during one.
Check the mode explicitly, not the label. A console that says immutability is enabled does not say which mode. The distinction is the whole control.
Check the retention date on a real object, not the policy that was supposed to apply it. Policies get changed, and objects written before the change keep the old date.
Confirm the backup software is actually using it. Some products write to object storage without setting a lock unless told to. The bucket having the feature and the objects carrying a retention date are two different facts.
Restore something. Immutability guarantees the data is unchanged and says nothing about whether recovery produces a working system.
RecoveryRecovering from them, which is not the same as restoring
Immutable backups exist for one moment, and the recovery has an order that matters more than the technology does.
Do not restore into the environment that was compromised. The data is clean and the network is not. Restoring a file server into a domain the attacker still has access to returns you to the same position with fresher data.
Rebuild the platform first, restore the data second. Operating systems, domain controllers and applications get rebuilt from installation media and configuration, not from a backup taken during the intrusion. Only the data comes back from the backups.
Pick a recovery point before the intrusion started, not before the encryption. The encryption is the last step of an attack that began weeks earlier, and the useful restore point is on the far side of the beginning.
Reset every credential before anything reconnects. Domain accounts, service accounts, API keys and the backup account itself, which the attacker was specifically looking for.
Expect the restore to be slower than the backup was. Cloud object storage is priced and engineered for writing, and pulling terabytes back over a business internet connection is measured in days. That number belongs in the recovery plan rather than in the incident.
The organizations that recover quickly are the ones that had done a restore before they needed one. Immutability guarantees the data survived. It guarantees nothing about how long the recovery takes, and that is the number the business actually cares about.
PitfallsWhere people go wrong
Choosing governance mode. It is the default in several interfaces and it has a bypass, which means compromised administrative access defeats it. For ransomware protection the answer is compliance mode.
Setting retention shorter than dwell time. Fourteen days of protected backups on a network that was compromised for a month protects the wrong fourteen days.
Enabling it and assuming old backups are covered. It applies to objects written after it was turned on. Everything already there is unchanged.
Treating it as a substitute for offsite copies. Immutability protects data from being changed. It does not put that data anywhere else, and locked backups in a building that burns down are gone.
Forgetting the cost is committed. You cannot delete early, so a ninety day lock on a large dataset is ninety days of storage you have agreed to pay for whatever happens.
Using the Linux immutable flag as the control. Root removes it in one command, and an attacker on that machine is root.
Never testing a delete. The configuration and the behavior disagree more often than anybody expects, and the only way to know before a recovery is to try.
ComparisonThree kinds of copy, and what each one survives
| Criterion | Ordinary backup | Immutable backup | Air gapped copy |
|---|---|---|---|
| Survives a stolen admin credential | No | Yes, in compliance mode | Yes |
| Survives the building burning down | Only if offsite | Only if offsite | Usually, it is elsewhere |
| Available in minutes | Yes | Yes | No, it has to be fetched |
| Can be deleted early if wrong | Yes | No | Yes |
| Ongoing cost | Lowest | Committed for the retention | Media and handling |
| Needs somebody to do something | No | No | Yes, and that is the weakness |
The last row is the honest comparison between the two strong options. Air gapped media is unbeatable while it is disconnected and it depends on a person performing a task every week. Immutability needs nobody, and it is only as good as the mode somebody selected once.
FAQFrequently asked questions
What are immutable backups?
Backups the storage itself will not change or delete for a set retention period, regardless of the access rights of whoever asks. Immutability is enforced below the permission layer rather than by it.
How are they different from read only backups?
Read only is an access permission, and permissions are changed by anybody with enough rights. Immutability is enforced by the storage and cannot be overridden, in compliance mode, by any credential at all.
What is object lock?
The cloud storage feature that implements immutable backups. It marks the data with a retention date and refuses modification or deletion until that date passes.
What is the difference between governance and compliance mode?
Governance mode can be bypassed by a user holding a specific permission. Compliance mode cannot be bypassed by anybody, including the account owner, until retention expires.
Which mode should I use for ransomware protection?
Compliance mode. A ransomware operator in your environment usually holds administrative access, which is exactly what governance mode assumes belongs to you.
How long should the retention period be?
Longer than the time it takes to notice a compromise. Thirty days is a floor, sixty to ninety is better for anything you could not rebuild, and the calculation is about dwell time rather than about your backup schedule.
Does object lock apply to existing backups?
No. It applies to data written after it was enabled. Anything already in the bucket stays as it was.
Do immutable backups stop data being stolen?
No. They protect availability, not confidentiality. Data exfiltrated before the encryption is unaffected by how well the backups are locked, which is the security limit of the control.
Does an immutable backup still need to be offsite?
Yes. Immutability protects a copy from modification and does nothing about the building it sits in. It is one part of a backup strategy rather than a replacement for one.
Can I delete immutable backups if I made a mistake?
In governance mode, yes, with the bypass access permission. In compliance mode, no. That is the trade, and it is why the retention period deserves thought before it is set.
Is tape immutable?
Once it is out of the drive, effectively yes, and it is air gapped as well. The weakness is that somebody has to physically handle it on a schedule.
Does the Linux immutable flag count?
No. chattr +i is removed by root with one command, and an attacker who reached the filesystem is root. It guards against accidents, not against an intrusion.
How do I know immutability is actually working?
Try to delete a locked object with your most privileged account and confirm it fails. Then check the mode and the retention date on a real object rather than on the policy meant to apply them.
What is WORM storage?
WORM stands for write once, read many. WORM storage accepts data and then refuses any change or deletion until a retention period ends. Tape, optical disc and object storage with object lock all work this way. It is the property that makes a backup immutable.
How do immutable backups help ransomware recovery?
Ransomware operators delete or encrypt backups before they reveal themselves, because a victim with good backups does not pay. An immutable copy cannot be altered even with stolen administrator credentials, so ransomware recovery starts from a known clean point instead of from a negotiation.
Keep readingRelated concepts
Read next · Shared storage NAS vs SAN The local backup target is usually a NAS, and whether it can enforce retention at all is worth checking before buying. Open this next12 min- Backup · 13 min The 3-2-1 Backup Rule, and What Ransomware Did to It Three copies protected by one account are three copies an attacker can reach, which is the gap immutability fills.
- Operations · 13 min Patch Management, and Why the Hard Part Is Not the Patching The intrusion that makes the retention window matter usually arrived through something unpatched.
- Managed IT · 10 min What Backup and Disaster Recovery Actually Buys You Why the copies survive.
- Disks and drives · 9 min Btrfs vs ext4, and When Snapshots Are the Point Why a file system snapshot lives on the same disk, and what ext4 and Btrfs each give you.
- Platforms · 11 min OneDrive vs SharePoint, and What Happens When Someone Leaves Why a grace period is not the same as a protected copy.