Veeam Hardened Repository in v13: Build It from Scratch

The Veeam Hardened Repository (VHR) is a Linux-based backup repository where backup files are set immutable after they are written. Immutable means that even root cannot delete, modify, or move those files until the immutability period you configure expires. This is enforced by the Linux kernel's chattr immutable flag, not by Veeam software alone. An attacker who compromises your VBR server, your backup server credentials, or even the root account on the Linux machine cannot delete the backup files while the flag is set. The Veeam Immutability Service checks and enforces the flag every 20 minutes.

This is different from object storage immutability like S3 Object Lock. The Hardened Repository is local or directly attached block storage on a Linux machine you control. No cloud dependency, no egress fees, full control over the hardware. It is the on-premises answer to immutable backups, and in v13 it has become significantly easier to deploy thanks to the Veeam Infrastructure Appliance option.

The authentication model in v13 also deserves a mention. When you add a Hardened Repository, you use single-use credentials for the initial deployment of Veeam Data Mover. After that, those credentials are discarded. VBR connects to the repository using certificate-based authentication instead of stored passwords. This means a credential theft from the VBR database does not yield usable access to the repository.

For production use, size the Hardened Repository server with at least 8 CPU cores, 32 GB RAM, and dedicated storage. Shared storage between the OS and backup data is a management headache and a failure risk. Use at least two separate disks: one for the OS, one or more for backup data. The backup data disk should be dedicated block storage, not an NFS mount, not an SMB share. Veeam explicitly does not support NFS or CIFS as the underlying storage for a Hardened Repository.

For storage sizing, your target is raw capacity that can hold at minimum two full backup copies of your protected data, plus headroom for incremental chains and growth. A common starting point is protected data size multiplied by 1.5 to 2x for the data disk. Larger environments benefit from RAID 10 for the balance of performance and redundancy, or RAID 6 for better capacity efficiency when spinning disks are involved. RAID is configured at the hardware layer before the OS is installed.

Supported Linux distributions with advanced XFS integration in v13 include Ubuntu 20.04 and 22.04, RHEL 8 and 9, Rocky Linux 8 and 9, AlmaLinux 8 and 9, Debian 11 and 12, and SLES 15. Ubuntu 22.04 and Rocky Linux 9 are the most commonly deployed choices in production environments today.

Install your chosen Linux distribution with a minimal or server configuration. Do not install a desktop environment. After installation, apply all available security updates before you do anything else. The VHR is a security-critical machine and you do not want it to start life with outstanding kernel CVEs.

XFS is Veeam's recommended file system for Hardened Repositories for two reasons. First, it supports immutable file attributes via chattr, which is the kernel mechanism Veeam relies on. Second, XFS supports block cloning (reflinks), which allows Veeam to create synthetic full backups without actually duplicating data on disk. The space savings from block cloning can be substantial, especially when you have a lot of incremental backups referencing the same base data blocks.

Before you can add the Hardened Repository, the Linux machine must be added as a managed Linux server in VBR. Go to Backup Infrastructure, right-click Managed Servers, select Add Server, and choose Linux. Enter the FQDN or IP address of the machine. On the credentials step, select or add the SSH credentials for the Veeam service account you created. VBR will connect and deploy the required components. During this step, VBR uses the credentials to install Veeam Data Mover and Veeam Installer Service. After this step, the credentials are stored in VBR's credential manager but will be used as single-use credentials once the Hardened Repository is configured.

With the repository added, target your backup jobs at it the same way you would any other repository. In the job wizard, select the Hardened Repository as the backup repository on the Storage step. There is one important constraint: the only permitted backup methods are Forward Incremental with active full, and Forward Incremental with synthetic full. Reverse incremental and Forever Forward Incremental are not compatible with immutable repositories because they require modifying backup files after the fact, which the immutability flag prevents.

Set your active full or synthetic full schedule. Weekly synthetic fulls are the most common configuration. Each synthetic full benefits from XFS reflinks, so the space cost of a synthetic full on a properly configured Hardened Repository is much lower than on a standard repository.

After the first backup job runs to the Hardened Repository, you can verify that immutability is working by SSHing to the Linux machine and checking file attributes on a backup file. Use lsattr on a .VBK or .VIB file in the backup directory. The output should include the i flag, which is the immutable attribute. A file with this flag set cannot be deleted or modified even by root until the flag is cleared, which only happens when the Veeam Immutability Service determines the immutability period has expired.

In the VBR console, you can see the immutability expiry date for each restore point by right-clicking a backup in the inventory and selecting Properties. The immutability expiry date will be listed alongside the standard restore point metadata.

A few constraints that catch people off guard. VBM metadata files are not immutable. The .VBM file for each backup chain is updated on every job run, so immutability cannot be applied to it. This does not compromise the protection on the actual backup data files (.VBK and .VIB), but it is worth knowing. Symlinks in the backup directory path are not supported. The repository path must be a direct path to a real directory. The Hardened Repository cannot be shared between two different VBR servers. One VBR installation owns it. If you add it to a second VBR server, backups from the first will fail. Use a Scale-Out Backup Repository with multiple extents if you need to spread backup load across multiple repositories managed by one VBR server.

The immutability period cannot be shortened after it is set. It can only be extended. Think carefully about the period you configure before writing the first backups. A 30-day immutability period means that even if you want to free up space urgently, you cannot delete those files for 30 days.