Immutable Backups: How They Stop Ransomware From Deleting Recovery

Updated: October 2026

Ransomware crews learned years ago that encrypted servers don't get paid for if the backups still restore, so they go after the backups first. A backup that nobody can delete or change for a set number of days takes that move off the table. Here's how immutable backups work, the ways they're built, what they still don't protect, and how to test that the lock holds.

What Is an Immutable Backup?

An immutable backup is a copy that can't be modified or deleted until a retention date passes. The storage enforces it, not the backup software's settings screen. The model is called WORM: write once, read many.

Three things make a backup immutable rather than just hard to reach:

1. The lock lives in the storage layer. A deny rule in the backup console doesn't count, because whoever owns the console can remove it.
2. Every restore point gets a retain-until date. Before that date, delete and overwrite requests fail. After it, normal retention cleans up.
3. Admin rights don't shorten it. In the strictest modes, not even the account's root user can remove the lock early.

Read-only permissions, a separate domain or a hidden share are useful layers. None of them is immutability. They depend on credentials staying safe, and stolen credentials are how attackers reach backups in the first place.

Why Attackers Go for Backups First

CISA's #StopRansomware Guide spells out the logic: "many ransomware variants attempt to find and subsequently delete or encrypt accessible backups to make restoration impossible unless the ransom is paid."

The numbers back it. In Sophos research published in March 2024, 94% of organizations hit by ransomware said the attackers tried to compromise their backups, and 57% of those attempts succeeded. The survey covered 2,974 IT and security professionals.

The sequence is usually the same. Attackers get in, find the backup server, use the credentials they already stole to log in, delete restore points or shorten retention, and only then run encryption. Our post on how a ransomware attack moves hour by hour shows where that step lands. Immutability breaks the chain at the delete step.

How Immutable Backups Are Built

There are four common ways to get a lock that holds. They differ in where the lock lives and who can undo it.

S3 Object Lock and S3-Compatible Storage

Amazon S3 Object Lock stores objects in a WORM model and only works in buckets with versioning turned on. Each object version gets a retention period, a legal hold, or both. A legal hold has no end date and stays until someone removes it.

Object Lock has two retention modes, and the difference matters more than anything else in this post:

• Governance mode blocks deletes for most users, but anyone with the s3:BypassGovernanceRetention permission can override it. AWS notes the S3 console sends the bypass header by default.
• Compliance mode blocks everyone, including the root user. AWS's documentation says the only way to delete a compliance-mode object early is to delete the AWS account.

Governance mode is for testing retention settings. Compliance mode is the one that survives a stolen admin account. Many S3-compatible storage services (Wasabi, Backblaze B2 and others) support the same Object Lock API, so backup tools can write to them the same way.

Azure Immutable Blob Storage

Azure Blob Storage supports WORM through time-based retention policies and legal holds, set at the account, container or version level. A new time-based policy starts unlocked, so you can test it. You can shorten or delete an unlocked policy. Once you lock it, you can only extend the retention period, never shorten or delete it.

Microsoft recommends locking the policy within about 24 hours and not relying on the unlocked state beyond short-term testing. The same distinction applies as with S3: an unlocked policy protects you from mistakes, not from an attacker with admin rights.

Hardened Linux Repositories

Backup software can also enforce immutability on its own Linux storage server. Veeam's Hardened Repository is a common example. Veeam's documentation for version 13 describes it: each backup file gets an immutable attribute with a time period, the minimum is 7 days, and the period counts from the last restore point in the active chain.

Two details from that documentation catch people out. The immutability flag is only set when the backup session completes, so a failed job leaves no locked copy. And the repository watches for clock tampering, because moving the system time forward is one way to make locks expire early.

The server itself carries the rest of the protection: no remote shell access, a dedicated local account, and nothing else running on it. That hardening is what makes the file-level lock trustworthy.

That thread shows the design problem in practice. The team found their NAS sync tool didn't support immutability at all, and the replies split the job into two parts: replication for a warm second site, and a separate immutable copy for the day both sites are gone.

Backup Appliances

Appliance vendors enforce locks in their own firmware or storage layer. The questions to ask are the same as above. Where does the lock live, what is the minimum and maximum retention, and who can release it early? If the answer to the last one is "our support team, on request", find out what identity check they run first.

