Immutable backup: what it really protects against, how it works, and how long to lock
- An immutable backup cannot be modified, deleted or encrypted for a defined period, by anyone, including the backup administrator; it is a logical control, not an air gap
- On a Veeam hardened repository the lock is the Linux immutable attribute set by a root-level service, 7 to 9,999 days, counted from the last restore point of the chain and re-applied to the whole chain
- On object storage Veeam always writes S3 Object Lock in compliance mode, 1 to 999 days, plus a block generation of 10 or 30 days; not even the cloud account’s root user can delete before expiry
- It does not protect against an attacker who waits out the window, data encrypted at the source and backed up faithfully, a compromised cloud account in governance mode, physical access to the box, or a restore into a still-infected network
- Size the window against dwell time: Mandiant’s global median was 14 days for 2025 intrusions; seven days is the technical floor, thirty days or the full job retention is the defensible default
What immutable means, and what it does not
Veeam’s definition is the industry’s: a backup that cannot be modified, deleted or encrypted for a defined period. The important word is anyone. A properly built immutable copy survives a stolen backup administrator password, a compromised backup server and a ransomware operator who found the repository, because the delete command is refused where the data lives, not where the request comes from.
It is not an air gap. The NIST definition of an air gap requires no physical connection and no automated logical connection; an object-lock bucket and a hardened repository are online, reachable and writing every night. Vendors who describe their online vaults as “logically air-gapped” are using marketing language. The distinction matters when a regulator or an auditor asks what “offline” means in your backup policy, and it matters in the failure cases at the end of this article. Immutability is the “1” in Veeam’s 3-2-1-1-0 rule: three copies, two media, one off-site, one offline or immutable, zero errors after verification.
How a hardened repository enforces the lock
A Veeam hardened repository is a Linux server with local block storage. Two services run on it: the transport service, which moves data and runs as a non-root user, and the immutability service, which runs as root as its child, checks the files every twenty minutes and sets or clears the immutable attribute. The filesystem has to support immutable files and extended attributes, which is why XFS is the recommended choice, and each backup file gets a lock file and an attribute with its expiry. The server is added with single-use credentials that are not stored anywhere in the backup infrastructure; afterwards the account loses sudo and SSH is disabled, so a compromised backup server has nothing to log in with. In version 13 the recommended build is the Veeam infrastructure appliance with the hardened repository role: certificate authentication only, no SSH at all, multi-factor authentication that cannot be switched off, no domain join.
| RULE | WHAT IT MEANS IN PRACTICE |
|---|---|
| Lock period | 7 to 9,999 days; the wizard refuses anything shorter |
| Where the clock starts | at the last restore point of the active chain, and the period is re-applied to every file of that chain on each successful run |
| Worked example | full on 12 January, last increment on 14 January, ten-day period: everything in the chain is locked until 24 January |
| Backup method | forward incremental with periodic fulls only; reverse and forever-forward would have to rewrite locked files |
| GFS points | a yearly full is locked for the longer of the repository period and its own lifetime; its increments only for the repository period |
| Shortening the setting | affects future restore points only; files already locked keep their expiry |
| Metadata | the .VBM file is never locked because it is rewritten every run; import from the .VBK files if it is lost |
| Failed sessions | the flag is set only after a completed session; a failed run followed by a new full leaves the failed files unlocked |
| Log backups | SQL, Oracle and PostgreSQL log files are not extended with the chain; the period must cover the whole chain or a log restore fails |
| Clock attacks | a clock shift of more than 24 hours, or the box switched off for more than 24 hours, blocks all retention until an administrator resets it |
Veeam Backup & Replication 13.1 documentation, September 2026; the mechanics are the same in 12.3.
Two design rules follow. The immutability period must be at least the length of the chain, or the oldest files unlock before the chain closes; and immutability overrides retention, so files whose retention has expired stay on disk until the lock expires, which is capacity you have to plan for.
How object lock enforces it
On Amazon S3 and S3-compatible storage the lock is a property of the object version. Object Lock requires versioning, is enabled on the bucket and cannot be disabled afterwards. Each version carries a retain-until date in one of two modes. Compliance mode means nobody, including the root user of the account, can delete or shorten it; AWS states that the only way out before expiry is to delete the account. Governance mode can be bypassed by a principal holding the bypass permission who sends an explicit header, which is exactly the permission a compromised cloud administrator would use. Veeam therefore writes every object in compliance mode, with a period of 1 to 999 days, and manages retention itself; the bucket must have Object Lock and versioning on, default retention off and no lifecycle rules, and those settings must never be changed after the bucket is added.
Veeam locks data blocks rather than files, and adds a block generation so that increments written within a generation share the full backup’s expiry without an API call per block: 30 days on Amazon S3, IBM, Google and 11:11, 10 days on everything else, including on-premises S3-compatible appliances and Azure. The actual time on storage is therefore the job retention or the minimum immutability, plus the block generation: Veeam’s own example is 13 days of retention, 7 days minimum immutability and a 10-day generation, deleted after 23 days. Since the first 13.0 patch the default mode locks for the entire retention period rather than the minimum. Azure works the same way with version-level immutability and blob versioning, on new containers only, and only a locked policy is compliance-grade; an unlocked one can be removed.
What it does not protect against
The list is longer than the sales deck.
| THREAT | WHY IMMUTABILITY ALONE FAILS |
|---|---|
| An attacker who waits | locks expire; with a seven-day window and a median dwell time of two weeks, the copies you need may be mutable by the time you notice |
| Data encrypted at the source | the repository faithfully keeps what it was given; inline scanning is off by default and does not see dormant malware |
| Cloud account compromise | governance mode bypass, an unlocked Azure policy, or simply an unpaid bill and a closed account |
| Misconfigured buckets | default retention on, lifecycle rules, versioning toggled, an existing container reused: all documented by Veeam as causing data loss |
| Physical, console or out-of-band access | someone with a live USB stick or an unsecured BMC can reformat the box; immutability is a logical control |
| One repository | a disk, RAID or firmware failure, or a fire, is not addressed by a flag; the EU implementing rules on NIS2 require copies in a different network at sufficient distance |
| A window shorter than the chain | log backups are not extended, failed runs stay unlocked, and the .VBM is never locked |
| Restoring into the compromised network | the copies are clean; the environment is not; DORA requires restore on physically and logically segregated systems |
| Replicas mistaken for the immutable copy | a replica is a live, mutable VM copy that replicates encryption and can be deleted by a compromised hypervisor administrator |
Sophos measured the stakes in 2024: 94 per cent of organisations hit by ransomware said the attackers went for the backups, and 57 per cent of those attempts succeeded. Mandiant’s 2026 report states that ransomware operators actively targeted backup infrastructure, identity services and virtualisation management planes. The immutable copy is the answer to the first sentence of that finding; the rest of the cyber resilience design answers the others.
How long to lock: the dwell-time argument
The window has to outlast the time an intruder spends inside before anyone notices, plus the time it takes to decide and restore. Mandiant’s global median dwell time was 11 days for intrusions in 2024 and 14 days for 2025, with a long tail: 122 days for espionage cases and about 400 for one campaign. Ransomware crews shorten it themselves, five days when the attacker announces the encryption, but the data was often staged and exfiltrated well before. On the recovery side, Sophos’ 2026 survey found only 55 per cent of victims back within a week and 83 per cent within a month.
| SETTING | VERDICT |
|---|---|
| 7 days | the technical floor on a hardened repository, not a recommendation; shorter than the median dwell time |
| 14 days | matches the 2025 median; half of all intrusions run longer |
| 30 days | covers most detection and decision cycles; our default for the primary hardened repository |
| Entire job retention | the version 13 default on object storage; the right answer where the storage budget allows it |
| GFS monthly and yearly points | locked automatically for their whole lifetime; the long-term protection needs no extra setting |
Judgement on the last three rows; the mechanics and the dwell-time figures are sourced.
On object storage every extra day is paid storage, plus the block generation, which is why Veeam itself warns against locking longer than the job retention. On a hardened repository the cost is disk, and disk is cheap compared with a week of the company standing still.
Proving the copy works
The zero in 3-2-1-1-0 is verification. SureBackup boots machines from the backup in an isolated lab, runs heartbeat, ping and application tests and can scan the content with antivirus and YARA rules; a lighter mode verifies and scans without a lab. Secure Restore scans a restore point before it touches production and aborts or restores with restrictions if it finds malware. Neither replaces a rehearsed recovery order, which our RPO and RTO guide covers, and neither helps if the restore target is the same network the attacker still sits in. Veeam’s 2025 survey found only 44 per cent of playbooks included backup verification procedures; that number is the reason this section exists.
The regulatory hooks
NIS2 lists backup management and disaster recovery among the minimum measures in Article 21; the Commission’s implementing regulation of October 2024 spells out storing backup copies in locations that are not in the same network, retention periods based on business and regulatory requirements, regular integrity checks and regular restore tests. DORA’s Article 12 requires documented backup policies with scope and minimum frequency, periodic testing, and restoration on systems physically and logically segregated from the source. GDPR Article 32 asks for the ability to restore availability of personal data in a timely manner and for regular testing of the measures. None of them says “immutable”; all of them are easier to answer with an immutable copy that has been restored on a schedule, which is what our disaster recovery service is built around.
What we build
Eurokommerz designs and runs backup estates on Veeam across the EU with our engineering partner Vixen.UNO: a hardened repository on local disk as the primary immutable copy, an object-lock copy off-site in compliance mode, GFS points locked for their lifetime, SureBackup on a schedule, and a written window that matches the company’s recovery plan rather than the wizard’s minimum. Send us the current job list and retention, and we will return the gaps.
FAQ
Is an immutable backup the same as an air-gapped backup?
How long should the immutability window be?
Can the backup administrator delete an immutable backup?
Why is the actual retention longer than I configured on object storage?
Does immutability protect against ransomware that encrypted the files before the backup?
Does NIS2 or DORA require immutable backups?
Send us the backup job list, the retention and where the copies live. We will return the immutability gaps, the window we would set and the restore test plan. We reply within one business day.
Talk to an expertWe reply within one business day