Home  ›  Glossary  ›  Veeam Hardened Repository

What is a Veeam Hardened Repository?

Veeam Hardened Repository is a Veeam backup repository on a Linux server with local or block storage, where the operating system marks each backup file immutable for a set number of days. While the mark is in place, the Veeam server that wrote the file cannot change or delete it. The Veeam server connects with single-use credentials, so no reusable login for the repository is stored in the backup infrastructure.

The Linux immutable flag on Veeam backup files

The design targets a specific weakness of the classic Windows repository joined to the domain, where anyone controlling the domain or the Veeam server can simply delete backup files. On the Linux host, one Veeam service receives data from the proxies, and a second, running as root, sets the file system's immutable attribute on each backup file and clears it when the period ends.

The period is configured on the repository, from 7 days upward, and counts from the newest restore point in a chain. A full backup and its increments therefore stay locked together until the last of them ages out, and the oldest file in a chain is held well past its own age.

Backup methods, disks and clocks it accepts

  • Forward incremental chains. Locked files cannot be merged, so jobs run forward incremental with periodic active or synthetic fulls. Forever forward and reverse incremental are excluded.
  • Block storage with XFS. Disks are local or block-attached and formatted with a file system that supports the immutable attribute. Veeam recommends XFS, whose block cloning keeps synthetic fulls fast and small. NFS and SMB shares are excluded.
  • A trustworthy clock. Lock expiry follows server time, so Veeam watches for large jumps and freezes retention operations when the time moves suspiciously.
  • Unlocked metadata. Small chain metadata files are rewritten on every run and never carry the flag.

Root access as the remaining key

The flag stops Veeam and ordinary users. The root account on the Linux host can remove it, which is why Veeam's own security guidance counts physical and console access to the server as part of the threat. Console access includes the hypervisor console when the repository is a VM and the out-of-band management port when it is a physical box.

Veeam's Linux-based appliance image narrows the path to root, with SSH unavailable, no domain membership, certificate-based authentication and enforced multi-factor authentication. The principle stays the same: whoever controls root, or the clock, controls the lock.

One more Linux server for a small team to own

How well the lock holds comes down to how isolated one server is. A host nobody logs in to day to day, with SSH off, a root password shared with no other system and its management port on a separate network, stands up well to a stolen domain or Veeam account. A host built in a hurry, with SSH left open for troubleshooting and the same root password as every other Linux machine, protects far less than the word hardened implies.

Someone also patches it, swaps failed disks and keeps it physically away from the people who run production. Capacity ends at the chassis, and growth means more servers added as extents in a scale-out backup repository, each another host to harden.

Veeam supports pairing a Hardened Repository for fast local restores with an S3 bucket holding a second immutable copy, so that the two locks rest on different controls.

ARTESCA and Veeam Hardened Repository

ARTESCA enforces immutability at the S3 API with S3 Object Lock, so no file attribute or Linux root account controls the lock. In compliance mode no user, the account root included, can shorten retention before the retain-until date, while governance mode leaves a bypass open, as set out in Veeam immutable backup.

An ARTESCA bucket can sit in the same scale-out backup repository as a Hardened Repository, for instance as the capacity tier behind it, and Object Lock is among the features Scality has validated with Veeam Backup & Replication. ARTESCA scales to a validated 8.5 PB, so that tier grows without a new chassis per extent.