Immutable vs Air-Gapped vs Offline Backups

These three terms often get used interchangeably. Each one blocks a different attack.

CISA's guidance asks for "offline, encrypted backups of critical data" and regular tests of their availability and integrity. The same guide adds a caution about immutable cloud storage: it "does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost."

If you want to see a hardened repository built from scratch, this Veeam v13 walkthrough from Labs Hands On covers the install and the immutability settings.

For a small IT team, the practical answer is a combination. Keep a fast local copy for everyday restores, and an immutable copy in a separate account with separate credentials for the day the local site is lost. Our guide to MSP backup solutions covers how that split looks when you run it for many clients.

What Immutability Doesn't Protect

A locked restore point stops one attack: deleting that restore point. Everything around it is still in play.

The backup console. An attacker who owns the backup admin account can't delete locked data, but can disable jobs, shorten retention for new backups, or delete the storage account where the provider allows it. By the time anyone notices, the last good copy may be older than you think. Separate the storage control plane from the backup console, and protect both with their own credentials and phishing-resistant MFA.

Retention shorter than detection. A 7-day lock doesn't help if the attacker sat in the network for three weeks and every locked copy already contains their tools. Set retention longer than the time it would take you to notice an intrusion, and keep some older restore points beyond that.

Infected or incomplete backups. Immutability preserves whatever you wrote, malware included. And as Veeam's documentation notes for its repository, a failed backup session never gets its lock.

Encryption keys. Encrypted backups are only restorable if the keys survive. If the key store or password vault lived on the same network that got encrypted, the locked backups are unreadable.

Governance-style modes. A lock that an admin can bypass is only as strong as that admin's account.

One reply in that thread puts the threat model in a sentence: if a single admin account can rotate storage credentials, shorten retention, remove the storage account and silence the alerts, the setup won't protect much once that account is compromised.

How to Test That the Lock Holds

Don't trust a setting you haven't tried to break. Run these checks when you set immutability up, and again after any change to the backup platform:

1. Try to delete a locked restore point with the backup admin account and with a storage admin account. Both should fail.
2. Try to shorten retention on existing data. In compliance mode or a locked Azure policy, that should fail too.
3. Check the lock directly on the storage, not only in the backup console. For S3, this shows the mode and retain-until date of an object version:

bash
aws s3api get-object-retention --bucket <bucket> --key <object-key> --version-id <version-id>

4. Restore from the immutable copy into an isolated network, and time it. The restore time from object storage over your internet link is the number that decides whether this copy is usable in a real incident. Our post on disaster recovery testing covers the test types and how often to run each.
5. Alert on the last successful immutable copy, not just on job status. A job that silently stopped writing leaves you with locks on old data.

What Immutable Retention Costs

Immutability itself usually isn't the expensive part. Microsoft says there's no extra capacity charge for immutable Azure Blob Storage, though version-level WORM needs versioning, and stored versions cost money. The real cost is retention: you pay to store every locked restore point for its full lock period, and you can't delete early to save space.

That's also where mistakes hurt. A 10-year compliance-mode lock set by accident on a large bucket can't be undone short of closing the account, which is the kind of costly misconfiguration CISA warns about. Start in governance mode or with an unlocked policy, confirm the retention math, then switch to the strict mode.

A rough way to size it: take your full backup size, add the daily change rate multiplied by the number of locked days, and add the extra copies your backup chain keeps. Then compare that with what one lost restore would cost. Our post on incremental vs differential backup walks through the storage math for restore chains.

The Short Version

Immutable backups stop ransomware from deleting the restore points you'd use to recover without paying. Use a lock that admins can't bypass: S3 compliance mode, a locked Azure policy, or a hardened repository. Keep it in a separate account from production, with retention longer than your detection time. Then test it by trying to delete what you locked.

For how immutability fits the wider plan, read our guide to BCDR.

If an insurer asks about your backups, our post on cyber insurance requirements covers what they check.

Choosing a product for a small office? Our small business backup guide has a buying checklist.

For IT teams weighing appliances, cloud and hybrid setups, see the enterprise backup guide.