Veeam hardened repository: requirements, setup in version 13.1 and the mistakes that weaken it

What a Veeam hardened repository needs in version 13.1

A Veeam hardened repository needs a Linux server with block storage, backup chains that never rewrite a file once it is written (forward incremental with periodic full backups), and no administrative path to root on that server once it holds backups. In Veeam Backup & Replication 13.1, the current version as of October 2026, Veeam’s user guide calls the Veeam Infrastructure Appliance “the recommended option”: a Veeam-built Linux image on which you select the Veeam Hardened Repository role, and a repository built that way must use certificate-based authentication and cannot be reached over SSH. For the immutability period you set, backup files “cannot be moved, modified or deleted, but can be copied”.

Version 13.1 has been available since 29 July 2026. Veeam’s download page lists build 13.1.1.18, dated 8 September 2026, as the latest. How the lock is applied to each file, the limits of the period and what immutability does not stop are in our guide to what immutable backup protects against.

What changed from 12.3 to 13.0 and 13.1

Up to version 12.3, a hardened repository was a Linux server you installed yourself or built from Veeam’s hardened repository ISO. Veeam deployed its data mover there with single-use credentials, which serve only for that deployment. Veeam’s security best practice guide gives the service account temporary sudo rights for that step, then tells the administrator to “permanently disable SSH and remove SUDO right for the veeamsvc account”. Version 13.0 brought the Veeam Infrastructure Appliance, a bootable “JeOS (Just Enough Operating System) ISO” with only the services Veeam roles need.

Veeam Help Center: Backup & Replication 13.1 user guide, What’s New in 13.1 (24 July and 11 August 2026), archived 13.0.2 and 12 user guides; Veeam Security Best Practice Guide.

Governance mode, new in 13.1, is meant for Linux repositories that want to keep “the flexibility of deleting backup at the system administrator level”, in Veeam’s words, and it may carry roles a hardened repository does not allow. An administrator of that Linux server can still remove backups, so it does not replace a hardened repository where the threat is a stolen administrator account.

Setup with the appliance, a hand-built Linux server or a virtual machine

For the appliance, Veeam’s user guide sets this order:

1. Mount the ISO image, select the deployment type, begin the installation and accept the licence agreements.
2. In the Initial Configuration wizard, select the Veeam Hardened Repository role, set the hostname and review the network settings.
3. At the Time step, add NTP or NTS servers you control; the default is time.nist.gov, and Veeam notes that server time affects multi-factor authentication and job schedules.
4. Configure the host administrator (veeamadmin) and security officer (veeamso) accounts for two different people, each with MFA.
5. Add the repository in the backup console, set the path and the immutability period at the Repository step, then disable the Host Management console Web UI, as Veeam strongly recommends; on an appliance hardened repository it switches itself off 24 hours after being enabled.

The 13.1 user guide still documents a server you configure yourself; it has to meet the backup repository system requirements of your exact build, so check the distribution list there before every upgrade. Veeam’s security guide, written for version 12, names Rocky Linux or Red Hat for a manual installation, with Ubuntu or SUSE also possible. A Linux-based backup server can also hold immutable backups, but Veeam warns that this “increases the attack surface of your backup infrastructure”.

Veeam’s version 12 guide said: “To reduce the attack surface, use a physical machine with local storage.” A Veeam product manager’s hardware guide, updated on 25 February 2026, recommends a server with internal disks, which removes the risk of an attacker deleting everything on a storage system. The appliance can run as a virtual machine (the 13.1 release notes list a known issue for such VMs), but such a repository is only as safe as the hypervisor accounts that can delete its disks, the subject of our guide to protecting ESXi and vCenter from ransomware.

Disks, RAID and the XFS file system

Veeam’s hardware guide asks for separate operating system and data disks, SSDs for the operating system, a RAID controller with battery-powered write-back cache, and redundant power and network. For the data disks it names RAID 6 or 60 with at least one spare disk, which it says most customers choose over RAID 10, and it rules out RAID 5, 50 and other single-parity layouts. Veeam’s best practice guide advises volumes of up to 500 TB, filled to no more than 80 per cent.

The same guide recommends XFS with a 4 KB block size, because XFS supports both Fast Clone and immutability. Fast Clone builds a synthetic full by referencing existing data blocks instead of copying them. On XFS it relies on reflink, which the mkfs.xfs manual says is enabled by default and needs crc=1, also the default. A volume formatted earlier or with other options may lack it, so check xfs_info on the mount point for reflink=1 before the first backup.

