Building a hardened Linux repository for Veeam immutable backups

An immutable backup is one that cannot be altered or deleted for a defined period, no matter who asks. That property is the difference between a ransomware incident and a ransomware catastrophe, because the modern attack pattern is not simply to encrypt production — it is to find the backup infrastructure first and destroy it, then encrypt production.

A Veeam hardened Linux repository addresses this directly. It is a Linux server that is not domain-joined, is reachable only through tightly controlled paths, and enforces immutability at the filesystem level using credentials that Veeam itself does not retain. This guide walks through building one on an HPE Apollo 4200 Gen10 running Ubuntu 22.04 LTS.

Configured correctly, immutable retention also supports record-keeping requirements such as SEC 17a-4(f), FINRA 4511(c), and the corresponding CFTC rules.

Why the platform choice matters

The single most important architectural point is this: a hardened repository must not be a member of the domain your attacker just compromised. An immutability flag on a Windows repository inside the production Active Directory still sits behind the same credentials the attacker now holds. A separate Linux host, with its own local accounts and single-use deployment credentials, removes that path entirely.

Everything else in this build is in service of that idea.

Hardware and network

The build used a physical HPE Apollo 4200 Gen10 (XL420 Gen10 node) configured with:

12 × 6 TB SAS hard drives for the backup volume
2 × 960 GB SATA SSDs for caching
2 × 10 GbE network connections, one to each of two redundant switches
1 × 1 GbE connection for iLO out-of-band management

The two 10 GbE links were bonded using balance-alb (adaptive load balancing). This mode was chosen deliberately: it provides both link redundancy and transmit/receive load balancing without requiring any configuration on the switch side, which matters when the two links land on independent switches that are not stacked.

Firmware and Secure Boot

Firmware was brought current using the HPE Service Pack for ProLiant (2022.03.0) before anything else was configured. Firmware remediation belongs at the start of a build, not after data is on the array.

Secure Boot was then enabled, so that only software or firmware signed with approved keys is permitted to execute. On a system whose entire purpose is to be the last line of defense, boot integrity is not optional.

Storage layout

The 12 hard drives were configured as a RAID 6 array, tolerating two simultaneous drive failures — the appropriate choice at this drive count and capacity, where rebuild times are long enough that a second failure during rebuild is a realistic scenario.

The two SSDs were configured as a RAID 1 pair and used for HPE SmartCache, providing read caching in front of the spinning disk array.

LVM was layered on top so that the backup volume can be extended later without rebuilding, which will matter the first time retention requirements change.

Filesystem: XFS with reflink

This is the step that most affects Veeam’s behavior:

mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/ubuntu-vg/backups-lv

The reflink=1 option enables copy-on-write block sharing, which is what Veeam’s Fast Clone relies on. With Fast Clone available, synthetic full backups are created by referencing existing blocks rather than copying them — dramatically reducing both the time and the capacity a synthetic full consumes. crc=1 enables metadata checksumming.

Building this filesystem without reflink is a mistake you will not notice until your synthetic fulls take all night and consume full-backup-sized capacity.

The volume was mounted at /mnt/backups with restrictive permissions (700).

Hardening the operating system

With the storage in place, the host itself was hardened:

Separate administrative and service accounts. A dedicated administrative user, entirely distinct from the account Veeam uses. These roles should never be the same identity.
SSH key authentication using Ed25519. Password authentication for administrative access is disabled.
Multi-factor authentication on SSH via Google Authenticator, so a stolen key alone is insufficient.
PermitRootLogin no. Root login over SSH is disabled outright.
Minimal service surface. SSH is the only network service running. A backup repository has no business also serving anything else.

Veeam configuration

Within Veeam Backup & Replication, the repository is added using single-use credentials for hardened repository. This is a specific and important option: Veeam does not store these credentials. They are used only to deploy the Veeam Data Mover to the server and are then discarded.

The repository was configured with:

A 7-day immutability window — adjust to your own retention and recovery requirements
Fast Clone enabled, which the XFS reflink configuration above makes available
The dedicated /mnt/backups path with 700 permissions

Going further

Depending on your threat model and operational tolerance, several additional steps are worth considering:

Disconnect iLO from the network entirely. Out-of-band management is a convenience and an attack surface. On a hardened repository, the trade may be worth making.
Disable SSH after the build is complete, re-enabling it only through physical or out-of-band access when maintenance is genuinely required.
Apply host-based firewall rules restricting inbound connections to the specific Veeam infrastructure hosts that need to reach the repository, and nothing else.

Each of these makes the system less convenient to administer. That is precisely the point — the value of a hardened repository comes from how few paths exist into it.

The part that actually matters

Building the repository is the easy half. The half that determines whether any of this works is testing a restore that assumes the production domain is gone. If your recovery procedure depends on authenticating against the Active Directory an attacker has just encrypted, the immutable backup will survive and you still will not recover.

Test the restore path from a position of assumed total compromise. Measure how long it takes. Write it down. Then do it again next year.