What is an immutable backup?
An immutable backup is a backup copy that cannot be overwritten, encrypted or deleted until its retention period ends. The storage enforces the rule, not the backup software or a user’s good intentions. Even someone with valid admin credentials cannot remove it early, so the copy survives ransomware, human error and a compromised account.
Think of a letter sealed in a time-locked safe. You can read it later, and you can add new letters next to it. Nobody can open the safe to swap or burn the letter before the timer runs out, not even the person who put it there.
Why do backups need to be immutable?
Ransomware often looks for reachable backups first and deletes or encrypts them before it touches production. If the attacker holds the same credentials your backup job uses, a normal backup is just another target.
An immutable copy removes that option. The attacker can still write new data or hide files behind delete markers, but the locked versions stay readable. You lose time on the restore, not the data.
How is a backup made immutable?
There are a few common ways to get there. They differ in cost, speed of restore and how much they depend on one system.
Object Lock on object storage
The S3 API has Object Lock, a write-once-read-many (WORM) setting that works on top of versioning. Each object version gets a retain-until date or a legal hold. In compliance mode, nobody can delete the version or shorten its retention until the date passes, not even the account owner.
Offline or air-gapped media
Tapes or disks that are disconnected after the backup cannot be reached over the network at all. They are slow to restore from and need someone to handle them, but no remote attacker can touch them.
Locked snapshots
Some storage systems can take snapshots and block their deletion for a period. These help with fast rollbacks, but they usually live on the same system as the data, so they don’t protect against losing that system.
What should you plan for?
Immutability is a property of the copy, not a full backup strategy. Get these parts right as well:
- Retention length. Lock long enough to cover how late you might notice an attack, often weeks. Too long, and you pay for storage you can’t delete.
- Clean data. A locked copy of already encrypted or corrupt files is still useless. Watch backup jobs for sudden size or change spikes.
- Encryption keys. Keep keys for encrypted backups somewhere separate from the backups themselves, and lock those copies too.
- Restore tests. Restore regularly and time it. A backup you have never restored is a guess.
- A second location. Immutability doesn’t help when the site holding the only copy fails. Pair it with the 3-2-1 rule.
How enum handles immutable backups
enum Object Storage supports Object Lock and versioning on its S3-compatible API, so backup tools that write to S3 can store WORM copies. You enable Object Lock when you create the bucket. Storage runs in one zone without bucket replication, so keep another copy elsewhere for site-level failures.
FAQ
Is an immutable backup the same as versioning? No. Versioning keeps old versions when you overwrite or delete an object, but anyone with delete permission can remove those versions. Object Lock adds a retention rule that blocks deletion until the date passes.
Can I delete an immutable backup early if I made a mistake? In compliance mode, no, so test retention settings first. Governance mode lets users with a special bypass permission remove the lock, which helps for testing but is weaker against a compromised admin account.
Does an immutable backup stop ransomware? It doesn’t stop the attack, but it keeps a clean copy the attacker can’t destroy. Your recovery still depends on clean data, safe encryption keys, enough retention and restores you have actually tested.