An immutable backup is a recovery point that cannot be modified, overwritten, or deleted until a defined retention period ends. The storage layer enforces the lock, so ransomware holding stolen administrator credentials cannot erase the copy while the lock is active, as long as the lock mode is one that administrators cannot override. In AWS S3 compliance mode, no user, including the account’s root user, can overwrite or delete a protected object version. The lock preserves the copy’s existence, not its cleanliness. Lock duration, credential separation, and restore testing decide whether it helps in a real incident.
Key Takeaways
Backups are a primary ransomware target. A 2024 Sophos survey of 2,974 ransomware victims found that 94% said attackers tried to compromise their backup, and 57% of those attempts succeeded. Median recovery cost was $3M when backups were compromised, against $375K when they were not.
Lock modes differ in who can override them. In AWS governance mode, principals with the bypass permission can delete locked versions or shorten retention. Compliance mode blocks everyone, including root.
Immutable does not mean clean. A lock preserves whatever was written. NIST warns that attackers can poison future backup copies and return once only old copies remain.
Lock length is a bet on detection speed. Mandiant reports a 14-day global median dwell time for 2025 intrusions. A lock shorter than your worst-case detection time can leave you with no pre-intrusion restore point.
Separate who controls backup from who controls production. NIST recommends separate accounts and separate management systems for cyber-attack recovery copies. Mandiant recommends decoupling backup environments from the corporate Active Directory domain.
The restores are on a schedule. NIST’s draft storage guidance calls for testing critical backups at least monthly.
What is Immutable Backup?
Immutable backup stores backup data so it cannot be altered or removed during a retention window. It usually relies on write-once-read-many (WORM) behavior or an equivalent lock.
NIST describes immutability as preventing destruction or alteration, combined with integrity verification and enforced retention periods. It notes this is often delivered through WORM storage or object storage that pairs WORM with integrity metadata.
A conventional repository relies on permissions, so whoever holds delete rights can delete. A locked copy suspends the delete right for the retention window, whoever holds it, subject to lock mode.
Immutable is not the same as offline. CISA’s #StopRansomware Guide recommends offline, encrypted backups that are tested regularly, because many ransomware variants look for accessible backups to delete or encrypt. Immutable storage typically remains network-reachable; it stops deletion but does not remove the network path. NIST’s draft SP 800-209 Rev. 1 says to use immutable storage where possible and appropriate to further isolate recovery data. Treat immutability as a strong layer, not a replacement for isolation.
How Ransomware Deleted Backups
Operators remove recovery options during the same intrusion, using native OS tools, stolen credentials, backup-server exploits, and hypervisor or cloud consoles.
Built-in recovery features. MITRE ATT&CK T1490 documents native Windows utilities used to delete volume shadow copies and the backup catalog, and to disable automatic recovery.
Backup software access. CISA notes that actors harvest credentials from the compromised environment to reach backup solutions, and use public exploits against unpatched ones.
Hypervisors and management planes. Mandiant’s M-Trends 2026 reports that ransomware operators, including Akira and Qilin, targeted backup infrastructure, identity services, and virtualization management planes in 2025. Encrypting hypervisor datastores can make every VM on them unusable at once. MITRE's detection guidance for T1490 includes ESXi shell commands that remove all VM snapshots.
Cloud storage. Mandiant also describes attackers deleting backup objects directly from cloud storage.
Slow poisoning. NIST describes interfering with the backup process so future copies are compromised, then waiting until only old copies remain.
Two Documents Cases
Code Spaces (June 2014). Code Spaces faced a DDoS attack and an extortion attempt on June 17, 2014. The attacker, who had reached its AWS control panel, deleted EBS snapshots, S3 buckets, and machine images. The company reported that most data, backups, and offsite backups were partly or fully deleted. Code Spaces ceased operations on June 18, 2014. This was extortion rather than file-encrypting ransomware, but the failure mode is the same — backups sat behind the same access path as production.
A 2025 intrusion reported in M-Trends 2026. A secondary summary of the report states that the financially motivated cluster UNC2165 destroyed backups and deployed RansomHub ransomware across Windows and virtual management servers. The reported facts again point to backups reachable through access the attacker already held.
How Immutability Stops Backup Deletion
The storage system attaches a retain-until date to each recovery point and refuses delete and overwrite requests until that date, regardless of the requester's permissions (mode-dependent).
1. The backup software writes the recovery point to a lock-capable target with a retention period.
2. S3 stores the lock information in the object version's metadata.
3. Delete and overwrite requests against that version are refused while the lock is active. On versioned buckets, retention and legal holds protect only the specified version, so new versions and delete markers can still be added on top — a delete request can add a marker, but the locked version remains.
4. After the retention period ends, the version can be overwritten or deleted.
Layered diagram of production hosts, backup server, and lock-enabled storage in a separate account. Arrows show attacker actions, marked “blocked” (API delete or overwrite during lock) or “not blocked” (job changes, lock expiry, poisoned source data, account compromise).
What a Lock Does and Does not Stop
Attacker action
| Stopped by the lock?
| Why it matters
|
Delete or overwrite the locked recovery point via the storage API | Yes, until the retain-until date | Mode-dependent - governance mode can be bypassed by privileged principle |
Encrypt the locked file in place | Yes | Modification is refused |
Delete shadow copies or hypervisor snapshots on production systems | No | These are not the locked copy |
Stop backup jobs or change retention for future points | No | Existing points survive, but new ones may never arrive |
Wait for the lock to expire | No | Protection ends at the retain-until date |
Compromise the cloud account | Depends | For AWS compliance mode, deleting the account is the only way to remove objects early |
Corrupt or encrypted source data before backup | No | The lock preserves whatever was written |
Exfiltrate data for extortion | No | Immutability does not provide confidentiality |
Are Snapshots and Replicas Immutable?
Not by default. Hypervisor snapshots and replicas sit in the same administrative plane as production, and MITRE lists snapshot removal on ESXi as a detection case. NIST also notes that snapshots store only changes from a base, so they are often unusable if the base is lost. Some storage platforms add retention locks to snapshots; verify this per platform and version rather than assuming it.
Implementation Options and Who Can Undo the Lock
Option
| Who can remove the lock early
| Best fit
| Residual risk
|
S3 Object Lock, governance mode | Principle with the bypass permission | Testing retention settings before committing to compliance mode | Stolen privileged identity |
S3 Object Lock, compliance mode | No user, including root, account deletion is the only path | Copies you must not be able to undo | Cannot be shortened; account-level control |
Azure immutable blob, unlocked time-based policy | The policy can be edited or deleted | Short-term testing only | Not a compliant state |
Azure immutable blob, locked time-based policy | The policy cannot be deleted; retention can be extended but not decreased | Regulatory retention such as SEC 17a-4(f) | Irreversible planning |
Legal hold (AWS and Azure) | Stays until explicitly removed | Freezing points during an investigation | Needs storage-layer permission |
Linux immutable attribute (chattr +i) | Superuser or a process with CAP_LINUX_IMMUTABLE | On-premises repositories | An attacker with root can clear it |
Offline or disconnected copy | Not reachable while disconnected | Last-resort copy, in line with CISA’s offline guidance | Handling effort, slower restore |
A Retention Lock is a Bet on How Fast You will Notice an Intrusion
A lock protects a recovery point only until its retain-until date. It must therefore outlast the time an intruder can stay undetected; otherwise every locked copy that remains may postdate the compromise.
Why This Happens
Once retention ends, a protected version can be deleted or overwritten. Older clean points age out while newer points may already contain the intruder's changes.
Mandiant's 2025 global median dwell time was 14 days, up from 11. For espionage and North Korean IT worker cases, it was 122 days. Prior compromise was the top initial vector in ransomware operations at 30%, so the foothold behind a ransomware event can be older than the event.
NIST's poisoning scenario, described above, is the deliberate version of the same problem.
A default is not derived from your detection performance. Vinchin's WORM protection period, for example, defaults to 7 days within a 1–9999 day range — shorter than the global median above.
Why the two errors are not symmetric. A lock that is too short can leave you with no clean point. A lock that is too long ties up storage you cannot release. AWS compliance-mode retention cannot be shortened. Azure locked policies cannot be decreased. Vinchin WORM retention can only be extended. Locks can be extended but not shortened, so start conservative and tiered, and extend when needed.
Practical Implication
1. Estimate worst-case time to detect, then add the time to decide and start a restore.
2. Give at least one tier of restore points (for example weekly or monthly) a lock longer than that figure. Keep shorter locks on daily points to control storage growth.
3. When you suspect an intrusion, extend locks or place legal holds on candidate points before they expire.
4. Scan older points before trusting them.
Choosing an Approach
Environment
| Primary lock
| Add
| Watch out for
|
Single site, no public cloud | S3-compatible on-premises target with Object Lock or vendor WORM storage | Offline copy on a rotation | Storage admins hold root-equivalent rights over the lock, so use separate identities |
Hybrid, cloud allowed | Object Lock or immutability policy in a separate account or subscription | MFA and a separate identity provider for that account | Versioning cost; append-style write patterns |
Regulated retention | Compliance mode or locked policy, plus legal hold when needed | Test in governance or unlocked mode first | Irreversibility |
Large virtualized estate exposed to hypervisor attacks | Lock-capable target outside the hypervisor and AD trust boundary | Malware scans of restore points | Snapshots are not backups |
Small team, weak detection | Tiered locks with a long-lock tier | More frequent restore tests | Storage growth |
Workflow: Implementing Immutable Backup for VM Workloads
1. Set the recovery objective. NIST recommends setting an RPO and RTO for each data asset. Decide the oldest restore point you must be able to reach.
2. Choose a lock-capable target and check prerequisites. For AWS, versioning is required, and once Object Lock is enabled, it cannot be disabled. Requirements differ by platform and version.
3. Create the target under separate ownership. Use a separate account, identity provider, and MFA from production.
4. Enable locking and test in governance mode first. Enabling compliance mode before testing is the step most likely to cause an irreversible mistake. Example only — verify the syntax against your AWS CLI version. Regions other than us-east-1 also need --create-bucket-configuration LocationConstraint=<region>.
aws s3api create-bucket --bucket <backup-bucket> --object-lock-enabled-for-bucket
aws s3api put-object-lock-configuration --bucket <backup-bucket> \
--object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":14}}}'5. Connect the backup software and set per-job locks. Vinchin Backup & Recovery documents two layers. Storage Protection blocks unauthorized applications from modifying data on the backup server's storage, and WORM Protection makes a job's backup data read-only until its retention period expires. The WORM option is available only when the selected storage has WORM enabled. Vinchin also supports S3-compatible object storage with Object Lock. The disk-level server backup documentation states that WORM is not supported when forever incremental is enabled. Check the help center for your release and workload, because availability depends on version, storage type, and job settings.
6. Set lock duration using the detection logic above, with a longer-lock tier.
7. Scan and test restores. NIST recommends testing critical backups at least monthly, with an end-to-end restore for strict-RTO applications, and periodically scanning past copies for poisoned ones. Vinchin offers a Malware Scan option on backup jobs. CISA advises taking care not to re-infect clean systems, for example by restoring into a clean VLAN.
8. Monitor and patch. Alert on retention, credential, and job changes, and keep backup software patched.
The most failure-prone steps are 2, 4, and 7.
Troubleshooting after Enabling Immutability
Symptom
| Likely cause
| What to do
|
Job fails after the lock is enabled, especially jobs that append to an existing file | Azure documents that create-then-append workloads such as SQL Backup to URL fail under an active retention policy or legal hold | Use a job design that writes new objects, check the platform's protected-append setting, and test before locking |
WORM option unavailable in a job | Storage lacks WORM, or forever incremental is on (per Vinchin documentation) | Enable WORM on the storage, or use another backup mode for that job |
Storage does not shrink after pruning | Locked points cannot be deleted before their retain-until dates (reasoned from lock behavior) | Size for retention × change rate, and use shorter locks on daily points |
Lock set too long by mistake | Compliance mode cannot be shortened, and locked Azure policies cannot be decreased | Test in governance or unlocked mode first |
Restore works but malware returns | The lock preserved infected data | Scan restore points and restore into an isolated segment |
FAQs
Q1: Is an immutable backup the same as an air-gapped or offline backup?
No. Immutable copies usually stay reachable and are protected by a time lock. Offline copies are disconnected. CISA's guidance names offline backups, and NIST recommends isolating cyber-attack recovery copies. Keep at least one copy that is offline or under separate control in addition to locked storage.
Q2: Can I enable Object Lock on an existing S3 bucket, and undo it?
AWS allows enabling it on an existing versioned bucket, but it cannot be disabled afterward and versioning cannot be suspended. Other S3-compatible platforms vary by product and version.
Q3: Does the lock carry over when backups are replicated to a DR bucket?
With S3 Replication, replicated objects take the source bucket's Object Lock configuration, and the destination bucket must also have Object Lock enabled. Objects uploaded directly to the destination follow the destination's own setting.
Q4: What should I do with locks when I suspect an intrusion?
Place a legal hold, or extend retention, on the restore points you may need. A legal hold stays until explicitly cleared. Do this at the storage layer, before the retain-until dates arrive.
Q5: Does Vinchin Backup & Recovery support immutable backup?
Yes, through documented mechanisms: per-job WORM Protection on WORM-enabled storage, S3-compatible object storage with Object Lock, and Storage Protection for the backup server's storage. Confirm availability against your version, storage type, and job settings.
Conclusion
Immutability settles one question: can anyone erase this copy before its retention ends? Pick the lock mode by who must not be able to override it, set the duration by how long an intrusion could go unnoticed, and keep storage credentials apart from production. A lock preserves data, not cleanliness, so recovery only counts once a restore has been tested.
