Immutable backup is the difference between a bad fortnight and a business that does not reopen. Everything else in a recovery plan — the runbooks, the retainer, the incident bridge — assumes there is something clean left to restore from. Modern ransomware crews know that, which is why the encryption of production data is now the second thing they do. The first is finding your backups and deleting them.
That shift is why the old 3-2-1 rule quietly stopped being enough. Three copies on two media with one offsite protects you beautifully against a failed disk, a flooded server room or a deleted folder. It does nothing at all against an attacker holding domain admin credentials who can browse to the backup console and hit purge. The 3-2-1-1-0 backup strategy adds the two digits that close that gap: one immutable backup that cannot be changed or deleted by anyone, and zero errors on a restore you have actually tested.
This guide covers what an immutable backup genuinely is at the storage layer rather than in the marketing copy, how each digit of 3-2-1-1-0 is proved, what the lock window costs in real storage, and the mistakes that turn a technically correct configuration into an audit failure. It is written for the person who has to defend the design to a board, an insurer or a regulator — not for a product comparison.
None of this is exotic any more. Object lock is a checkbox on every major cloud platform, hardened repositories ship in mainstream backup software, and the whole arrangement usually costs less than the excess on a cyber insurance policy. The reason most businesses still do not have an immutable backup is not budget. It is that nobody was ever asked to prove it.
Table of contents
- What an immutable backup actually is
- The 3-2-1-1-0 immutable backup rule, line by line
- How immutable backup storage is enforced
- What ransomware does when there is no immutable backup
- Choosing the immutable backup retention window
- What an immutable backup costs, and where the money goes
- Verifying the immutable backup: the zero nobody tests
- Immutable backup mistakes that fail an audit
- A 90-day immutable backup rollout plan
- Frequently asked questions about immutable backup
- References
What an immutable backup actually is
Write once, read many, no exceptions
An immutable backup is a copy that cannot be modified, overwritten or deleted for a defined period, by anybody — including the account that created it, including the storage administrator, and including someone holding your entire credential set. The enforcement lives below the backup application, in the storage platform itself, which is the whole point. A setting your backup server can revoke is not immutability; it is a preference.
The model comes from WORM storage — write once, read many — which regulated industries have used for decades. What changed recently is that object storage made it cheap and API-driven rather than an appliance purchase.
Immutability is not the same as read-only
Read-only permissions are enforced by an access control list, and access control lists are edited by administrators. An attacker who has spent three weeks inside your network is, by that point, an administrator. Every read-only flag they encounter is simply a flag they turn off.
True immutability is enforced by a retention timestamp held by the storage layer, and the storage layer refuses the delete regardless of who is asking. There is no override, no support ticket that unlocks it early, and no emergency exception. That absence of an escape hatch is uncomfortable the first time you configure it, and it is exactly the property that makes an immutable backup worth having.
Immutable is not the same as offline
An air-gapped tape in a fire safe is offline. It is unreachable over the network, which is a genuinely strong control and also a slow one — someone has to drive to the safe. An immutable backup sitting in object storage is online, instantly restorable, and protected by policy rather than distance.
The two solve overlapping problems with different trade-offs, and a mature design usually keeps both. The 3-2-1-1-0 backup strategy is deliberately written so that the “1” can be satisfied by either, provided it is genuinely one or the other.
Why versioning and snapshots do not count
Snapshots are the most common false positive in this whole area. A storage snapshot is fast, cheap and useful, and it is also deletable by whoever administers the array. Cloud object versioning has the same weakness: an attacker with the right permissions deletes the versions and then empties the bin.
Neither becomes an immutable backup until a lock policy is applied on top, and the lock is what does the work. If you can find a sequence of clicks that removes the data early, so can somebody who wants to.
| Property | Conventional backup copy | Immutable copy |
|---|---|---|
| Who can delete it | Any backup or storage admin | Nobody, until the lock expires |
| Where the control lives | Access control list | Storage retention timestamp |
| Survives stolen admin credentials | No | Yes |
| Survives a malicious retention change | No | Yes, in compliance mode |
| Emergency early deletion | Routine | Impossible by design |
| Typical restore speed | Minutes to hours | Minutes to hours |
| Storage cost | Baseline | Baseline plus lock-window overhead |
The 3-2-1-1-0 immutable backup rule, line by line
3 — three copies of the data
One production copy and two backups. The reason it is three rather than two is arithmetic: two copies means a single failure leaves you with no margin, and backup jobs fail more often than anyone likes to admit. Count copies of the data, not of the media — two backup files on the same volume are one copy wearing a disguise.
2 — on two different media types
Different media fail in different ways and for different reasons. Disk, object storage, tape and a separate cloud platform all have distinct failure modes, and putting two copies on the same technology means one systemic fault takes both. In practice most businesses now read this digit as “two different platforms” rather than two physical media formats, which is a reasonable modernisation.
1 — one copy offsite
Offsite protects against the site-level event: fire, flood, theft, a burst pipe above the comms room. It must be far enough away that one incident cannot reach both locations, which for most UK businesses means a different town rather than a different floor.
1 — one copy immutable or offline
This is the digit that was added for ransomware, and it is the one most designs get wrong. It requires a copy that an attacker with full administrative control cannot destroy. An immutable backup in object storage satisfies it. So does genuinely disconnected tape. A second replicated appliance managed by the same credentials does not.
0 — zero errors on restore verification
The last digit is the only one that tests reality. It requires that recovery has been performed and verified, not that the backup job reported success. A green job status confirms that bytes were written; it says nothing about whether the immutable backup you are holding boots, whether the database inside it is consistent, or whether the application starts.
Why the order matters when you build it
Work the digits left to right and you will build something coherent. Work them right to left — buying an immutable backup first and worrying about coverage later — and you end up with one very well protected copy of an incomplete dataset. Coverage before hardening, every time.
| Digit | Requirement | How you prove it | Shortcut that breaks it |
|---|---|---|---|
| 3 | Three copies of the data | Inventory listing production plus two backups | Counting two files on one volume as two copies |
| 2 | Two different media or platforms | Named platform per copy | Two arrays from the same vendor, same firmware |
| 1 | One copy offsite | Physical or region address of the second site | A second rack in the same building |
| 1 | One copy immutable or offline | Failed delete attempt, logged and dated | Replication under the same admin credentials |
| 0 | Zero errors on verified restore | Restore report with application-level checks | Treating a green job log as verification |
How immutable backup storage is enforced
Object lock in governance and compliance mode
Object lock is the mainstream mechanism, and it comes in two flavours that behave very differently under attack. Governance mode lets a sufficiently privileged account shorten or remove the lock — useful for correcting mistakes, useless against a compromised administrator. Compliance mode allows no override at all, by anyone, until the timestamp passes.
For the ransomware use case, compliance mode is the only setting that makes an immutable backup honest. Governance mode is a good default for a first month of learning, and a bad final answer.
Hardened repositories on immutable Linux
Mainstream backup platforms also offer a hardened repository: a Linux host with no domain membership, no shared credentials, single-use tokens, and an immutability flag applied to backup files at the filesystem level. The backup server can write new files but cannot delete existing ones before their flag expires.
This is a strong pattern precisely because the backup server holds no credential capable of destroying anything. Compromising the console gets an attacker the ability to create noise, not to erase history. It is how most on-premises immutable backup deployments begin.
Tape, which is still undefeated
Tape is unfashionable and remains the cheapest true air gap in existence. Once a cartridge leaves the library it is not reachable by any attacker on any network, and the media cost per terabyte for long retention is difficult to beat. The trade-off is recovery speed and a human logistics process that has to actually happen.
Where the immutable backup should sit
Put the locked copy on a platform whose control plane is separate from your production identity provider. If the same single sign-on tenant that an attacker compromised also administers the backup platform, your immutable backup is doing more work than it should have to. Separation of the control plane is the quiet second half of the design, and it belongs in the same conversation as your wider cloud infrastructure architecture.
The scale of the threat is what justifies the effort. Vendor research published by Sophos in 2024 found that in almost every ransomware incident, the attacker went looking for the backups first.
What ransomware does when there is no immutable backup
Dwell time is the whole game
Intrusions are rarely same-day events. Attackers commonly sit inside a network for days or weeks, escalating privilege, mapping the estate and reading documentation. Somewhere in that window they find the backup console, and it is usually documented in the same wiki as everything else.
The encryption event you eventually notice is the last step of a long project, not the beginning of one.
The deletion happens before the encryption
The sequence is consistent enough to plan around. Backups are discovered, retention policies are shortened or jobs deleted, replication is broken, and only then is production encrypted. By the time an alert fires, the recovery path has already been dismantled — quietly, using legitimate tools and legitimate credentials, which is why endpoint detection often does not flag it. An immutable backup is the one asset in that sequence they cannot touch.
Why credential theft beats every software control
If the control that protects your backups is enforced by software that accepts an administrator’s instruction, then stealing an administrator is a complete bypass. This is not a flaw in any particular product; it is the architecture. Strong managed detection and response shortens dwell time and raises the chance of catching the reconnaissance, but it is a probability improvement rather than a guarantee.
An immutable backup is not a probability improvement. The delete request simply fails.
The insurance and regulatory angle
Insurers increasingly ask about your immutable backup arrangements directly in the proposal form, and a wrong answer can affect both premium and cover. Regulators are less prescriptive but arrive at the same place: the ICO’s security guidance expects that personal data can be restored in a timely manner after an incident, which is difficult to claim when the only copies were deletable. Treat the design as a compliance artefact as well as a technical one.
Choosing the immutable backup retention window
Long enough to outlast the dwell time
The lock window has one job: it must be longer than the time between the attacker’s first access and your discovery of the incident. If they were inside for five weeks and your immutable backup locks for seven days, every locked copy already contains their handiwork. Fourteen days is a common floor and a thin one; thirty days is the more defensible answer for most businesses.
The dwell-time question you have to answer honestly
Ask how long a competent intruder could plausibly remain undetected on your network, then ask who would notice and how. If the honest answer is “we would probably find out when something stopped working”, your immutable backup lock window needs to be measured in weeks rather than days, and your monitoring needs a separate conversation.
Tiering the window rather than flattening it
You do not need the same retention on everything. A workable pattern locks daily copies for thirty days, weekly copies for ninety, and monthly copies for a year, with only the monthly set held in the coldest storage tier. That structure gives you deep history without paying premium rates to keep every daily immutable backup for twelve months.
What you cannot do once the lock is set
Be clear with stakeholders before you enable compliance mode: locked data cannot be deleted early, and that includes data you later wish you had not written. Two consequences follow. Storage costs are committed for the duration of the window, and a subject erasure request cannot reach into a locked copy until it expires. Both are manageable, and both are much easier to explain in advance than during an audit — document the position alongside your wider data protection records.
| Mechanism | Enforced by | Typical lock window | Weak point to watch |
|---|---|---|---|
| Object lock, compliance mode | Storage platform, no override | 14 to 90 days | Cost is committed for the full window |
| Object lock, governance mode | Storage platform, privileged override | 7 to 30 days | A compromised admin can remove the lock |
| Hardened Linux repository | Filesystem attribute, no domain trust | 7 to 30 days | Host patching and physical access |
| Immutable vault in a backup service | Cloud provider policy | 14 to 365 days | Same tenant as production identity |
| Offline tape | Physical disconnection | Months to years | Human process and restore speed |
What an immutable backup costs, and where the money goes
Storage overhead is the real line item
The licence rarely changes. What changes is how much data you are holding, because a lock window prevents the normal expiry that keeps a repository flat. Copies you would previously have aged out now sit there until their timestamp passes, and the steady-state footprint of an immutable backup repository grows accordingly.
The practical rule is that the overhead scales with the lock window divided by the backup interval, softened considerably by deduplication and incremental chains.
Egress and restore charges nobody budgets
Storing data cheaply is easy; getting it back in a hurry is where cloud bills surprise people. Check the egress rate and any early-retrieval penalty on the tier you have chosen, then multiply by the volume you would actually pull during a full recovery. A tier that is superb for archive can be painful for the one day you genuinely need it.
The comparison that makes the case
Set the annual storage overhead against the cost of a week of downtime for your business, and the arithmetic usually stops being interesting very quickly. For most small and mid-sized organisations an immutable backup adds a modest recurring cost to protect against a loss that would be measured in months of profit.
Where a provider adds or removes value
If the arrangement is run for you, the questions worth asking are about proof rather than product: which mode is enabled, what the window is, who holds the credentials that could change it, and when a restore was last verified end to end. Any competent managed IT services partner should answer all four without needing to check.
Verifying the immutable backup: the zero nobody tests
A green job is not a restore
Backup software reports on whether it finished writing. It cannot report on whether the thing it wrote is usable, because that requires bringing the data back and asking the application. The gap between “job succeeded” and “service restored” is where most recovery plans quietly fail, and it is invisible until the day it matters. An immutable backup nobody has ever restored from is a hypothesis, not a control.
What a real verification looks like
Restore to an isolated network, boot the system, start the application, and have somebody who uses it daily confirm that the data looks right. Then write down how long the whole thing took. That number is your real recovery time objective, as opposed to the one in the policy document.
Test the immutable backup specifically
It is easy to test the convenient copy — the local one, the fast one, the one you restore from every week for routine file recovery. The copy that matters on the worst day is the locked one, and it is often the least exercised. Restore from the immutable backup at least twice a year, deliberately, and record the result.
Rehearse the credential loss too
Run one exercise on the assumption that your identity platform is compromised and every administrative account is untrusted. Who can reach the locked copy? With what credential, stored where? If the honest answer involves a password manager that lives inside the domain you have just assumed is owned, you have found a real gap, and it costs nothing to fix on a quiet Tuesday.
Immutable backup mistakes that fail an audit
Locking the copy but not the catalogue
The data is locked and the metadata is not. An attacker who destroys the backup catalogue leaves you with an immutable backup of opaque objects and no index describing what any of them are. Protect the catalogue with the same rigour, or verify that your platform can rebuild it from the locked data alone.
Using governance mode and calling it an immutable backup
Governance mode with a privileged override is a perfectly reasonable operational setting and it does not satisfy the fourth digit. If a sufficiently senior account can shorten the retention, then so can an attacker who has that account. Say which mode you use, in writing, and expect to be asked.
One tenant, one identity, one blast radius
If production and the immutable backup live in the same cloud tenant, authenticated by the same directory, then a full tenant compromise reaches both. The lock still holds — that is its value — but everything around it is contested. Separate the control plane where you can, and document the dependency where you cannot.
Protecting servers and forgetting the SaaS estate
Mail, files and collaboration data in a cloud suite are not backed up by the provider in the sense most people assume; retention policies and recycle bins are not the same control. This gap deserves its own decision, which we cover in detail in our guide to Microsoft 365 data retention versus backup.
Setting it up once and never re-proving it
Configurations drift. A policy gets edited during a migration, a new workload is onboarded without the lock, a bucket is recreated by a script. Re-prove the immutable backup arrangement on a schedule by attempting a delete and capturing the failure, because a control you have not tested this year is a control you are assuming.
A 90-day immutable backup rollout plan
Days 1 to 30 — inventory and honesty
List every system and dataset, name the current copies, and mark which of the five digits each one actually satisfies today. Expect the results to be worse than the architecture diagram suggests, particularly for SaaS data and for anything a team stood up themselves. Do not fix anything yet; the inventory is the deliverable.
Days 31 to 60 — build the immutable backup
Choose the mechanism, enable compliance mode, set the window at thirty days unless you have a reason to go longer, and route the copy to a platform with a separate control plane. Then attempt to delete an object and screenshot the refusal, because that screenshot is your evidence for insurers, auditors and your own board.
Days 61 to 90 — verify and write it down
Perform a full restore from the immutable backup to an isolated environment, time it, and have a user validate the result. Record the recovery time you measured rather than the one you hoped for. Finish by writing a one-page summary naming the mechanism, the window, the credential separation and the last verified restore date.
After day 90 — the maintenance rhythm
Quarterly: attempt a delete, confirm it fails. Twice yearly: restore from the locked copy and time it. Annually: revisit the window against your current view of dwell time, and re-check that every new workload from the last twelve months is covered. Thirty minutes a quarter keeps the whole arrangement honest.
Frequently asked questions about immutable backup
Does an immutable backup stop ransomware?
No, and it is not meant to. It stops ransomware from removing your ability to recover, which changes the incident from an existential event into an expensive operational one. Prevention and detection are separate controls doing a separate job.
Can I delete data early in an emergency?
In compliance mode, no — that is precisely the property you are paying for. Plan the window with that in mind and keep genuinely short-lived data out of the locked set rather than hoping for an override that does not exist.
How does this interact with a right-to-erasure request?
A locked copy cannot be edited, so erasure is satisfied when the lock expires and the copy ages out. Document that position, keep the window proportionate, and make sure the request is honoured in production immediately. Regulators are generally comfortable with a documented, time-bound backup exception; they are much less comfortable with a surprise.
Is a second replicated appliance good enough?
Only if it cannot be deleted by the credentials that administer the first one. Replication is a resilience control, not an immutable backup, and treating one as the other is the single most common gap found during a review.
How long should the lock window be?
Longer than your realistic detection time. Thirty days suits most businesses, fourteen is the practical minimum, and anything under a week offers little protection against an intruder who has been present for a month. Start at thirty and adjust with evidence.
Do we still need offsite copies if we have an immutable backup?
Yes. Immutability protects against deletion; offsite protects against the building. They are different failure modes and the 3-2-1-1-0 backup strategy asks for both because both happen.
References
NCSC: Mitigating malware and ransomware attacks
NCSC: Offline backups in an online world
NIST SP 1800-11: Data Integrity — Recovering from Ransomware and Other Destructive Events
NIST SP 800-209: Security Guidelines for Storage Infrastructure
NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
Microsoft: Immutable vaults in Azure Backup
Google Cloud: Bucket Lock and retention policies
