How Veeam Works: Proxies, Repositories and the Hardened Repository

Short answer: Veeam splits the work three ways: a backup server that decides what happens, proxies that move the data, and repositories that store it. The most security-critical component is the Hardened Repository, a Linux store where backup files are marked immutable with a kernel-level chattr flag, so not even root can delete them until the period expires. Whether that design works comes down to one number: the immutability period must be longer than the time an attacker spends inside your environment.

The three roles

The backup server. The control layer. It holds the configuration database, schedules jobs and coordinates everything else. It is also the most valuable target in your environment, which is why the hardened repository is designed to stay safe even if this server is compromised.

The proxy. The data mover. It reads from the source, then compresses, deduplicates and encrypts the data on its way to the repository. Throughput problems are usually proxy sizing problems.

The repository. Where backup files land. It can be a Windows or Linux server, a deduplicating appliance, or object storage. That choice determines both your security level and your cost per terabyte.

Why the hardened repository matters

Ransomware groups delete backups before encrypting production, because a victim with a working backup does not pay. Mandiant's M-Trends 2026 report gives that trend a name: ransomware operators are shifting from data theft to recovery denial. The goal now is to make recovery impossible.

Veeam's answer is to enforce protection below the application layer. In a hardened repository, immutability comes from the Linux kernel itself, through the chattr flag. For the defined period, files cannot be moved, changed or deleted, only copied. Just as importantly, the credentials used to set up the repository are not stored in the backup infrastructure, so an attacker who takes over the backup server still cannot authenticate to the store.

Set the immutability period by the numbers

In the same M-Trends report, global median dwell time is 14 days, three days worse than the year before. The breakdown matters more:

When the organization detects the attack itself: 10 daysWhen the attacker announces it, meaning the ransom note arrives: 5 daysWhen an external party notifies the victim: 26 days

A seven-day immutability window falls short of the 14-day median. It protects backups taken while the attacker was already inside, but the ones that would take you back to before the intrusion have already aged out of it. When the tip-off comes from outside, the figure rises to 26 days, which is why a 30-day window is a common floor.

That choice directly drives capacity cost, which makes it a budget decision: shortening the window looks like a storage saving but actually cuts your odds of recovering.

Storage efficiency worth configuring

Format the repository disk with XFS and enable block cloning (reflink). With block cloning, synthetic full backups are built by referencing existing blocks rather than physically copying data. That sharply reduces both disk I/O and the space consumed. Veeam's hardened repository guidance names XFS as the recommended filesystem for this reason. Skipping this step is one of the most common ways teams pay for storage they do not need.

The 3-2-1 rule still holds

Three copies of the data, on two different media types, one copy offsite. Veeam extended it to 3-2-1-1-0: one copy immutable or offline, and zero errors after a verified restore test.

The part most organizations skip is that final zero. A backup job reported as successful is not proof of recoverability. Only a completed restore is proof; we gave the numbers behind that distinction in our article on the recovery gap.

Mistakes new operators make

No immutability, or a window shorter than median dwell time. The 14-day figure above is the reference for that decision.Never testing a restore. Verified recovery is the only meaningful measure; we set out the method in the disaster recovery failover test guide.The backup server and repository sharing a trust boundary, which lets a single compromise reach both.Undersized proxies, which push the backup window into production hours.

Frequently asked questions

Can an administrator delete an immutable backup? Not during the immutability period. The Linux kernel does not permit it, root included.

Is object storage a good repository? For retention tiers, yes, provided you watch proxy sizing and concurrent API request limits.

Does Veeam protect physical servers? Yes, along with cloud, SaaS and database workloads. That is a coverage advantage over tools that only replicate.

What is the difference between a backup and a replica? A backup is an independent copy you restore from. A replica is a standby copy you fail over to. Serious environments keep both; we worked through the split in our Zerto and Veeam comparison.

Sources

Veeam Hardened Linux Repository Best PracticesMandiant M-Trends 2026: dwell time and the recovery denial trendHow we build this layer: backup and data protection