If your Veeam repository is a Windows share, your ransomware recovery story ends the moment an attacker gets domain admin. The Linux hardened repository closes that gap — but only if it's configured correctly. Most implementations I have audited are not.

What the hardened repository actually protects against

Veeam's hardened repository runs on Linux, uses XFS with reflink support, and enforces immutability via file attributes. Once a backup block is written, no process can modify or delete it during the immutability window — not the Veeam service, not root, not even a compromised domain admin.

Warning

Immutability protects the file from deletion, not from being read. If an attacker has root on the hardened repository itself, they can read the data. That is why the repository must live in a segmented network with no inbound domain trust.

Prerequisites

  • Ubuntu 22.04 LTS or RHEL 9 (Veeam's supported list)
  • A dedicated physical server or VM with local disks only — no iSCSI, no NFS
  • A local, non-domain user for Veeam
  • The server in its own management VLAN with a hardened SSH config

Step 1 — Format the volume with XFS + reflink

code
# Create partition
sudo parted /dev/sdb --script mklabel gpt
sudo parted /dev/sdb --script mkpart primary xfs 0% 100%


# Format with XFS (reflink is on by default in xfsprogs 5.1+)
sudo mkfs.xfs -m reflink=1 /dev/sdb1

# Mount
sudo mkdir -p /mnt/veeam-repo
sudo mount /dev/sdb1 /mnt/veeam-repo

# Verify reflink is enabled:
sudo xfs_info /mnt/veeam-repo | grep reflink

# Expected: reflink=1

Step 2 — Enable the immutable attribute

This is the part most implementations get wrong. Simply having reflink is not immutability — you must set the immutable file attribute on the backup folder. (Bash)

code
# Set +i on the repository directory
sudo chattr +i /mnt/veeam-repo

# Verify
sudo lsattr -d /mnt/veeam-repo
# Expected: ----i---------e------- /mnt/veeam-repo
Trade-off · Fast clone vs. immutable folder
If you set +i on the parent folder, Veeam cannot create subfolders during backup jobs. The correct pattern is to let Veeam create the folder structure first, then set +i on the subfolder where backups will be written. Do this after the first full backup completes.

Step 3 — Configure Veeam

On the Veeam server, add the repository (Powershell):

code
Add-VBRBackupRepository `
  -Name "Hardened-Linux-XFS" `
  -Folder "/mnt/veeam-repo/backups" `
  -Type LinuxLocal `
  -MountServer "veeam-mount-01.contoso.local" `
  -MountServerCredentials (Get-Credential) `
  -UseNFS $false

Then in the job settings, set immutability:

Retention window: 21 days (survives typical 14-day attacker dwell time)

Immutable restore points: checked

Fast clone: enabled (requires reflink, which we already verified)

Step 4 — Test the immutability

Before you claim the repository is hardened, prove it:

code
# As Veeam admin, try to delete a restore point
sudo rm -rf /mnt/veeam-repo/backups/JobName/Backup_2026-05-20T*.vbm
# Expected: "Operation not permitted"

If the delete succeeds, your +i attribute was set on the wrong path. Fix it before declaring the repository hardened.

What this actually buys you

The hardened repository does not prevent the initial compromise. It does not prevent lateral movement. It prevents the specific step where attackers try to destroy your restore capability. Combined with segmented networking, separate credentials, and regular immutability tests, it converts your backup from "another target" to "a real recovery path".

Short version

Set XFS with reflink, apply chattr +i to the backup subfolder (not the parent), configure Veeam with 21-day immutability, and prove it with an rm test. That is the entire configuration.