An immutable backup is a backup copy written in a way that cannot be modified, encrypted or deleted by anyone, including administrators, until a defined retention period has expired. In backup & recovery for servers, immutability is the main technical answer to ransomware and malicious insiders, who increasingly target backups before they attack production data.
Immutability is enforced by the storage layer, not by good intentions. Typical implementations rely on WORM storage (write once, read many), object lock in S3-compatible object storage, hardened Linux repositories with immutable file attributes, or snapshots that the storage system refuses to remove early.
How immutable backups are enforced
An immutable backup works because the storage system itself rejects changes to protected data for a fixed time. The backup software writes the data normally, then sets a retention date; from that moment, delete and overwrite requests fail regardless of the credentials used.
| Method | Where it runs | How it blocks changes |
|---|---|---|
| S3 Object Lock | Object storage, cloud or on-premises | Retention date per object version |
| Hardened Linux repository | Dedicated backup server | chattr +i attribute, no shell access for backup account |
| WORM tape | LTO WORM cartridges | Media physically cannot be rewritten |
| Immutable snapshots | Storage arrays, ZFS-based systems | Snapshots locked against early deletion |
| Backup appliance lock | Purpose-built deduplication appliances | Retention lock in the appliance OS |
A crucial detail is what the retention clock protects against. If an attacker can change the system clock, reset the storage controller or delete the whole bucket or volume, immutability can be bypassed. Strong designs therefore use separate credentials, network isolation and trusted time sources for the immutable tier.
Governance and compliance retention modes
Object storage platforms usually offer two retention modes, and the difference is decisive. In governance mode, users with a special permission can still shorten retention or delete objects; in compliance mode, nobody, including the root account, can delete the object before its retention date.
| Mode | Who can delete early | Typical use |
|---|---|---|
| Governance mode | Users with bypass permission | Testing, internal policies |
| Compliance mode | Nobody until expiry | Ransomware protection, regulatory retention |
| Legal hold | Nobody until hold is removed | Litigation or investigation, no fixed date |
Compliance mode is the setting that actually stops a compromised administrator account. Its cost is inflexibility: a misconfigured retention of several years cannot be undone, and the storage must be paid for until it expires. Teams therefore test retention settings in governance mode before switching production backups to compliance mode.
Object lock depends on bucket versioning. An overwrite does not replace a locked object; it creates a new version, while the protected version remains intact. A delete request only adds a delete marker, so the locked version can still be restored until its retention date passes.
Immutable backup compared with air-gapped and offsite backups
Immutability, air gaps and offsite copies address different threats, and the 3-2-1 backup rule is often extended to 3-2-1-1-0 to include one immutable or air-gapped copy and zero errors after restoration tests.
| Approach | Protects against | Remains exposed to |
|---|---|---|
| Immutable backup | Deletion, encryption, tampering | Theft of readable data, storage-level destruction |
| Air-gapped backup | Any network-borne attack | Slow restores, manual handling errors |
| Offsite backup | Site loss such as fire or flood | Ransomware if online and writable |
| Ordinary snapshot | Accidental changes, quick rollback | Deletion by a privileged attacker |
An immutable copy is often logically air-gapped: it stays online for fast restores but cannot be altered. A physically air-gapped copy, such as ejected tape, gives stronger isolation at the cost of slower recovery time. Many organizations combine both.
Designing an immutable backup strategy
The central design parameter is the immutability period. It must be longer than the time an attacker could stay undetected in the network, because ransomware groups often wait days or weeks before encrypting. Periods of 7 to 30 days are common for operational backups, with longer locks for monthly or yearly copies.
| Decision | Recommended practice | Reason |
|---|---|---|
| Retention length | Longer than likely attacker dwell time | Clean restore points must still exist |
| Credentials | Separate accounts, MFA, no domain join | Stolen admin rights cannot reach backups |
| Backup chain | Lock full and incremental backups together | An unlocked increment breaks restores |
| Capacity planning | Budget for locked data that cannot be pruned | Storage grows during the lock period |
| Restore testing | Regular restoration tests from the locked tier | Proves backups are usable, not only stored |
Incremental and synthetic full backups need special care. If a full backup expires while later increments still depend on it, the chain becomes useless. Backup software that supports immutability extends locks across the whole chain automatically.
Limitations and common mistakes
Immutability prevents destruction of backups, but it does not guarantee a clean or complete backup. If ransomware encrypted files before the backup ran, the immutable copy faithfully preserves encrypted data.
- Using governance mode and assuming it stops a privileged attacker.
- Leaving the management console reachable with domain credentials, so retention policies can be changed for future backups.
- Locking only part of the backup chain, which leaves restores dependent on deletable files.
- Ignoring the storage clock, which an attacker may manipulate on self-managed systems.
- Skipping restoration tests, so nobody knows whether the locked data actually restores.
Immutable storage also does not replace encryption at rest, because a locked backup can still be read and exfiltrated if the attacker reaches it. Confidentiality and immutability are separate controls.
Stripped to the essentials
An immutable backup is a copy of data that is sealed for a fixed time. During that time nobody can change it or throw it away. Not even the person in charge can do it.
Think of a document placed in a time-locked safe. Thieves who break into the office can damage everything on the desks. The copy in the safe stays untouched until the timer ends. The main benefit is simple: after an attack, a clean copy still exists.
Where it is applied
A regional accounting firm backs up its file servers and database every night to a local backup server and copies the data to S3-compatible object storage with object lock in compliance mode and a 21-day retention period. The backup storage uses a separate account with multi-factor authentication that is not part of the office domain.
One Friday, attackers who had stolen an administrator password encrypt the file servers and try to delete the backups. The local repository is wiped, but every delete request to the locked bucket fails. The team identifies that the intrusion began 9 days earlier and restores from a copy taken 10 days before, then replays newer clean data from unaffected sources.
The firm is back in operation within two days without paying a ransom, because the immutable copy survived the attack.