"Immutable backups" is on nearly every backup vendor's homepage now, ours included. The word is doing a lot of work, and most of the pages that use it never say what it stops and what it doesn't.

This article is the plain version. No product tour, no fear-driven statistics. Just what immutability is, the one attack it defeats, the attacks it does nothing about, and what you should check before you trust it.

If you take one thing away: immutability protects your backups from being deleted or overwritten. It does not protect your data from being stolen, your systems from being encrypted, or your backups from being wrong. Those need other measures.

What "immutable" actually means

An immutable backup is a file that the storage system refuses to delete or modify for a set period, no matter who asks. Not the backup software, not the administrator, not the account owner. The clock runs on the storage side, and it does not care about your credentials.

That last part is the whole point. A backup that only your software promises not to touch is a policy. A backup the storage provider physically cannot delete until a date has passed is a guarantee. Ransomware exploits the gap between those two.

In practice this is implemented by object storage features such as S3 Object Lock in compliance mode, or equivalents at other providers. You write a file, you set a retention date, and until that date the delete and overwrite operations return an error. After the date the lock lapses and normal rules apply again.

Two details matter more than they look:

• Compliance vs. governance mode. Governance mode lets a sufficiently privileged user bypass the lock. Compliance mode lets nobody bypass it, including the provider's own support. Only compliance mode is a real defence against an attacker who has your admin credentials.

• Retention is per object, per write. Immutability is not a switch you flip on a bucket and forget. Every new backup file needs its own retention period applied when it is written, and that period has to cover the time you would need to notice an attack and recover.

The one attack it stops

Modern ransomware does not start by encrypting your files. It starts by finding your backups.

The playbook is well established. An attacker gets a foothold, often through a phished login or an exposed remote-access service. They spend days or weeks moving quietly through the network and collecting credentials. Before they trigger the encryption, they locate every backup they can reach and destroy it: delete the files, wipe the repository, empty the cloud bucket, or simply encrypt the backup archives along with everything else. Then they encrypt production and send the ransom note.

The reason is obvious once you see it. A company with working backups does not pay. So the backups have to go first.

This is exactly the step immutability breaks. If the backup files carry a storage-enforced retention lock, the attacker can hold every password in the company and the delete still fails. They can encrypt the file on your server, but the copy in the locked bucket is untouched. They can delete the bucket policy, revoke your keys, and nothing changes; the objects stay until the retention date.

So the honest one-line claim is: immutability guarantees that a backup written before the attack still exists after it. That is a narrow claim. It is also the single thing that decides whether a ransomware incident is a bad week or the end of the business.

What it does not protect against

Here is the list vendors tend to leave off the page.

Data theft. Immutability keeps a copy of your data safe. It says nothing about who else has a copy. Most ransomware groups now exfiltrate data before encrypting and threaten to publish it. An immutable backup lets you restore; it does not stop the leak. Encryption of the backup files themselves, with keys the attacker never sees, is the relevant control there.

The attack itself. Your servers still get encrypted. Your staff are still locked out. Recovery still takes as long as a restore takes. Immutability makes recovery possible; it does not make it fast or painless.

Bad backups. A locked backup of corrupted, incomplete or already-encrypted data is a locked copy of garbage. If the attacker sat in your network for three weeks, the backups from that period may include their changes. Immutability preserves what you wrote. It does not check whether what you wrote was worth keeping.

Short retention. If your lock is seven days and the attacker waits ten, every locked copy has expired by the time they strike. The lock only helps if it outlasts the attacker's patience and your detection time. Weeks are a minimum; months are safer.

Attacks that start before the lock existed. If you turned immutability on last month, anything older than that is still ordinary, deletable data. The protection only covers what was written under the lock.

Stolen provider accounts. Compliance-mode locks survive a stolen access key, but they do not survive a closed account. If an attacker can get your cloud account terminated, or if you stop paying the bill, the provider will eventually remove the data. Root account security and billing continuity are part of the same defence.

Local copies. Backups sitting on a NAS, a USB drive or a network share are not immutable in any meaningful sense. A snapshot on the same box the attacker controls is not immutable either. If the attacker can reach the device with admin rights, they can erase it.

How this works with Duplicati

Duplicati's storage model happens to fit immutability well, because it was designed around dumb storage from the start. Every backup is written as a set of encrypted, deduplicated volume files. Existing files are never edited in place; a new backup run only ever adds new files. Cleanup is a separate, explicit step that deletes whole volumes once nothing references them.

That write-once pattern is exactly what object-lock storage wants. The workflow looks like this:

1. Pick a bucket that supports object lock in compliance mode (Amazon S3, Backblaze B2, Wasabi, MinIO and most S3-compatible providers offer it). Enable the lock or versioning support when the bucket is created; it usually cannot be added to an existing bucket.

2. Tell Duplicati how long to lock each file. Add the advanced option remote-file-lock-duration=90D (or whatever period you choose) to the backup job. At the end of every backup run, Duplicati locks, or re-locks, every volume needed to restore that backup for the full duration. Older volumes that are still referenced get their lock extended; nothing a restore depends on is left unprotected.

3. Set the duration longer than your longest plausible detection time. Thirty days is a common floor. Ninety days costs more storage and buys considerably more safety.

4. Don't rely on credential tricks. The lock is what guards the remote volumes, not the permissions on the key. Once a volume is locked, both overwrites and deletes are refused by the storage provider, whatever the key is allowed to do. Duplicati needs ordinary read, write and delete rights so it can run backups and clean up expired volumes; a locked file is safe even from a key that has all of them.

5. Encrypt the backups with a passphrase stored outside the backed-up systems. Immutability keeps the files; encryption keeps them private if the bucket is ever read by the wrong person.

6. Let Duplicati handle cleanup timing. Duplicati records the lock period for every remote file and will not try to delete a locked volume until its lock has expired. Retention and compaction still run; they just defer removal of anything still under lock. Storage use will run higher than with an unlocked target, and that is the price of the guarantee.

That is the whole setup: one bucket with object lock, one option on the job, and a passphrase kept somewhere safe.

What to actually verify

A vendor saying "immutable" is not evidence. These are the questions that separate a real lock from a marketing word:

• Is the lock enforced by the storage provider, not by the backup software? Try to delete a file with your admin credentials. It should fail.

• Is it compliance mode, where nobody can shorten or remove the lock, or governance mode, where a privileged user can?

• What is the retention period on the files written last night? Not the default on the bucket; the actual value on the actual objects.

• Does that period exceed how long an attacker could sit in your network unnoticed?

• Are the backups encrypted with a key that is not stored on the systems being backed up?

• Have you restored from the locked copy recently, on a machine the backup software has never seen, using only the passphrase?

• Who can close or terminate the cloud account, and is that access protected with hardware keys?

• Is there at least one copy that is off-site, off-network and locked, rather than only a local snapshot?

If you cannot answer all of these, you do not yet have immutable backups. You have backups and a hope.

The short version

Immutability is a narrow, mechanical guarantee: files written under a lock cannot be deleted or changed until the lock expires. That narrow guarantee happens to defeat the single step ransomware relies on most, which is destroying your backups before the ransom note lands.

It does not stop the breach, the theft, or the downtime. It does not fix bad backups or short retention. What it does is make sure that when the dust settles, there is something to restore from. Everything else about recovery is your job; immutability just makes that job possible.