The Veeam Linux hardened repository

A hardened repository is a Linux server that makes backup files immutable for a set period and keeps no usable credentials on the backup server. It is the main on-premises defence against an attacker who has taken over the backup server.

It offers immutability: for the configured period, files cannot be moved, modified or deleted, although they can be copied. It also offers secure authentication. Certificate-based authentication needs no user name or password and is available on Veeam Infrastructure Appliance deployments. Single-use credentials are used once to deploy the Data Mover and never stored, so a compromised backup server cannot reuse them. No other role may run on it except a VMware backup proxy in Network (NBD) mode, and even that adds VDDK and its vulnerabilities, so Veeam recommends placing the proxy elsewhere. It can store VM, physical, cloud-copy, unstructured data, log and plug-in backups, plus VeeamZIP, Copy, Move and Export Backup output.

A hardened repository cannot be shared between backup servers, does not support symlinks in its path and is not shown in the Files view. An appliance hardened repository can also act as an Application Backup Repository, but the documentation warns this widens the attack surface on immutability.

Common trap: Planning to host a mount server, guest interaction proxy or WAN accelerator on the hardened repository - the only extra role allowed is a Network-mode VMware proxy, and even that is discouraged.

Backup methods and how the lock works

Use only forward incremental with active or synthetic full. Immutable files cannot be merged until they expire, so reverse incremental and forever forward incremental cannot be selected. In v13 reverse incremental is deprecated anyway; it still runs only for jobs that used it before the upgrade. VBM metadata files cannot be immutable (they change every run), so import from VBK files. A backup copy job aimed at a hardened repository needs GFS before immutability applies.

The Veeam Data Mover Service (veeamtransport, port 6162, non-root) receives the period from the backup server. The Veeam Immutability Service (veeamimmureposvc, a root child process) sets and removes the attribute and checks files every 20 minutes. Each backup file gets a .veeam.N.lock file and an extended attribute.

• The period is 7-9999 days, counted from the last restore point in the active chain, so the active chain is extended with each new point. Inactive chains are not extended.
• The flag is set only when a session completes. If a failed run is followed by a new full, those files stay mutable; set the flag with Set-VBRImmutabilityLockExpirationDate.
• Increasing the period applies to the active and later chains. Decreasing it never shortens locks already set.
• Immutability overrides job retention. A GFS full is locked for the longer of the repository period and its GFS lifetime, and its increments for the repository period.
• Log backups are locked once written and are not extended. The period must therefore cover the whole active chain, or application restore can fail.

Timeshift detection writes /etc/veeam/immureposvc/timeLog every 10 minutes. If the system or hardware clock shifts by more than 86,400 seconds (24 hours), or the repository is off for more than 24 hours, retention is blocked and the session shows a warning. On an appliance, clear it with Reset time shift protection in the Veeam Host Management console TUI; on a manual server, the fix needs root access. Set the hardware clock to UTC for accurate detection. The documentation states this design protects files even if the NTP server is compromised.

Common trap: Keeping a forever forward incremental job when retargeting it at a hardened repository - immutable files cannot be merged, so only forward incremental with scheduled fulls is allowed.

What changed since v12

In v12 many hardened repositories were built from the Veeam Hardened Repository ISO. In v13 they are upgraded in place with the Veeam Infrastructure Appliance ISO. Keep the same hostname and network settings, then switch the managed server to certificate-based authentication. Data stays, but paths move from /mnt/veeam-repository01/ to /var/lib/veeam/. In 13.1, with four-eyes authorisation enabled, reducing or disabling a hardened (or governance-mode) repository’s immutability needs a second approver. Configuration backups can also be stored immutably there (see Chapter 4: Securing the backup infrastructure). A plain Linux repository can be converted by re-adding the server under a different name or IP as a hardened repository and importing the backups. This is not possible for an Infrastructure Appliance repository, a mount server, or a server with packages such as NfsGateway or GuestInteractionProxy installed.

Get the whole book

This note is one section of Ultra Transcenders VBR-13: Veeam Backup & Replication 13, an independent study guide that explains every topic the course covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to the Veeam Help Center.

About the book · VBR-13 terms in the glossary · All VBR-13 study notes