What is Veeam immutable backup?
Veeam immutable backup is a Veeam restore point that the storage underneath refuses to change or delete until a set date. Veeam asks for the lock, and the repository enforces it.
Locks matter because full recovery is still rare. In Veeam's Data Trust and Resilience Report 2026, only 28% of ransomware victims got all of their data back.
Two places Veeam can put the lock
The Veeam backup server is one of the first systems an intruder looks for. Its console can delete every restore point it manages. Immutability moves the final say from that server to the storage, so a stolen console cannot erase locked copies.
| Repository | How the lock works | Who can still lift it early |
|---|---|---|
| Hardened Repository (Linux) | A file system flag on each backup file | The root account on that Linux server |
| S3 object storage | S3 Object Lock on each stored object | Depends on the lock mode |
On object storage, governance mode can be lifted by accounts given a special bypass permission, while compliance mode holds against everyone until its date.
Why the lock outlasts the job setting
The lock is rarely the number shown on the backup job. Restore points share data blocks, a bit like chapters in a book that several editions reuse. A block cannot unlock while any newer restore point still needs it.
So Veeam adds a few extra days on top of the job's retention, and renews locks in batches. A 14-day job often keeps data locked for several weeks. Those extra days show up as used capacity, and storage plans need room for them.
Gaps worth checking
- Lock shorter than the attacker's stay. An intruder who disables jobs and waits past the lock finds old restore points already expired. Retention policy design sets lock length against that risk.
- Governance mode with broad keys. A stolen storage key with the bypass permission can remove the lock.
- Files outside the lock. Small chain metadata files and some application log backups are not locked.
- Quiet changes to jobs. A stolen console can still stop new backups and shorten future retention, a form of backup tampering.
When an attack does land, locked restore points survive a wiped backup server. Ransomware recovery then starts by rebuilding the server and re-importing them.
ARTESCA and Veeam immutable backup
Both S3 Object Lock modes are available on ARTESCA, along with retention periods and legal holds. Scality's Veeam compatibility page lists Object Lock as validated with Veeam Backup & Replication. Veeam sets each lock date, and ARTESCA enforces it on every stored object version.
With compliance mode, neither a stolen Veeam console nor a stolen ARTESCA administrator login can shorten those dates. ARTESCA does not lengthen a lock Veeam set too short. Once a date passes and Veeam deletes the data, it is gone.
Related terms
- Veeam Hardened Repository: the Linux option, locked by a file system flag.
- S3 Object Lock: what enforces Veeam locks on object storage.
- Immutable backup: the general idea, across tape, Linux and object storage.
- Retention policy design: setting lock length against how long attackers hide.