Immutable backup: what it protects against, how it works and how long to lock
Eurokommerz, Vienna, since 2006: Private AI/ML · IT Managed Services · Enterprise Training · AI Hardware & Software
- 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 server, 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
Eurokommerz × Vixen.UNO: Cyber Resilience Talk to an expert →
What immutable backup means, and how it differs from an air gap
Veeam defines an immutable backup as one that cannot be modified, deleted or encrypted for a defined period, and the industry uses the same definition. The lock applies to every account, including the backup administrator’s. A properly built immutable copy therefore survives a stolen backup administrator password, a compromised backup server and a ransomware operator who found the repository, because the storage itself refuses the delete command, whichever account sends it. The technical assessment of our cyber resilience service reviews your infrastructure, access and backups. Describe your backup setup and our team will help.
An immutable backup 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. Some vendors call their online vaults “logically air-gapped”; under the NIST definition such a vault is still an online copy. 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. An immutable copy can serve as the second “1” in Veeam’s 3-2-1-1-0 backup rule: three copies, two media, one off-site, one offline, air-gapped or immutable, and zero errors after recovery 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 (Veeam recommends XFS), and each backup file gets a lock file and an attribute with its expiry. On a server you build yourself, Veeam adds it with single-use credentials that are not stored anywhere in the backup infrastructure; Veeam’s user guide then has the administrator remove that account from the sudoers file and disable SSH, so a compromised backup server has nothing to log in with. In version 13 the recommended build is the Veeam Infrastructure Appliance with the Veeam Hardened Repository role: certificate-based authentication only, no SSH at all, no domain join. Multi-factor authentication for the appliance’s veeamadmin and veeamso accounts was enforced at deployment in 13.0; since 13.1 the appliance can be installed without it and MFA enabled later in the Host Management console, so check that both accounts have it. Whichever repository you deploy, keep the backup server on Veeam Backup & Replication 13.1.0.411 or later (13.0.3.63 on 13.0, 12.3.2.4934 on 12.3), the builds that fix CVE-2026-58069 according to Veeam’s KB4902 (as of October 2026). Our Veeam hardened repository guide covers the requirements, the build and the disk sizing.
| 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 server 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. Where SQL, Oracle or PostgreSQL log backups run, the immutability period must cover the whole chain, because their files are not extended with it; 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 other cloud object stores. 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. Other cloud object stores that Veeam supports follow the same pattern with their own versioning and immutability settings; only a locked retention policy is compliance-grade, because an unlocked one can be removed.
What it does not protect against
Immutability alone leaves the following threats open.
| 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 retention policy, or an account closed after an unpaid invoice |
| Linux governance mode | new in Veeam 13.1 for standard Linux repositories, it keeps “the flexibility of deleting backup at the system administrator level”, so a stolen administrator account of that server can still remove backups |
| 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 server; immutability is a logical control |
| One repository | a disk, RAID or firmware failure, or a fire, is not addressed by a flag; keep a second copy in a different network, far enough away to survive a disaster at the main site |
| 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 | clean copies restored into a network the attacker still controls can be compromised again; restore onto systems separated from the compromised ones and checked before use |
| 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 |
In Sophos’ 2024 survey, 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 addresses the attacks on backup infrastructure; the other parts of a cyber resilience design address the attacks on identity services and management planes.
Our cyber resilience service covers those parts with zero-trust access, network segmentation, multi-factor authentication and privileged access management. Tell us how administrators reach the backup servers, the hypervisor management and the identity services; the first call is free of charge.
How long the immutability period should be
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 and North Korean IT worker cases and nearly 400 for one campaign. Ransomware crews shorten it themselves, five days in 2024 when the attacker announced itself, 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; a defensible default for a primary hardened repository |
| Entire job retention | the right answer where the storage budget allows it; on object storage, check which immutability setting the repository uses |
| 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 the disk capacity for the extra days of restore points.
Verifying the immutable copy: SureBackup and Secure Restore
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 that only 44 per cent of playbooks included backup verification procedures.
What NIS2 and the implementing regulation require
NIS2 lists backup management and disaster recovery among the minimum measures in Article 21. Commission Implementing Regulation (EU) 2024/2690 applies only to the entities listed in its Article 1 (DNS service providers, TLD name registries, cloud computing, data centre, content delivery network, managed and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers); every other organisation in scope of NIS2 is bound by the national law that transposes Article 21 of Directive (EU) 2022/2555, and which text applies to you is for your legal department to confirm. For those entities, 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. GDPR Article 32 asks for the ability to restore availability of personal data in a timely manner and for regular testing of the measures. We found no use of the word “immutable” in these texts. An immutable copy is one technical way to protect the copies against deletion with stolen administrator credentials, and documented restore tests show that they can be recovered; our guide to NIS2 backup and business continuity requirements goes through the Annex point by point. Our disaster recovery service runs scheduled failover tests in an isolated environment, with a report after each test on what came up, how fast and what to fix.
What we do
Under our cyber resilience service, the team of our engineering partner Vixen.UNO starts with a paid technical assessment of infrastructure, access and backups, which ends with a risk map and a prioritised action plan; its price is fixed before work begins. Regular test restores, network segmentation, multi-factor authentication and privileged access management are part of the service, under one contract with Eurokommerz. We supply Veeam backup software and implement it together with Vixen.UNO, as our software page describes.
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 require immutable backups?
Our engineering partner Vixen.UNO reviews your backups in a technical assessment, and we supply and implement Veeam backup software. Describe your task in a few lines and our team will help: we reply within one business day. The first call is free of charge.
Talk to an expertWe reply within one business day