Here is a number that should make every sysadmin uncomfortable: in 2025, the median time between a ransomware crew gaining access to a network and detonating their payload dropped below 24 hours. The days of attackers lurking for weeks are largely over. They get in, they find your backups, they encrypt or delete them, and then they encrypt production. By the time you see the ransom note, your safety net is often gone too.
That last part is the quiet catastrophe. Most organizations that pay a ransom do so not because their production data was hit, but because their backups were hit as well. If your backup can be modified or deleted by anyone with the right credentials, it is not really a backup. It is a hostage waiting to happen.
This is where immutable backups come in. In this guide I will explain exactly what immutability means, how it works under the hood, how to actually set it up across cloud and on-prem, a worked recovery scenario with real numbers, and how it fits into a broader defense strategy. By the end you will know how to build a backup that ransomware physically cannot touch.
Key Takeaways
- Immutable backups cannot be altered or deleted until a defined retention period expires, even by an administrator with full credentials.
- The technology behind this is WORM (Write Once, Read Many), enforced by object lock, hardware, or specialized software.
- Follow the 3-2-1-1-0 rule: 3 copies, 2 media types, 1 offsite, 1 immutable/offline, 0 verified errors.
- Set retention to at least 14 to 30 days so you can recover from attacks discovered late.
- Immutability is worthless without tested restores. An untested backup is a rumor.
- Pair immutability with strong access control, MFA, and endpoint hardening for defense in depth.
What Are Immutable Backups, Exactly?
An immutable backup is a copy of your data that, once written, cannot be changed, overwritten, or deleted for a set period of time. Not by a hacker who steals your admin password. Not by malicious insiders. Not even by you, until the retention clock runs out.
The concept borrows from a decades-old storage principle called WORM: Write Once, Read Many. You write the data once, you can read it as many times as you want, but the write operation is permanent for its lifetime. Think of it like ink on paper versus pencil. Ransomware relies on being able to erase your pencil marks. Immutability hands you a pen.
Immutability vs. Traditional Backups
A traditional backup is just a file or a snapshot sitting on disk, in a NAS, or in a cloud bucket. If an attacker gains access to that storage, they can encrypt it, delete it, or corrupt it exactly like any other file. Many ransomware strains now specifically hunt for backup file extensions (.bak, .vbk, .tib) and shadow copies before encrypting.
An immutable backup removes that attack surface. Even with valid credentials, the delete command simply fails until retention expires. That single property changes the entire economics of an attack against you.
How Immutability Actually Works
There are three common ways to enforce immutability, and it helps to understand the mechanism so you can pick the right one.
- Object lock (cloud): Services like Amazon S3, Backblaze B2, Wasabi, and Azure Blob support "object lock" with a retention period. Once set in compliance mode, not even the account root user can delete the object early. This is enforced at the storage API layer.
- Hardened repositories (on-prem): A Linux server configured so the backup application writes files with a temporary immutability flag (using the
chattr +iextended attribute) and no interactive login is allowed. Even root cannot remove the file until the flag expires. - Air-gapped and offline media: Tape, or rotated external drives that are physically disconnected. Data that is not plugged in cannot be encrypted over the network. Old-fashioned, but bulletproof.
Governance Mode vs. Compliance Mode
When you enable object lock, most cloud providers offer two flavors, and choosing wrong defeats the purpose:
- Governance mode: Users with special permissions can override the lock and delete early. Convenient, but a compromised admin account can bypass it. Useful for internal policy, weak against ransomware.
- Compliance mode: Nobody can delete the object before retention expires. Not the admin. Not the root user. Not the provider on your behalf. This is the mode you want for ransomware defense.
The 3-2-1-1-0 Rule for 2026
The classic 3-2-1 backup rule (3 copies, 2 media types, 1 offsite) is showing its age. Modern practice extends it to 3-2-1-1-0:
- 3 copies of your data (production plus two backups).
- 2 different media or storage types.
- 1 copy stored offsite.
- 1 copy that is immutable or air-gapped (the new addition).
- 0 errors after automated recovery verification.
If you want a broader treatment of how local and cloud copies fit together, our guide on how to back up your data in 2026 with a local plus cloud strategy pairs perfectly with what follows here.
Comparing Immutable Storage Options
Not every immutable target is equal on cost, recovery speed, or resistance to a determined attacker. Here is how the main options stack up for a small-to-midsize workload.
| Option | Immutability Type | Recovery Speed | Rough Cost (per TB/mo) | Ransomware Resistance |
|---|---|---|---|---|
| Amazon S3 (Compliance lock) | Object lock | Fast | $18–23 | Excellent |
| Backblaze B2 / Wasabi | Object lock | Fast | $6–7 | Excellent |
| Hardened Linux repo | chattr immutable flag | Very fast (LAN) | Hardware only | Very good |
| LTO tape (offline) | Physical air gap | Slow | $3–5 amortized | Bulletproof |
| Rotated external drives | Physical air gap | Medium | $4–6 amortized | Very good |
My honest recommendation for most teams: use an object-lock cloud bucket (Backblaze B2 or Wasabi for cost, S3 if you are already on AWS) as your immutable offsite copy, and keep a fast local copy for day-to-day restores. Add offline media only if you handle regulated or irreplaceable data.
A Worked Example: The 2 A.M. Recovery
Let me make this concrete. Say you run a mid-sized ecommerce operation with a PrestaShop store, a WordPress marketing site, and a database totaling 400 GB of critical data. You back up nightly.
Here is the setup you built:
- Copy 1: Local NAS snapshot, nightly, kept 7 days.
- Copy 2: Backblaze B2 bucket with object lock in compliance mode, 30-day retention.
- Copy 3: Weekly external drive, rotated offsite and kept in a drawer at home.
Now the attack. At 2:14 A.M. on a Tuesday, a compromised plugin gives an attacker a foothold. They escalate to admin, encrypt the production server, and delete the NAS snapshots over SMB. By morning your site is down and your local backups are gone. This is exactly the scenario that pushes companies into paying.
But your B2 copy has object lock in compliance mode. The attacker's stolen credentials issue delete calls against the bucket, and every single one returns an AccessDenied error. The data is untouchable until day 30. You spin up a clean server, pull last night's 400 GB copy from B2, and restore.
The math: at roughly 500 Mbps download you move 400 GB in about 1 hour 50 minutes, plus restore and verification time. Call it a half-day outage instead of a business-ending event. You paid the attacker nothing.
That is the entire value proposition in one story. The immutable copy is the difference between a bad Tuesday and a closed company.
How to Set Up Immutable Backups Step by Step
Here is a practical walkthrough using an object-lock cloud bucket, the approach I recommend for most readers. I will use Backblaze B2 as the example, but the flow is nearly identical for S3 and Wasabi.
- Create a dedicated bucket. In your provider console, create a new bucket used only for backups. Enable Object Lock at creation time. On most providers, object lock cannot be added to an existing bucket after the fact, so do it now.
- Set the default retention. Choose Compliance mode and set a default retention of at least 30 days. This means every object written inherits a 30-day untouchable window.
- Create scoped application keys. Generate an application key with permission to write and read the bucket, but not to delete or to change bucket settings. Store it in a secrets manager, never in a plaintext script.
- Point your backup tool at the bucket. Configure Veeam, Duplicati, Restic, Kopia, or your platform of choice to use the bucket as a target. In Restic, for example, immutability is honored automatically when the backend has object lock enabled.
- Schedule and stagger. Run backups nightly. Keep enough retention that a slow-burn attack discovered two weeks late still has clean recovery points.
- Enable MFA on the storage account. Compliance mode protects the objects, but you still want MFA guarding account settings and billing.
- Verify every backup. Turn on integrity checks. Restic's
restic checkand Kopia's built-in verification catch corruption before you need the data. - Run a monthly test restore.Cover image: Server room by torkildr, licensed under BY-SA 2.0 via Openverse.
