Deep Dive: Veeam Hardened Repository vs Linux Repository vs Veeam Infrastructure Appliance in v13.1 (English)

Secure backups have always been important. But over the last few years, the requirements have shifted from “Yes, we should have backups — and ideally a second backup copy in another location and on another medium” to “Hopefully the backup still exists, is reachable, and really cannot be deleted.”

Ransomware, compromised admin accounts, supply-chain attacks, and targeted attacks against backup infrastructures have made one thing very clear: a backup is only truly useful if, in the worst-case scenario, it is reliably available, usable, and uncompromised.

Terms like WORM, immutability, Hardened Repository, Linux Repository, Veeam Infrastructure Appliance, single-use credentials, certificate-based authentication, Governance Mode, Single Disk, and Multi-Disk installation appear very quickly. But what is actually behind these terms, and what do I need for my use case?

With Veeam Backup & Replication 13.1, the topic and the available options have been significantly improved and expanded. But honestly, that has not necessarily made things easier — at least not if you have not looked into the topic in detail.

Veeam has always offered multiple ways to reach the goal. For backup repositories, this means that even before v13.1, you could choose between Linux-based repositories, Windows-based repositories, Hardened Repositories, Infrastructure Appliances, and storage or cloud solutions.

Depending on the design and configuration, the server-based repository options in Veeam Backup & Replication v13.1 support local disks, SAN LUNs — iSCSI, FC, NVMe-oF — or classic NFS mounts. However, these variants are not identical in detail, because depending on the selected option, there are significant dependencies regarding immutability, hardening, backup source, and storage target.

In short:

There are many options and many correct answers.
Unfortunately, there are also a few things that only look correct at first glance.

It becomes especially confusing when people use terms in conversations such as “Government Mode”, “Governance Mode”, “Governance retention”, or “GM Mode”. But when you look into the ISO menus or the official wizards, you do not necessarily find these exact terms there. At the same time, the Veeam Infrastructure Appliance introduces different “products” and “appliance roles” that are easily mixed up in day-to-day discussions.

And that is exactly why I took the time to write this article.

1. What is a Linux Server Repository?

A Linux Server Repository is a Linux server installed by the customer. For supportability reasons, it must be installed and configured with an operating system supported by Veeam.

See:
System Requirements for Backup Repository
https://helpcenter.veeam.com/docs/vbr/userguide/system_requirements_backup_repo.html?ver=13

The Linux server is then added as a managed server. During this process, Veeam services are deployed to the server. After that, the server can be used as a repository, while the customer remains responsible for maintaining the OS and applying patches.

The server can use different storage types to store backup data, including:

• local disks
• directly attached storage solutions
• mounted NFS paths
• SAN storage such as iSCSI, FC, or NVMe-oF

Veeam installs several services on the Linux server, including Data Mover components and the Veeam Installation Service. If immutability is configured, additional immutability-related components are added.

An important point here is that there are differences in how immutability can be configured. Veeam recommends setting this up as a Hardened Repository with certificate-based authentication or single-use credentials. However, it is also technically possible to run it in a more classic way using standard, persistent root accounts.

When immutability is enabled on a Linux Repository, it is based on Governance retention mode. This means that Veeam protects the backup files for the defined period using Linux file attributes. However, a user with sufficient local root permissions on the repository system remains a critical risk factor, because such a user can, in principle, bypass these protection mechanisms. This is also the main reason why a hardened implementation is recommended: the goal is to isolate and protect the root account as much as possible. Actually this is generally the core difference: the security philosophy. With a dedicated Veeam Hardened Repository, access and roles are deliberately reduced, and the root account is strongly isolated.

If you want to use Fast Clone on the repository — which can save a significant amount of storage space and is nowadays practically the common standard — the Linux Repository server must support XFS as the file system.

On Windows servers, a similar space-saving technology is available by using ReFS. However, Windows repositories do not provide an immutability function, neither in Governance nor in Compliance mode.

2. What is a Veeam Hardened Repository?

A Veeam Hardened Repository is a Linux-based repository model designed, supported, and maintained for secure backup storage. Veeam takes significantly more control over the underlying OS image, configuration, and security model, especially when deployed through the Veeam Infrastructure Appliance model.

The goal is to create a standardized and reduced system that is not misused as a general-purpose Linux server. Instead, it is specifically intended for ransomware resilience and for protecting backup data against manipulation or accidental deletion.

The central idea is simple: Backup data should not only be stored — it should remain immutable for a defined period of time. Even if an attacker gains access to parts of the backup infrastructure, restore points on the repository should not simply be deletable or modifiable.

