Deploying the Veeam Hardened Repository Appliance: A Complete Step-by-Step Guide
Deploying the Veeam Hardened Repository Appliance: A Complete Step-by-Step Guide
If you've already read our Infrastructure Appliance proxy deployment guide, this will feel familiar — the wizard flow is almost identical. But deploying the Veeam Hardened Repository (VHR) has a few meaningful differences that matter for immutable storage, and this guide covers all of them. Same JeOS ISO, different GRUB selection, different outcome.
What Is the Veeam Hardened Repository?
The Veeam Hardened Repository (VHR) is an immutable backup storage target built on the same JeOS appliance framework as the Infrastructure Appliance proxy. When you write backup data to a VHR, Veeam stamps each file with a WORM (Write-Once-Read-Many) immutability flag in the XFS filesystem metadata. For the duration of the configured retention period, that data cannot be modified, encrypted, or deleted — by anyone, including a compromised backup administrator account or a fully compromised Backup & Replication management server.
This is the architectural guarantee that makes the VHR the cornerstone of ransomware-resilient backup design. The protection lives at the filesystem level, independent of Veeam software. Even if the entire management plane is taken out, the data on a properly deployed VHR remains intact and recoverable.
The appliance model makes this significantly easier to deploy correctly than the old manual Linux hardening approach. A manual hardened repository setup had many failure points — active root accounts, misconfigured PAM, exposed SSH ports. The JeOS appliance eliminates all of that by design, delivering DISA STIG compliance and immutability out of the box.
All screenshots in this guide were captured from a live deployment on March 5, 2026. The Hardened Repository appliance was deployed with static IP 192.168.1.12, hostname vlhr-8be94d3b, and registered into the same VBR v13 instance used in the proxy guide.
How This Deployment Differs from the Proxy Guide
If you're coming from the proxy deployment guide, here's a quick reference for what changes. Everything else is identical.
| Step | Infrastructure Appliance (Proxy) | Hardened Repository |
|---|---|---|
| GRUB selection | Veeam Infrastructure Appliance | Veeam Hardened Repository |
| Install mode options | Install, Reinstall | Install, Upgrade, Reinstall NEW |
| Rocky Linux installer title | …PROXY HOST 13.0.1.1071 INSTALLATION | …HARDENED REPOSITORY 13.0.1.1071 INSTALLATION |
| Default hostname prefix | vprx-xxxxxxxx | vlhr-xxxxxxxx |
| Wizard finish progress | [7/12] Restarting veeamdeployment | [8/11] Restarting veeam-updater |
| Post-wizard TUI | Single thumbprint shown | Two thumbprints: Host Management Console + Application IMPORTANT |
| VBR pairing cert | Standard TLS cert | Must match the Application thumbprint (not the Host Management one) |
| Data disk format | Standard (ext4) | XFS with Fast Clone + WORM immutability daemons |
| Web UI on port 10443 | Enabled by default | May be disabled by default — requires physical console to enable |
The two-certificate thumbprint distinction is the one most likely to catch people off guard, so we'll cover it in detail in the post-wizard section.
Booting the JeOS ISO
Use the same Veeam JeOS ISO used for the proxy deployment — it's a single ISO that contains all appliance types. The difference is purely which GRUB option you select at boot.
Selecting Hardened Repository at the GRUB Menu
The GRUB selection determines how the OS installer partitions and formats the data disks. Choosing "Veeam Infrastructure Appliance" here instead will give you a standard proxy node — the XFS filesystem and immutability daemons won't be present, and you won't be able to configure it as a Hardened Repository in VBR. Select the right option before pressing Enter.
Install, Upgrade, or Reinstall
The Hardened Repository install mode screen offers three options — one more than the standard Infrastructure Appliance:
Here's when to use each:
- Install — Full destructive wipe. Use this for all new deployments. This is what we're doing in this guide.
- Upgrade — In-place upgrade of the Hardened Repository OS to a newer version, keeping existing backup data and settings intact. Use this when a new JeOS ISO is released and you want to upgrade an existing VHR node without losing your backup chains.
- Reinstall — Wipes the OS partition only, preserving the backup data partition. Use this only when the OS has failed catastrophically but the stored backup data on the data disk is still intact.
Select Install for a new deployment and confirm the disk wipe:
Automated OS Installation
The installer runs hands-off. You'll see the system boot into its first normal startup sequence once the installation completes — this looks different from the proxy guide because you're seeing the new system coming up rather than the installer pivoting:
When installation completes, the server reboots directly into the configuration wizard at the terminal.
The Configuration Wizard
The wizard is structurally identical to the proxy deployment — same six steps, same TUI navigation. The screenshots here are from the Hardened Repository deployment so the specifics (hostname, IP, MAC) reflect this node.
- Step 1
Accept the license agreement
- Step 2
Set the hostname — generates TLS certificates, cannot be changed post-deployment
- Step 3
Configure network — static IP strongly recommended
- Step 4
Set time zone and NTP servers — required for TOTP MFA
- Step 5
Create the Host Administrator account and enroll TOTP MFA
- Step 6
Configure the Security Officer — one-time opportunity, cannot be added later
Step 1 — License Agreement
Step 2 — Hostname
Same rule as the proxy: the hostname is ingested immediately by OpenSSL to generate the TLS certificates for the Host Management Console and VBR pairing. Changing it after deployment breaks all connectivity. Set a permanent name now — something like vhr-01.yourdomain.local is cleaner than the randomized default.
Step 3 — Network Configuration
Select [Static] and enter the IPv4 address, subnet mask, gateway, and DNS. DHCP technically works but is not appropriate for a repository node — the VBR pairing and TLS certificates are tied to the IP.
Step 4 — NTP and Time Zone
The MFA enrollment in the next step generates TOTP codes that depend on time synchronization between the appliance and the admin's authenticator app. If the clock is wrong, enrollment will fail with mismatched tokens. Configure reliable NTP servers here and click [Sync] to confirm it's working before proceeding.
Step 5 — Host Administrator Account and MFA Enrollment
The same DISA STIG PAM requirements apply as on the proxy node:
- Must meet the DISA STIG minimum length requirement (see Veeam KB4740)
- Must include at least one uppercase letter, one lowercase letter, one number, and one special character
- Must not contain more than four consecutive characters from the same character class
- Must be completely distinct from the Security Officer password
Once the password is accepted, TOTP MFA enrollment is immediately mandatory. Scan the QR code or enter the seed key into your authenticator app and confirm the 6-digit token. The system also generates a hexadecimal emergency recovery token at this point — write it down and store it offline in a secured location.
Step 6 — Security Officer Account
Skipping the Security Officer permanently disables four-eyes authorization for the lifetime of this appliance, and the only fix is a full wipe and reinstall. On a Hardened Repository this matters even more than on a proxy — the SO is the last line of defense against an attacker who has compromised the veeamadmin account trying to disable immutability protections or enable SSH to exfiltrate data. The wizard screen itself tells you this role belongs to someone from the information security team, not the backup admin. Take that guidance seriously.
As with the proxy, the Security Officer's MFA enrollment does not happen here. The password created in this step is a bootstrap credential only. On their first login to https://<VHR-IP>:10443, the SO will be required to change it and complete their own TOTP enrollment before they can access anything.
Step 7 — Summary and Commit
Press [Finish] to commit. The wizard applies all settings and restarts the necessary services:
When it finishes, the appliance is operational. But before jumping to VBR, check the post-wizard TUI screen — it shows something the proxy deployment didn't.
The Post-Wizard TUI — Two Certificate Thumbprints
After the wizard completes and you return to the main TUI screen, the Hardened Repository displays more information than the proxy does. This is worth reading carefully before you go to VBR.
The TUI displays two distinct thumbprints:
When you add this node to VBR using the "Veeam Infrastructure Appliance" wizard, the certificate fingerprint VBR shows you in the Validation dialog is the Application thumbprint — not the Host Management Console thumbprint. In this deployment that's B247AE7487…769B4F3. Write down the Application thumbprint from the TUI before going to VBR so you can verify it matches. This is how you confirm you're connecting to the right machine.
Adding the Appliance to Veeam Backup & Replication
Open the VBR web console, go to Infrastructure → Managed Servers, and click + Add Server.
After clicking Next, VBR contacts the appliance and presents the certificate fingerprint for verification:
The fingerprint VBR shows here (B247AE7487…769B4F3) corresponds to the "Application thumbprint" on the TUI — not the "Host management console" thumbprint (1E4EA405FD…056332). If you wrote down the wrong one from the TUI, they won't match and you'll wonder if something is wrong. It's fine — just go back to the TUI and confirm the Application thumbprint.
After accepting the certificate, VBR will proceed through the Review and Summary steps (same as the proxy workflow) and install the required components. The Hardened Repository node will appear in Managed Servers as Online once complete.
Adding the node to Managed Servers is only half the job. To actually use it for backups, you then need to navigate to Infrastructure → Repositories and add it as a Linux Hardened Repository, pointing to the XFS-formatted data partition. That step is outside the scope of this deployment guide but is covered in Veeam's documentation.
✅ Deployment Complete
- Hardened Repository appliance deployed on Rocky Linux JeOS 13.0.1.1071
- XFS data disk formatting and WORM immutability daemons configured at install time
- DISA STIG-compliant password policy and TOTP MFA enforced for both accounts
- Security Officer (veeamso) configured for Zero Trust four-eyes authorization
- Two certificate thumbprints generated — Application thumbprint confirmed in VBR pairing
- Appliance registered to VBR via certificate-based authentication — no SSH required
Key Takeaways Specific to Hardened Repository
XFS formatting, Fast Clone support, and the WORM immutability daemons are all configured during OS installation based on your GRUB selection. VBR doesn't add these capabilities later. If you accidentally boot with "Veeam Infrastructure Appliance" instead of "Veeam Hardened Repository," the resulting node will function as a proxy but won't have the immutability infrastructure in place. There's no fixing it without a reinstall.
When a new JeOS ISO is released, you can boot the existing VHR node from the new ISO and select "Upgrade" to perform an in-place OS upgrade while preserving both backup data and existing settings. This doesn't exist on the standard Infrastructure Appliance — proxies are stateless enough that a reinstall is acceptable, but a Hardened Repository may contain irreplaceable backup chains that make a wipe unacceptable.
The post-wizard TUI shows two thumbprints. The one VBR will ask you to verify during pairing is the Application thumbprint — not the Host Management Console thumbprint. Note it down before you go to VBR. It's easy to write down the wrong one and then wonder why the fingerprints don't match.
Hardened Repository nodes may have the Web UI service on port 10443 disabled as a default security measure — the idea being that a repository node should be as dark as possible on the network. If you can't reach the Web UI, you'll need physical console access to temporarily enable it, do what you need to do, and then disable it again. This is by design, not a misconfiguration.
The wizard screen itself tells you: "This role is usually assigned to a member of an Information Security team." On a proxy node, skipping the SO is a security gap. On a Hardened Repository, it's a serious one — the SO is the only independent check against an attacker who has compromised veeamadmin and wants to enable SSH, disable immutability monitoring, or wipe the partitions. The whole point of four-eyes authorization is that a single compromised account can't do catastrophic damage unilaterally.
This guide covers deployment and VBR registration. To actually receive backup data, you still need to add the node as a Backup Repository in VBR under Infrastructure → Repositories → Add Repository → Linux Hardened Repository, pointing to the XFS-formatted data partition. The deployment here just gets the node registered and trusted by VBR — the repository configuration is a separate step.