Immutable Backup

How Veeam immutable backup works: WORM and retention lock

Immutable backup is built on the WORM (Write Once, Read Many) principle. As soon as a backup file is written to the repository, a retention lock is applied, and until the lock expires the file cannot be deleted, overwritten or encrypted. The lock is enforced at the storage layer, not inside the backup software; so compromising the backup server or an administrator account is not enough to delete the backup.

Veeam applies this lock on S3-compatible object storage using the Object Lock feature. An immutability period is defined for each backup chain; incremental backups are also protected as long as the chain they belong to remains locked. Object Lock has two modes:

• Governance mode: accounts with special permissions can remove the lock; this provides flexibility during testing and transition periods.
• Compliance mode: no account can remove the lock before the period ends; this is the strictest protection against ransomware.

The concept is explained in detail in our what is immutable backup guide.

Service assurance: The service level agreement sets a monthly availability target of 99.9% for backup services; for a critical incident such as a suspected ransomware attack, the first-response target is 15 minutes.

When is immutable backup the right choice?

Not all data needs an immutable copy with the same priority; adding one alongside standard backups is recommended in the following cases:

• The backup server is joined to the domain: the risk of an attacker reaching backups with an administrator account increases.
• The only copy sits on the same network: ransomware spreading across the network can encrypt backup files too.
• You keep audit logs and archives: you need to show that records have not been altered afterward.
• You operate under ISO/IEC 27001 or ISO 22301: backup integrity and business continuity controls must be demonstrable.
• There is only one backup copy at a remote site: if that copy is lost, there is no other clean point to recover from.

The immutable layer does not replace your existing backup setup; it is a security layer added on top of it. Day-to-day restores are done from the fast-access standard backup repository, while the immutable copy comes into play only in scenarios where production and standard backups are damaged together. This distinction also determines which data the lock period applies to and how storage capacity is planned. Two questions are asked when setting the lock period: in the worst case, how long could it take to detect an attack, and how far back is it acceptable to go to reach a clean copy? The answers are settled jointly by the business units and the information security team; the period is then adjusted to the structure of the backup chain.

Common immutable backup mistakes

1. Setting the lock period too short: ransomware often sits undetected on the network for some time; if the lock is shorter than that dwell time, the clean copy can be lost too.
2. Setting the lock period unnecessarily long: since locked data cannot be deleted before the period ends, storage costs grow uncontrollably.
3. Sharing backup infrastructure credentials with production accounts: without separation of privileges, the protection the lock provides is weakened.
4. Never testing a restore: which date the clean copy is from and how long it takes to bring up can only be known through testing.

At MAV Cloud, immutable backups are kept on S3-compatible object storage and designed together with the overall backup setup, that is, our cloud backup service.

To check the other core controls alongside immutable backup, use the ransomware resilience check; it ranks the gaps by importance.

On-premise immutable storage or cloud immutable backup?

Immutable storage can also be built on-premise. The most common way in Veeam environments is a hardened repository on a Linux server, where backups are locked for a defined period and cannot be changed or deleted during it (Veeam Help Center). An on-premise repository restores quickly over the local network, but it stays in the same building as production: fire, flooding, theft or someone with physical or console access to the server can still affect it, and the hardware, patching and capacity planning remain the company’s job.

Cloud immutable backup keeps the locked copy at another location. The usual recommendation is to combine the two: a local immutable copy for fast everyday restores and an offsite immutable copy for disasters, in line with the 3-2-1-1-0 approach described in our 3-2-1 backup rule guide. MAV Cloud provides the offsite layer with Veeam and Object Lock on S3-compatible object storage in its Equinix Istanbul infrastructure.