The main functions of a Hardened Repository are:

• secure storage of backup data
• protection against manipulation and deletion through immutability
• secure authentication
• no permanently stored SSH credentials on the backup server
• no persistently used root passwords
• reduced access to the repository system
• minimal attack surface
• protection against time-shift attacks
• use of Linux immutable attributes and extended attributes

There is an important difference in authentication between manually deployed Linux Hardened Repositories and the VIA-based Hardened Repository variant.

With a classic Linux Hardened Repository, single-use credentials can be used. These credentials are used only once to install the required Veeam components on the Linux server. After that, they are not permanently stored on the Veeam Backup Server.

With a Hardened Repository based on the Veeam Infrastructure Appliance, the focus is instead on certificate-based authentication. The Veeam Backup Server no longer communicates with the Hardened Repository via SSH, but through certificates. For this, a SHA256RSA self-signed certificate with a 2048-bit RSA key is used.

This reduces the risk that a compromised backup server can simply read stored Linux credentials and use them against the repository.

From a storage perspective, it is important to understand that a Hardened Repository cannot simply use “any mount” as a target. In order for Veeam to technically enforce immutability, the file system must support Linux immutable attributes and extended attributes. Veeam uses mechanisms such as chattr and extended attributes for this. Therefore, only local disks and, starting with v13.1, SAN LUNs are supported for this scenario.

A Hardened Repository is intentionally designed to minimize the attack surface. The Veeam Backup Server does not store persistent SSH or root credentials for repository access. In classic Linux Hardened Repository deployments, single-use credentials are used only during the initial setup and are not retained afterwards. In the VIA-based Hardened Repository model, repository communication relies on certificate-based authentication instead of SSH. This means that even if an attacker compromises the VBR server, they cannot simply extract stored Linux credentials and use them to log in as root on the repository. Immutability itself is enforced by the Veeam Immutability Service, which applies and removes the required Linux immutable attributes in a controlled way. Root, of course, still exists as a Linux concept, but the security model prevents root access from being exposed through Veeam infrastructure or stored credentials. As a result, removing immutable flags through that attack path is effectively prevented.

3. What is the Veeam Infrastructure Appliance?

The Veeam Infrastructure Appliance, or VIA for short, is a Linux-based appliance provided by Veeam. It is based on a JeOS, meaning “Just Enough Operating System.”

The underlying operating system is Rocky Linux von CIQ, RLC Pro with long-term support and FIPS 140-3 validated packages.

The VIA is not a generic Linux server on which arbitrary software could be installed. It is a controlled appliance model specifically designed for Veeam infrastructure roles.

A VIA deployment can take on several roles, including:

• Backup Proxy (General-Purpose, VMware, CDP)
• Cache Repository
• Backup Repository (Linux, Hardened, NFS Share)
• SOBR Extent
• Guest Interaction Proxy
• Gateway Server
• Mount Server
• WAN Accelerator
• Log Shipping Server

The following roles are not supported, among others:

• Tape Server
• Off-host Backup Proxy
• NDMP Server

Source:
https://helpcenter.veeam.com/docs/vbr/userguide/linux_infrastructure_appliance_byb.html?ver=13

When deploying the VIA image, there are two important variants:

• Multi-Disk
  This is the default mode. In this mode, the server uses all available local disks to create separate system and data volume groups.
  Use Case Backup Repository and optionally additional roles such as Proxy
• Single Disk
  New with v13.1. In this mode, only one disk is used. Important: if the server sees additional disks, they will still be wiped. Also, local disk space cannot be extended or expanded later by adding more local disks. Only SAN LUNs can be added.
  Use Case e.g Proxy/Mount/Gateway-Server only, so without Repository function

Another setting in the VIA wizard is the appliance role.

• Infrastructure Server
  Similar to what was already available in v13.0, but you can now additionally add SAN LUNs as repository storage.
• Infrastructure Server with iSCSI/FC/NVMe-oF
  New with v13.1 you can now also use the server as a proxy for VMware backup from storage snapshots, meaning with Direct Storage Access.
• Hardened Repository
  Similar to v13.0, but you can now additionally add SAN LUNs as repository storage.

4. Proxy and Repository on the Same Server?

With a normal Linux Server Repository, it has always been possible to combine multiple roles. For example Repository and Proxy. This is not possible in the same way with a Hardened Repository. With v13.1, the Hardened Repository can now also provide VMware Backup Proxy functionality, but this is limited to Network Mode transport. The new VIA functionality with iSCSI/FC/NVMe-oF is significantly more flexible for these combined proxy scenarios. However, it does not follow the same security model as a dedicated Hardened Repository, because additional roles, services, and communication paths increase the attack surface.

