Hardened Repository

To protect your backup files from loss as a result of malware activity or unplanned actions, you can add to your backup infrastructure a hardened repository based on a Linux server. The hardened repository supports the following features:

• Immutability: when you add a hardened repository, you specify the time period while backup files must be immutable. During this period, backup files stored in this repository cannot be modified or deleted.
• Single-use credentials: credentials that are used only once to deploy Veeam Data Mover, or transport service, while adding the Linux server to the backup infrastructure. These credentials are not stored in the backup infrastructure. Even if the Veeam Backup & Replication server is compromised, the attacker cannot get the credentials and connect to the hardened repository.

Supported Backups

In the hardened repository, you can store the following backups created with backup and backup copy jobs:

• Image-level virtual machine backups and backup copies (VMware, Hyper-V, Cloud Director, Nutanix AHV, RHV)
• Physical machine backups and backup copies (Microsoft Windows, Linux, MacOS, AIX, Solaris)
• Cloud machine backup copies (Microsoft Azure, AWS, Google Cloud Platform)
• NAS backups and backup copies
• Application-aware processing log backups and backup copies (Microsoft SQL transaction log files, Oracle archived log files, PostgreSQL WAL files)
• Enterprise application backups and backup copies (SAP HANA, Oracle RMAN, SAP on Oracle, Microsoft SQL Server)

Also, backups created with VeeamZIP, Copy Backup jobs, Move Backup jobs, and Export Backup jobs are supported.

How Immutability Works

Immutability is managed by the transport service and the immutability service. After installation, the transport service runs as a non-root user. It communicates with the backup server, gets information about the immutability time period, and forwards it to the immutability service that manages immutability attributes.

The immutability service runs with root permissions as a child process of the transport service. It checks file immutability attributes every 20 minutes, calculates the time until a file needs to be immutable, and sets or removes the immutable attribute.

The described mechanism prevents backup files from being deleted or modified by a potential attacker even if they somehow exploit the transport service. For more information about the hardened repository architecture, see Protect against Ransomware with Immutable Backups.

For image-level VM backups and physical machine backups, immutability works in the following way:

1. For each backup file, Veeam Backup & Replication creates a.veeam.N.lock file that contain information about the immutability time period. Also, the xattr attribute with immutable time period is set on each backup file. These files are stored on the hardened repository.
2. Backup files become immutable for the configured time period (minimum 7 days, maximum — 9999). The immutability period is set according to the following:

• The count of the immutability period starts from the moment the last restore point in the active backup chain is created. For example:

• The full backup file of the active chain was created on January 12. The first increment was created on January 13. The second and last increment was created on January 14.
• The immutability period is set for 10 days and will be automatically extended for all backup files in the active chain. If there are several chains in the backup, Veeam Backup & Replication does not extend the immutability for inactive chains.
• Full and incremental backup files will be immutable until January 24: the date of the last restore point creation (January 14) + 10 days.

• The immutability flag is set on the file only when the current backup session is completed.

• If you increase the immutability period in repository settings, a new value will be applied for the active and next chains. If you decrease the immutability period, a new value will be applied only for the next chains.
• If you use GFS retention policy, see Retention Scenarios.

3. When the immutability time period expires, the immutability service makes backup files mutable again so they can be deleted or modified.

For application-aware processing log backups, immutability works in the following way:

1. For each log backup file, Veeam Backup & Replication creates a.veeam.N.lock file that contain information about immutability time period. These files are stored on the hardened repository.
2. Log backup files become immutable for the configured time period (minimum 7 days, maximum — 9999). The immutability period is set according to the following:

• Newly created log backup files are being updated several times according to the interval settings. Thus, the count of the immutability period starts and the immutability flag is set on the file only when the log backup job finished writing any data to the VLB file.
• The immutability period is not extended for log backup files in the active chain. If there are several chains in the backup, Veeam Backup & Replication also does not extend the immutability for old chains.

• If you increase the immutability period in repository settings, a new value will be applied for all log backup files created after the last successful image-level VM backup or physical machine backup. If you decrease the immutability period, a new value will be applied only for the next log backup files.
• If you use GFS retention policy, see Retention Scenarios.

3. When the immutability time period expires, the immutability service makes backup files mutable again so they can be deleted or modified.

For information on how immutability works for NAS backups and enterprise application backups, see the following sections:

• NAS Backup

• Veeam Plug-in for Oracle RMAN
• Veeam Plug-in for SAP HANA
• Veeam Plug-in for SAP on Oracle
• Veeam Plug-in for Microsoft SQL Server

Hardened Repository as Performance Extent

You can add a hardened repository to your scale-out backup repository as a performance extent. For more information, see Scale-Out Backup Repository and Add Performance Extents.

If you use the Capacity Tier with move option, note that having a hardened repository as a performance extent will affect the Capacity Tier behavior. You will not be able to move immutable backup files, because they cannot be deleted from the performance extent. Veeam Backup & Replication will copy such backup files to the Capacity Tier. When the immutability time period is over, Veeam Backup & Replication will delete these files from the performance extent. For more information on copy and move policies, see Copying Backups to Capacity Tier and Moving Backups to Capacity Tier.

If you evacuate your backups from an immutable performance extent, Veeam Backup & Replication will copy them instead of moving. When the immutability time period is over, you will need to delete these files manually. If the target extent is also immutable, the immutability of the target extent will apply to copied backup files. For more information on evacuating backups, see Evacuating Backups from Performance Extents.

When you evacuate backups to the hardened Linux extent, the immutability period of the full chain will be chosen as maximum between the following values:

• The immutability period determined for the original chain.
• The time of creation of the last restore point in the chain plus the immutability period determined for the target extent.

Retention Scenarios

Consider the following retention scenarios:

• An immutability retention overrides a job retention: if the job retention period is shorter than the immutability period, Veeam Backup & Replication does not delete backup files when the retention period is over, but only when the immutability period expires.
• Veeam Backup & Replication compares the immutability period of the backup repository and the GFS backup file lifetime, and sets an immutability period for full backup files with GFS retention policy as equal to the longest of these periods. For example: the backup repository immutability period is 10 days; the GFS backup file lifetime is 3 years; the backup file will be immutable for 3 years; the increments from this full backup file will be immutable for 10 days from the moment of the last increment creation.
• If a hardened repository is a part of a scale-out backup repository with the capacity tier added and the move policy enabled, Veeam Backup & Replication ignores the GFS retention policy. The immutability time period for full backup files equals the period specified in the setting of a hardened repository.
• The immutability period for backup files produced with VeeamZIP or Export Backup jobs is set according to the following:

• [With enabled retention period] Veeam Backup & Replication compares the immutability period of the backup repository and the retention period, and sets an immutability period for backup files with retention period as equal to the longest of these periods. For example: the backup repository immutability period is 1 month; the VeeamZIP or Export Backup backup file lifetime is 7 years; the backup file will be immutable for 7 years.

• [With disabled retention period] Veeam Backup & Replication ignores the VeeamZIP or Export Backup retention period. The immutability time period for VeeamZIP or Export Backup backup files equals the period specified in the setting of a hardened repository.

In This Section

• Requirements and Limitations
• Preparing Ubuntu Linux Server as Hardened Repository
• Adding Hardened Repository
• Managing Hardened Repository