A Veeam product manager explained in an R&D forums thread from January 2022 that active fulls do not use Fast Clone, and that chains copied in from another repository need an active full or a backup file compact operation first. Until then, synthetic fulls on a migrated chain are written in full.

Backup modes and job settings that immutability accepts

A locked file cannot be rewritten, so Veeam accepts only backup methods that never change a file after the run that wrote it: for backup jobs, forward incremental with periodic synthetic or active fulls. Forever forward incremental merges the oldest increment into the full once retention is reached, and reverse incremental rewrites the full on every run. A Veeam technical account manager’s Community Hub post (17 June 2026) quotes the wizard’s message for a forever forward incremental job: “Immutable backups feature requires the usage of forward incremental backup mode with periodic fulls.” Schedule periodic synthetic fulls, which cost little space on XFS with Fast Clone, or active fulls in the job’s advanced settings. The same post says reverse incremental can no longer be configured in version 13.

Backup copy jobs run forever forward incremental by default and, aimed at a hardened repository without GFS, report “Immutable backups feature requires the GFS retention policy enabled in the Backup Copy job settings.” Since version 11, GFS switches a copy job to forward incremental with synthetic fulls, and a Veeam product manager confirmed on the R&D forums that weekly GFS is enough. Version 13.1 also lets the backup server’s configuration backup be locked on a hardened repository, so an attacker who takes over the backup server cannot delete the backup you would rebuild it from.

Mistakes that weaken a hardened repository

The lock is the Linux immutable attribute, and the chattr manual says who controls it: “Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.”

Veeam Help Center 13.1 user guide and What’s New in 13.1; Veeam Security and Backup & Replication best practice guides; Veeam hardware guide (updated 25 February 2026); chattr(1) and mkfs.xfs(8) manuals.

One repository is still one failure domain, so keep a second copy elsewhere, as the 3-2-1-1-0 backup rule describes, and run the console’s Security & Compliance Analyzer after the build.

Our security and backup assessment reviews infrastructure, access and backups, and ends with a risk map and a prioritised action plan. Describe how your repository is built and who can reach it in the form below.

What someone at the console or the BMC can still do

The immutable attribute is a logical control inside the operating system, and Veeam’s security guide calls an immutable file system “useless” if the system “can be wiped at a lower level”. At the keyboard, someone can boot into single-user mode for a root shell, which is why the guide suggests a GRUB password, or start another operating system from external media and reformat the disks. A BMC remote console with virtual media does the same from anywhere on its network.

The hardware guide uses the BMC for disk and RAID status and for email alerts about failed disks, but it also allows the BMC port to be unplugged, with the alerts then sent by software on the operating system; on the appliance, check which alerts it can send before you unplug the BMC. As “a compromise”, the guide suggests a firewall in front of the BMC port that lets only outgoing traffic through. It adds that MFA on the BMC should be used but does not protect against the security issues such interfaces have had. The security guide also suggests locking the rack. The appliance’s security officer account (veeamso) is, in Veeam’s words, “an additional security layer to protect your infrastructure against malicious system administration”.

Network segmentation, multi-factor authentication and privileged access management are part of our cyber resilience service. Tell us where your BMCs and backup servers sit on the network and who holds their administrator accounts.

Sizing the disk for the immutability window

A locked restore point stays on disk even after retention would remove it, and Veeam deletes a forward incremental chain only when its last increment no longer meets retention. With daily runs and weekly fulls, the oldest full therefore stays for at least the immutability period plus the six daily increments that follow it.

As an illustration, assume a 10 TB full backup file, 0.5 TB of increments a day, weekly synthetic fulls with Fast Clone and 14 days of retention. Fast Clone lets the fulls share blocks, so the disk holds roughly one full plus the increments of about 20 days: 10 TB + 20 × 0.5 TB = 20 TB. A 30-day immutability period keeps about 36 days on disk, roughly 28 TB or 40 per cent more. With Veeam’s advice not to fill a volume above 80 per cent, the volume then needs about 35 TB. If the job runs weekly active fulls instead, every chain carries a full of its own, so each extra week of lock keeps one more full and its increments on disk, about 13 TB in this example. GFS points add their own share, which our backup retention guide works through.

What we do

Under our cyber resilience service, the team of our engineering partner Vixen.UNO delivers Veeam-based backup under one contract with Eurokommerz, with regular test restores to verify backup integrity and a recovery site in Baltneta’s Tier-3 data centres in Lithuania; target RPO and RTO are fixed in the SLA. The security and backup assessment, which also covers environments we did not build, ends with a risk map and a prioritised action plan; its price is fixed before work begins. Changes are rolled out step by step, in agreed maintenance windows with a rollback plan.

FAQ