How Immutability Works

Immutability is the state of data that prevents it from being modified or deleted. Veeam Backup & Replication applies immutability to the state of a backup chain within a certain period of time. After you enable immutability, Veeam Backup & Replication prohibits deleting data from object storage repositories until the immutability expiration date comes. Immutability settings configured for object storage repository are applied to the whole backup chain and all its restore points.

To make data immutable, Veeam Backup & Replication utilizes the technology that prevents data from deletion and allows you to keep several versions of objects. The selected technology depends on the type of object storage:

• Object lock and Versioning — for Amazon S3 Storage, S3 Compatible, IBM Cloud, Wasabi Cloud.
• Version-level WORM and blob versioning — for Azure Storage.

For more information, see Enabling Immutability.

Immutability Period

Veeam Backup & Replication protects a backup chain and all its restore points during a certain immutability period. The immutability period is the number of days you have to respond to malicious actions. Within this period, you can roll back to the earlier state of your backup chain. To roll back data, you need to run Veeam PowerShell. For more information, see the Sync-VBRObjectStorageRepositoryEntityState cmdlet.

Before you configure immutability settings for your object storage repository, consider how immutability settings can influence the period within which you can restore data in case of malicious actions. The longer the immutability period, the more time you have to perform the necessary actions and roll back to the working state of your backup chain.

In both examples, a user configures a backup job with the same retention period and a backup method but a different immutability period. Thus, in the first scenario, the user has less time to react to malicious actions.

Example 1. Short Immutability Period

In this scenario, a user configures a backup job with a short immutability period. Then, the user has only 3 days to react to malicious actions. If the user is not aware of the corruption and does not attempt to restore data within 3 days, all data will be lost.

The backup job is created with the following settings:

• The backup method is forever forward incremental.
• The job retention policy is set to 30 days.
• The immutability period is set to 3 days.

On the 2nd day of a month, due to malicious actions, the job retention policy is set to 1 day. Since the immutability period is set to 3 days, the object storage repository keeps all states of a backup chain up to 3 days. On the 5th day, the user attempts to revert back to the state it was before the attack, but since 3 days have already passed, the state of the backup chain is not available anymore.

Example 2. Long Immutability Period

In this scenario, a user has 7 days to react to malicious actions. If the user is not aware of the corruption and does not attempt to restore data within 7 days, all data will be lost

A backup job is created with the following settings:

• The backup method is forever forward incremental.
• The job retention policy is set to 30 days.
• The immutability period is set to 7 days.

On the 2nd day of a month, due to malicious actions, the job retention policy is set to 1 day. The immutability period is set to 7 days, therefore, the object storage repository keeps all restore points for 7 days. On the 6th day, the user finds out the malicious actions took place, however the user still has 2 days to revert to the 1st day, find the necessary state of a backup chain and restore data.

Object Storage Actual Retention

When you configure an object storage repository, keep in mind that the immutability period affects the total number of restore points stored in the object storage repository.

Apart from the immutability period set for each object storage repository, Veeam Backup & Replication automatically adds several days to the immutability expiration date to reduce I/O operations and associated costs. This period is called Block Generation. You do not have to configure it, the Block Generation setting is applied automatically. For more information, see Block Generation.

Therefore, the actual retention should be calculated according to the following formula:

Actual retention = job retention policy + immutability period + block generation period

For example, the backup job is created with the following settings:

• The job retention policy is set to 30 days.
• The immutability period is set to 14 days immutability.

• Default Block Generation period is 10 days (for Amazon S3 object storage and IBM Cloud object storage it is 30 days).

According to the backup job retention, an object storage repository will keep backups for 30 days. The immutability period adds extra 14 restore points as a delta that prolongs the job retention policy. Plus, 10 days from the Block Generation are on top. Thus, you need to plan storage that will be able to keep your backups for 30 + 14 + 10 days = 54 days.