5. Use-Case Recommendations

Okay, okay, okay — you get the idea. But what are the actual use cases for some commonly requested scenarios, and what should you choose?

Case 1: Maximum Security for the Primary Backup Copy

Veeam Infrastructure Appliance as Hardened Repository, Multi-Disk deployment, physical server, local disks.

Why?

• certificate-based authentication
• no stored Linux credentials
• no SSH for repository access
• reduced OS footprint
• no third-party software
• immutability
• time-shift detection
• XFS / Fast Clone

Suitable for:

• ransomware-resilient backup architecture
• 3-2-1-1-0 design
• customers with a strong security focus
• environments where the repository should be as isolated as possible

Case 2: I Want VMware Backup with Direct Storage Access

VIA Infrastructure Server with iSCSI/FC/NVMe-oF as Proxy and a separate Hardened Repository as the target.

Why?

• the Proxy role needs access to the production SAN
• the Repository should remain as isolated as possible
• role separation reduces risk

Case 3: Like Case 2, But I Want Only One System

VIA Infrastructure Server with iSCSI/FC/NVMe-oF as Proxy and Backup Repository with immutability.

Why?

• only one physical system required
• hardware savings
• full Direct Storage support
• immutability can be used
• good compromise for smaller environments or budget/space restrictions

But: The system is not as strongly isolated as a separate Hardened Repository, because the Proxy and Repository roles are combined and the server has access to the production SAN.

6. Advantages and Disadvantages

Linux Server Repository

Advantages

• very flexible
  You can install and customize almost anything you want.
• supports local disks, NFS, iSCSI, and FC
• can combine multiple roles
• suitable for existing Linux standards
• easier to integrate into existing operational processes
• immutability can be enabled

Disadvantages

• operational responsibility remains with the customer
• credential and SSH hardening must be implemented properly
• larger attack surface if multiple roles are combined
• root access remains a critical point
• not automatically as strongly isolated as a VIA Hardened Repository

Hardened Repository on Manually Deployed Linux

Advantages

• strong immutability
• single-use credentials
• no stored SSH credentials in VBR
• block storage, XFS, and Fast Clone are possible
• very good protection against manipulation from the VBR side

Disadvantages

• Linux hardening remains the customer’s responsibility
• OS lifecycle, patching, monitoring, and compliance remain with the operator
• no NFS/SMB as storage
• limited role combination
• Direct SAN proxy scenarios require a separate system

Veeam Infrastructure Appliance as Hardened Repository

Advantages

• Veeam-provided JeOS
• Veeam-managed appliance model
• supports SAN extensions
• reduced attack surface
• certificate-based authentication
• no SSH for repository connectivity
• MFA and Security Officer concept
• DISA/FIPS-oriented policies
• ideal for dedicated immutable backup targets

Disadvantages

• less flexible than self-managed Linux
• no third-party software
• capacity planning must be done carefully before deployment
• roles and storage expansion are more strictly predefined

VIA Infrastructure Server with iSCSI/FC/NVMe-oF

Advantages

• ideal as a VMware Proxy for backup from storage snapshots
• supports Direct SAN Access via iSCSI/FC/NVMe-oF
• Veeam-managed appliance model
• separation between Proxy and Repository role is possible

Disadvantages

• not exactly the same as a Hardened Repository
• for maximum immutability, the Repository role should be separated

7. Decision Matrix

You all know the situation: a decision has to be made, and it feels like you only have seconds. So here is my best choice per requirement — without going into all the details.

8. Detailed Overview in One Graphic

I tried to take the essence of the text and put it into a table without leaving out anything important. Here is the graphic. If you click on it, you can view it in full size.
 

https://andreasbuhlmann.wordpress.com/wp-content/uploads/2026/08/overview_via.png

 

Important Sources for Further Reading

VIA (Veeam Infrastructure Appliances)
Configuring – https://helpcenter.veeam.com/docs/vbr/userguide/hmc.html?ver=13
Deploying – https://helpcenter.veeam.com/docs/vbr/userguide/linux_infrastructure.html?ver=13

Hardened Repository
v13.1 Documentation: https://helpcenter.veeam.com/docs/vbr/userguide/hardened_repository.html?ver=13
Host Management (Same as Via): https://helpcenter.veeam.com/docs/vbr/userguide/hmc_about.html?ver=13

Linux Backup Repository Server:
Dokumentation v13.1 https://helpcenter.veeam.com/docs/vbr/userguide/linux_server.html?ver=13