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.

How Immutability Works 

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.

How Immutability Works 

 

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, he has only 3 days to react to malicious actions. If he 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.

How Immutability Works 

Example 2. Long Immutability Period

In this scenario, a user has 7 days to react to malicious actions. If he 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 he still has 2 days to revert to the 1st day, find the necessary state of a backup chain and restore data.

How Immutability Works 

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. Although the immutability period does not depend on the retention of the backup chain, it will preserve more restore points in addition to the restore points stored according to a retention policy  to guarantee consistency of earlier states of the backup chain and the ability to roll back to it.

Apart from the immutability period set for each object storage repository, Veeam Backup & Replication automatically adds up to 10 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 (10 days)

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.
  • Block Generation is 10 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.

Important

Consider the following:

  • If retention policy for backups with GFS flags, backups created by VeeamZIP jobs and exported backup files exceeds immutability settings, Veeam Backup & Replication applies immutability according to the retention that is defined for these types of backups. Immutability settings defined for an object storage repository are ignored.
  • If you add an object storage repository as an extent of the performance tier, immutability depends on the scale-out backups repository configuration. For more information, see Immutability for Performance Tier.

Page updated 3/19/2024

Page content applies to build 12.1.1.56