An immutable backup is a backup copy that the storage system locks against being changed, encrypted or deleted until a set retention period ends. The lock is enforced by the storage platform or backup service itself, not just by user permissions, which is what makes it useful against ransomware and stolen admin accounts. How strong that protection is depends on how immutability is configured: some modes let nobody remove the lock early, while others allow privileged users to override it.
At a glance
- Immutability is a time-based lock: the copy can be read and restored, but the storage refuses changes or deletion until the lock expires, subject to the lock mode.
- It is enforced by the storage layer or backup service, often using write-once, read-many (WORM) or object-lock features.
- Lock strength varies by mode; some let administrators shorten or remove the lock, others don’t.
- It protects existing backup copies; it doesn’t prevent attacks or guarantee that the copy is free of malware.
- Retention periods need planning, because locked copies keep using storage until they expire.
What problem it solves
Ransomware groups learned that victims with good backups don’t pay. Many attacks now look for backup servers, consoles and storage early, then delete or encrypt the copies before encrypting production systems. An attacker with domain administrator rights or backup console credentials can often do exactly what an administrator can do, including deleting backups.
Ordinary backups rely on permissions to stay safe, and permissions are what attackers steal. Immutable backups add a control that sits below the permissions: once a copy is written and locked, the storage refuses to change or delete it until the lock expires. If the lock is in a mode that administrators can’t override, a compromised admin account can’t remove those copies early either. The same protection guards against an insider or a mistake wiping out backups.
How it works
Write, then lock. When a backup is written, the storage applies a retention lock with an expiry date. Until then, requests to overwrite, encrypt or delete the copy are refused.
Where the lock lives. Common implementations include object storage with object-lock features, as used in many file systems and object storage services, hardened backup appliances and repositories, and backup services that manage immutable storage on your behalf. Tape that is physically removed and write-protected offers a similar outcome by different means.
Lock modes. Stricter modes block everyone, including the storage account owner, until expiry. More flexible modes let specially privileged users shorten or remove locks, which helps fix mistakes but leaves a path an attacker could use. Some services add separate approval steps, delayed deletion or a recycle bin for backup data as further safeguards.
Retention planning. The lock period should cover how far back you might need to go, including the time an attacker could spend inside before being discovered. Longer locks mean more storage, since copies can’t be removed early.
Recovery. Immutable copies still have to be checked for malware and restored in a tested process, ideally coordinated with incident response (IR) so you don’t restore the attacker’s foothold along with your data.
When it matters for buyers
- When cyber insurance renews. Insurers often ask whether backups are immutable, isolated or offline.
- After a peer is hit by ransomware. A common question is whether your backups would have survived the same attack.
- When choosing a backup service. Immutability options, lock modes and defaults differ widely between providers.
- When setting recovery targets. After an attack, the age of your newest clean, protected copy decides whether you can meet your recovery point objective (RPO) or lose more data than it allows.
- When reviewing the 3-2-1 rule. Many organizations now treat one immutable or isolated copy as part of that rule.
Questions to ask vendors
- Which of our backup copies are immutable by default, and which need to be configured?
- Which lock mode do you use, and can anyone, including your staff or our administrators, shorten or remove a lock?
- What extra safeguards protect the backup console itself, such as separate credentials, multifactor approval or delayed deletion?
- How long can locks be set for, and how does that affect our storage costs?
- How do you help us find and verify a clean recovery point after an attack?
- Is the immutable copy stored separately from our main environment and credentials?
How it differs from the 3-2-1 backup rule
The 3-2-1 backup rule is a guideline for how many copies to keep and where: three copies of data, on two different types of media, with one offsite. Immutability is a property of a copy: whether it can be changed or deleted. A setup can follow 3-2-1 and still lose every copy if all of them are reachable with the same stolen credentials. That gap is why newer versions of the rule add a copy that is immutable or isolated, such as an air-gapped backup. Immutable backup is commonly offered as part of backup as a service (BaaS). Our backup as a service overview covers how providers protect backup data.