Configuring an Interface Bond for Veeam Software Appliance and Veeam JeOS Installations on Hyper-V

Introduction

If you are anything like me, you want your labs and testing to mimic production as much as possible. Hence, when testing the Veeam Software Appliance and Veeam JeOS ISO installations in my Hyper-V lab, I want to use bonding for my LAN NICs and, potentially, for my dedicated backup network NICs. I say potentially, as that depends on the backup source and the available backup target networks, as well as the required configuration and the workloads they serve. Such design discussions have numerous permutations, which would lead us astray from the goal of this blog post.

Once we have decided we want bonding, the question at hand quickly becomes How does one get a bond to work in Linux VMs on Hyper-V? I will demonstrate how to do it for this specific use case. My primary concern was that the hardening of the ISO image might have blocked this from working, but it does not! Which is excellent news.

Yes, I know that bonding inside VMs is not the best approach, but we are doing this to emulate physical production configurations. In real-life production workloads, you should NOT even use virtual machines for hardened (immutable) repositories!

We need multiple NICs

First of all, we need a VM with multiple NICs. Two NICs for the LAN bond and then two or four NICs, depending on your network setup and goals. As stated above, we will not discuss this here.

I will direct you to a PowerShell script that allows you to easily deploy one or more scaffolding virtual machines on Hyper-V for testing the Veeam JeOS (Hardened Repository) ISO. Adapt the variables to your needs and run the script with elevated permissions. Locally, remotely, whatever suits you best.

You can set up the Hyper-V part of the NIC configuration for teaming via a script or in the GUI. I will use the GUI to showcase this, but will also provide the PowerShell commands in the script.

Note

You might remember my earlier guide on NIC bonding for Ubuntu guests in Hyper-V. There, I relied on full access to tooling on my Ubuntu servers. When working with the Veeam Hardened Repository ISO, things are more locked down. Thankfully, the installer provides a basic yet effective GUI. You can use it to configure NIC bonding during the installation process. Not only that, but we also have a basic menu-driven GUI after installation to configure and change the essentials. There should not be a need to SSH into the repository servers.

Bonding

This post guides you through setting up interface bonding during the initial installation phase using the built-in GUI, and I will show you where to configure or change it post-installation.

Installing the Veeam appliance & configuring bonding

They designed VeeamJeOS and other appliances with security in mind. That’s great for production, but it means you don’t get the same level of access to system internals as you do with a full-blown Ubuntu install. Specifically:

  • You can’t easily view or manipulate MAC addresses.
  • The repository is a stripped-down OS, so tools like ip, ifconfig, or even netplan might not be available.
  • You’re working with a locked-down shell and a minimal set of packages.
  • SSH access is available with one-time use passwords, and you need to enable it explicitly.

So how do we configure NIC bonding under these constraints? Let me walk you through this.

Step-by-Step: Bonding Interfaces in the Hardened ISO

1. Prepare Your Hyper-V Environment

Before booting the ISO, ensure your Hyper-V setup is ready. We will create a VM with an OS disk of at least 100 GB and add one or more larger data disks to emulate volumes backed by one or more RAID controllers. Don’t worry too much about the size, the disks are dynamically expanding ones and thin-provisioned. Naturally, you’ll need some vCPUs and vMemory. Additionally, create a Generation 2 VM and ensure that you set the secure boot template to “Microsoft EUFI Certificate Authority”. Last but not least, set the boot order to boot from the DVD drive first.

Next is the most important for this blog post: creating the vNICs.

  • Create two LAN vNICs for your VM and two or more BACKUP vNICs.
  • Enable MAC spoofing on the vNICs that you will bond inside the guest OS. It is crucial, as without it, the bond does not work correctly.
  • You must check “Enable this network adapter to be part of a team in the guest OS.”

Lucky you, I have a scaffolding script to create such VMs for you, and you can find it here: https://github.com/WorkingHardInIT/CreateVeeamHardenedRepoScafoldingVMs

Change the variables to values that make sense in your lab and run it in an elevated PowerShell session.

Enjoy. The only thing you need to do after running that script is mount the ISO in the DVD drive. You can play along with the VeeamHardenedRepository_2.0.0.8_20250117.iso or the VeeamJEOS_13.0.0.12109.BETA2.iso. In this article, I am using the VeeamHardenedRepository_2.0.0.8_20250117, as it is the current version suitable for production use. But if you follow the instructions below, you will be able to complete the process on both. For the V13 Beta 2, you need to contact Veeam as it requires an access code to download. You can watch a video of me installing VeeamSoftwareAppliance_13.0.0.12109.BETA2.iso with bonding here: https://vimeo.com/1108152527; the process is the same for the VeeamJEOS.

2. Boot the ISO and Access the Shell

Start the virtual machine.

Once the virtual machine is running, you should see the installer splash screen. Select “Install Hardened Repository (deletes all data).” Hit ENTER to continue

Next, you will see the Installation Summary Screen. It is more limited than you might be used to with a standard Rocky Linux deployment.

  • Make sure the Keyboard is correct.
  • Select your time zone (region and city)
  • The installation (storage layout) is not configurable.
  • The Network and hostname section is where we will do the most work!

3. Identify Your Network Interfaces

You should see all your NICs listed, and when you select one, you can also see the MAC address. That helps verify which Hyper-V vNIC this corresponds to. Usually, they are listed on both Hyper-V and in the OS (e.g., eth0, eth1, …) in the order in which the script created them.

As you can see, one NIC got an IP address via DHCP, which is a good sign.

4. Create the Bond

Now, let’s set up bonding. Click the “+” button located to the left of the NIC listing.

Ensure the type is “Bond” and click “Add”. Now configure the bond:

Please give it a distinguishable name, such as LANBOND

Give the interface a name: lanbond0

Add the interfaces. These are of type “Ethernet”

Click Create and add the devices. In this example, we will add both LAN NICs. Round-Robin is best here. LACP is not suitable for Hyper-V guest deployments. However, you can certainly use it in a physical production setup.

Save this and take a peek at the bond interface now. It has received a DHCP address. Good, now let’s configure our static IP settings. All this is pretty straightforward. Enter the correct data, including the NIC IP, subnet mask (in CIDR or Dotted Decimal Notation), gateway IP, and DNS servers.

5. Check your bond status and turn your bond off and on

Now pay attention to the bond. It will display the original IP address until you disconnect and reconnect. Use the toggle button for this. But there is more. Look at the MAC address. Yes, it has a spoofed MAC address of one of the member interfaces.

That is why you need MAC spoofing enabled on those bond member NICs in the Hyper-V setting of your virtual machine.

Finally, enter the host name and click Apply.

Click Done! You can already ping test the address; it should work.

Click “Begin Installation” in the lower-right corner of the splash screen. You will get a warning that this will wipe all disks. That is not a concern here. Click Yes. Let the installation process run. You can follow the progress.

Reboot the system when asked.

Log in using the following credentials:

  • User: vhradmin
    • Password: vhradmin

You must change the password to one that meets the minimal complexity requirements.

Accept the license terms.

You will have a menu to work with.

One of the things to do is configure the proxy setting, manage the network configuration, update your system, and start SSH with a single-use password.

SSH gives you (controlled/protected) SSH access to take a peek under the hood or see if you can customize anything (lab only).

However, mainly, you need to temporarily enable SSH to add this repository to the Veeam fabric.

7. Troubleshooting tips

Look at your ping -t 192.168.2.101 replies. They should be returning an answer reliably! If not, here are some tips:

  • First, ensure that you ping from only one test machine, as you can only send five pings per second. If you test from multiple machines and consoles, you will easily exceed this limit and experience drops.
  • MAC Spoofing is non-negotiable. Without it, it won’t work
  • Make sure “Enable the network adapter to be a part of a team in the guest operating system” is enabled.
  • If you’re unsure which NIC is which, Hyper-V’s VM settings display the order in which you added them. But you can also use the MAC address to identify them via SSH if needed.

8. Bond failover testing

Once you have a reliable ping reply, do some further failover testing:

  • Unplug one vNIC in Hyper-V and verify connectivity.
  • Deactivate the members of the bond in Rocky Linux.

Note that you should not lose connectivity.

Conclusion

You are now ready to add that Veeam hardened repository to your Veeam Backup & Replication environment. Congrats.

Configuring bonding during installation with the GUI is surprisingly efficient. Suppose you forgot or want to change the configuration that is possible in the GUI provided by Veeam when you log on to the console. If you enable SSH, you can also use it to access the system; however, it is not necessary to configure bonding in this manner.

The Veeam Hardened Repository ISO is pretty slick! I like it a lot. I would like to see some flexibility in the backup storage configuration to allow for customization. I would also like to have MFA for console, SSH, and sudo actions, similar to what I have with Duo, which I use for my hardened repository builds. And guess what? Veeam is adding MFA to the JeOS ISO image with Veeam Backup & Replication 13. That, and mandatory Security Officer approval for privileged actions, under the ‘two pairs of eyes’ principle. Below is a sneak peek of that!

In lab environments running on Hyper-V, this blog post and my PowerShell script can help you get up and running quickly with redundant connectivity to reproduce production configurations. Please share your questions, experiences, or tweaks in the comments below.

Why You Need an Immutable Backup Repository, And Why Veeam’s Just Enough OS and VBR appliance are the Smart Choice

Introduction

Let’s be honest: if you’re still relying on traditional backup strategies without immutability in today’s threat landscape, you’re playing a game of Russian roulette. Ransomware isn’t just a buzzword. It’s a business model. Insider threats aren’t hypothetical; they’re happening. And when the proverbial shit hits the fan, your backups are either your lifeline or your liability. Then there are wipers, who want to destroy data and your business, nothing else. They don’t ask for ransom payments, blackmail you to stop them from exposing your confidential files, or threaten to harm your personnel physically. Destruction and mayhem are all they care about. You need protection!

So, how do you prepare for that? You need a hardened repository, providing immutability and protection from deletion! Not just any Windows or generic Linux box with some tweaks, but a purpose-built, security-first solution. And suppose you want to avoid reinventing the wheel while staying compliant and operationally sane. In that case, the Veeam Hardened Repository ISO or its successor, Veeam Just Enough OS (Veeam JEOS), is the recommended approach.

Now, while I focus on the why related to Veeam’s Hardened Repository ISO, it is worth noting that an immutable repository does not exist in isolation. The 3-2-1-1-0 rule, CPU core and memory sizing, redundancy, high availability, IOPS, throughput, and storage and networking capacity matter! However, when it comes to the 3-2-1-1-0 rule, I have always stated that I don’t count the production workload as a copy. However, that one immutable copy is something I’m gradually changing into zero non-immutable and deletable copies.

Additionally, hardening any role in your backup fabric is now a must. Everything is a target, including your employees, via social engineering.

Hardened Linux Repository with immutability

Using a Hardened Linux Repository with immutability should be mandatory. None of this is about being paranoid; it’s about being prepared. Sure, you can laugh at me, say it is overkill or too expensive. Laughing is healthy, so keep doing that. But listen to me. It is not overkill and is not more costly. It is not even more cumbersome, except for the inevitable extra steps in a zero-trust workflow. There is even a bonus: when ransomware strikes, listening to me might keep that smile on your face!

You may have seen my blog post, Revised script for decrypting datacenter credentials from the Veeam Backup & Replication database | Working Hard In IT. That post does not mean Veeam or Windows cryptography implementations are inherently flawed; it highlights the inevitable consequences of having root access to your system. Hence, you can guess that you require any server role in your Veeam backup environment to be hardened as much as possible. Veeam is therefore also providing a Veeam Software Appliance (VeeamSoftwareAppliance_13.0.0.12109.BETA2.iso).

When you build your own Veeam Hardened Linux Repository, you must take technical measures and establish a process flow to service genuine requests and protect against both external and internal malicious actions. All that is taken care of by the Veeam appliance approach. Not too shabby, not too shabby at all!

A hardened Linux repository is a tactical and strategic asset in a backup fabric. It gives you a fighting chance and serves as an ark of Noah to start over from. Below, we will discuss why it should be a mandatory component in your architecture.

Immutability is essential

If your backups can be deleted, encrypted, or tampered with, you don’t have backups, but “hope”. You have a false sense of security. Immutability ensures that your backup data is locked down and protected from malware or rogue administrators.

Pre-Hardened OS

Security isn’t just about firewalls and antivirus. It’s about reducing your attack surface. A pre-hardened OS turns off unnecessary services, enforces strict access controls, and aligns with best practices from the outset. That means a lot of work and worrying that you don’t have to do.

STIG Compliance

Want to sleep better at night? Align with government-grade security standards. STIG compliance ensures your repository is secure, and you can reference Veeam to support that claim when needed.

Ransomware Resilience

Ransomware loves backup data. It’s the first thing attackers go after. A hardened repository isolates your backups and enforces immutability, making it a fortress against encryption attempts.

Auditability & Compliance

GDPR, HIPAA, and ISO 27001 compliance isn’t optional. Hardened repositories support forensic analysis, secure logging, and system integrity checks. You’re not just protected; you can prove to an auditor. Yes, compliance is a thing, and while the actual protection comes before compliance reports, we cannot ignore that.

Operational Stability

Misconfigurations are the silent killers of IT. A hardened repo minimizes that risk. With pre-applied security settings, even teams without deep Linux chops can deploy confidently.

Maintenance without effort

Security updates and patches? Streamlined. Veeam handles the OS and repo updates, so you don’t have to babysit your infrastructure. I still need to determine if the ISO can also handle firmware updates for you.

Insider Threat Mitigation

Not every threat comes from outside. Role-based access, BMC port protection, and restricted shell access help prevent internal sabotage, whether accidental or intentional.

Strategic Value

All the above is not just a technical and operational advantage. It’s a business win. A hardened repo ensures your backups are a reliable recovery point, even when everything else goes sideways. It is your Ark of Noah! And guess what? Have redundant Arks! One is none, two is one 😉.

Why Veeam’s Just Enough OS ISO Is a Game-Changer

You could build your own hardened Linux repo. I’ve done it. It works. But it’s not for everyone. Veeam’s Hardened Repository ISO (VeeamHardenedRepository_2.0.0.8_20250117.iso) streamlines the process, automates the hardening, and provides a vendor-backed solution that’s ready for production.

The future Veeam Just Enough OS hardened repository (VeeamJEOS_13.0.0.12109.BETA2.iso) is well locked down, and privileged actions require security officer approval. While that is essential in a zero-trust world, it also means you must have your processes streamlined and communication lines open. When people need to reset a password or require root access for troubleshooting, they cannot wait until the next business day when the security officer is at work, let alone a week, because somebody has to bring it up at the weekly CISO approval board.

Look, you can roll your hardened repository if you have the skills, time, and appetite for ongoing maintenance. I have done that and might still do so depending on the environment and requirements. However, if you’re looking for a secure, compliant, and low-maintenance solution that works, Veeam Hardened Repository ISO or its successor, Veeam Just Enough OS, is the answer. By starting today, testing these solutions, you gain insights and experience using them, and will be optimally prepared for when Veeam Backup & Replication v13 becomes available. The Veeam Hardened Repository ISO has experimental support, enabling its use in production environments. At the very least, you can store one backup copy on it today. If you are interested in this for future use, consider Veeam Just Enough OS (VeeamJEOS_13.0.0.12109.BETA2.iso) as part of the future V13 release. However, that one is not yet production-ready. But it won’t be long now when we look at the post by Anton Gostev on LinkedIn! At the time of writing this post, it should be less than a month.

Conclusion

The above is not paranoia, and it’s not just about ticking boxes for compliance. It’s about building a backup strategy that survives real-world threats. And in that world, immutability isn’t optional. It’s your insurance policy. Look, I have seen the devastation ransomware causes. It is a horrible place to be. I don’t want you to be in that world of hurt. However, we cannot prevent it. You are a target, and you will get hit. It is a question of when, not if. So make sure you have the means to come out on top!

Revised script for decrypting datacenter credentials from the Veeam Backup & Replication database

Introduction

In a previous article (Protecting your Veeam Backup and Replication Server is critical | Working Hard In IT), I discussed my script for decrypting the datacenter credentials from the Veeam Backup & Replication database. Since then, that PowerShell code has been published dozens of times all over the internet in various articles.

However, three relevant things have changed since my original blog post:

  1. Veeam v12.1 introduced a new encryption method.
    Firstly, in Veeam 12.1, the method of encrypting passwords has changed. That means the old script no longer works (always) as it only uses the legacy method.
  2. Veeam published its encryption and decryption methods.
    Secondly, Veeam has published the methods used to encrypt and decrypt passwords in the spirit of full disclosure and to preempt anyone who attempts to claim that Veeam is insecure. Those individuals or companies demonstrate only ignorance and malicious intentions. The good news is that the article has all the information we need to write a new script.
  3. Veeam now supports PostgreSQL, in addition to Microsoft SQL Server.
    Finally, Veeam now also supports MySQL as a database, in addition to Microsoft SQL. That means we need to ensure that we can retrieve the necessary data from both database types.

Background Info & approach

I based the script on information found in the Veeam KB article “How to Recover Account Credentials From the Veeam Backup & Replication Database” (https://www.veeam.com/kb4349).

Instead of having two scripts, my old one and a newer one. I decided to create one that would work on VBR v12 and lower, as well as on VBR 12.1 and higher.

What Changed in Encryption

Until version 12, Veeam used its internal .NET static method:

[Veeam.Backup.Common.ProtectedStorage]::GetLocalString($encryptedPassword)

That method leverages the native Microsoft Data Protection API (DPAPI) under the hood. It was part of the Veeam.Backup.Common.dll and worked well up to version 12. In v12.1 and beyond, this method no longer exists. Instead, Veeam now leverages the native Microsoft Data Protection API (DPAPI), directly:

[System.Security.Cryptography.ProtectedData]::Unprotect($bytes, $salt, ‘LocalMachine’)

Since both leverage the native Microsoft Data Protection API, I figured I could also use the [System.Security.Cryptography.ProtectedData]::Unprotect static method to decrypt those legacy passwords as long as I don’t try to leverage the optionalEntropy parameter for them. The good news is that in the KB article, Veeam provides instructions on how to differentiate between the legacy and new types of password encryption. That allows me to write logic to determine the version and execute the corresponding decryption method accordingly.

By the way, once you update a password on v12.1 or up, it will be encrypted with the new method. As time passes, by rotating the passwords, legacy encryption phases out.

The new script

I did not want to maintain two separate scripts, one for the legacy password decryption method and one for the newer one. That’s why  I’ve consolidated everything into a single, unified PowerShell script. It supports:

  • Supports VBR v10 through v12.3+ and decrypts Veeam credentials from registry and database.
    • The Veeam Backup & Replication encryption salt in the registry lives here: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\Data.

    • The Veeam database info in the registry lives here:
      Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\DatabaseConfigurations\
  • Per-user counters and clean output formatting
  • Supports MSSQL and PostgreSQL configurations
  • Handles multiple password formats:
    • ‘v12 and lower’
    • ‘v12.1 and up (with encryption salt)’
  • Optional filtering by username
  • Optional export to file (`Veeam_Credentials.txt` on Desktop)
  • Graceful error handling and informative console output

The script runs on Windows only, because DPAPI is a Windows-native feature. With VBR v13 introducing Linux-based deployments, this script won’t work in those environments. That’s a different challenge for another day.

Getting the script

You can find the script on GitHub at https://github.com/WorkingHardInIT/Revised-script-for-decrypting-datacenter-credentials-from-the-Veeam-Backup-Replication-database. You will also find the documentation there.

Why do I need this script?

The IT world, like everywhere else, is not a perfect place, and I need a way to deal with imperfection. It is that simple. If we are honest, we all know that  IT environments aren’t always in pristine condition. Whether it’s a lab, a forgotten backup server, or an entire backup fabric for a production environment abandoned by a previous IT partner, credentials are often missing. Documentation is sparse. And when disaster strikes, you need access, fast.

My script has already helped IT teams recover access to critical systems when no one else could. I know because I’ve seen it happen. Before Veeam ever published its KB article, my original script was quietly saving the day in real-world scenarios.

Conclusion

Knowledge is power. And while power inherently allows abuse, hiding knowledge under the guise of “security” is just security theater. Security through obscurity is not security but window dressing.

That’s why I’m glad Veeam documented their credential encryption methods. It empowers administrators to recover access responsibly. And it exposes the charlatans who twist transparency into baseless accusations of insecurity. I just felt compelled to create a handy, functional script around it that I can use when needed.

If someone uses this information to claim Veeam is irresponsible, they could not be more wrong. They prove themselves to be untrustworthy. To me, they’ve lost their reputation and credibility.

This script isn’t about hacking. It’s about recovery, accountability, and clarity. And if it helps you regain control of your environment when all else fails, then it’s done its job.

Veeam Hardened Repository ISO: Overview and Requirements

Introduction

Readers of my blog and other articles will know that I am a strong advocate of immutable backups, and Veeam delivers this functionality through its Linux Hardened Repository. I have several articles on how to set this up, secure it, add MFA, extend and repair XFS volumes, and more. I have designed and run many successful deployments in production.

In my latest designs, I have introduced a process flow to ensure that backups are not only immutable but also undeletable. The way to do this is to disallow root/sudo access to key personnel who are not involved in daily operations, and who must agree to allow and grant access under the 4-eyes principle. Why? To ensure no one, accidentally or otherwise, makes preventable, bad decisions.

Still, I notice that many people are hesitant to use it, as the perceived complexity of Linux deters them. Veeam has been addressing this perception, which is partially real and partially driven by fear, by providing the Veeam Hardened Repository ISO to simplify deployment and maintenance. Today, we will be looking into that

The Veeam Hardened Repository ISO

The Veeam Hardened Repository ISO (abbreviated to VHRISO on the forums) is a preconfigured, bootable ISO image based on the Rocky Linux distribution, developed and maintained by Veeam. It delivers a Managed Hardened Repository solution designed to simplify deployment and enhance security for backup infrastructures.

This solution caters to the masses to provide better security for all:

  • Minimize the need for Linux expertise during the setup process.
  • Provide a hardened operating system with advanced security configurations applied by default.
  • Ensure secure and compliant backup storage aligned with industry standards.

Security Foundation

The operating system embedded in VHRISO is pre-hardened using guidelines from the Security Technical Implementation Guides (STIGs), maintained by the Defense Information Systems Agency (DISA) for Rocky Linux. All this ensures that even if immutability is enabled, misconfigurations are less likely to compromise the system.

Support Status

As of October 29, 2024, VHRISO transitioned from Community Preview to Experimental Support status. That means that production use is officially supported.

You can open support cases for issues, except those related to the ISO Installer and Configurator Tool, which fall under experimental SLA terms.

Only unmodified versions of VHRISO deployed on compliant hardware are eligible for support.

Veeam announced that it will integrate the standalone ISO into the platform in the next release of Veeam Backup & Replication, V13.

The main points of that announcement are:

  • Veeam will integrate the standalone ISO into the platform via the new “Just Enough OS” (JeOS) ISO, which will enable deployment of various backup roles, including the hardened repository.
  • Centralized Updates: JeOS will manage and update the OS and Veeam components across all backup infrastructure roles, simplifying maintenance with automatic patching during scheduled windows.
  • Easier Provisioning: V13 removes the need for complex passwords in setting up a hardened repository. It will use thumbprint verification and a temporary PIN code for repairing with backup servers.
  • Host Management Web UI: A new web interface will provide an easy-to-use management tool for JeOS and Veeam settings, with security safeguards to minimize exposure.
  • Full Support for Managed Repositories: Managed hardened repositories deployed from the V13 JeOS ISO will now be fully supported, moving beyond experimental status.

See Anton Gostev’s announcement here: https://www.linkedin.com/posts/askgostev_weve-been-getting-many-questions-about-our-activity-7312464807171923969-q1YR/

Latest Release

On January 29, 2025, Veeam released Build 2.0.0.8, available via:

You can find it in the Veeam Customer Portal https://www.veeam.com/download_add_packs/vmware-esx-backup/hardened-repository/

Trial Downloads section under: Additional Downloads > Extensions and Other > Veeam Hardened Repository ISO

System Requirements

To ensure compatibility and optimal performance, you must meet the following prerequisites:

Software Requirements

  • Veeam Backup & Replication version 12.2 or later

Hardware Requirements

  • You must use hardware from the Red Hat compatibility list or the Certified Quality and Independent organization certified hardware list
  • Enable UEFI Secure Boot
  • Do NOT install third-party security software
  • Only hardware RAID controllers are supported
    • Software RAID, Intel VMD VROC, and FakeRAID are not supported
    • RAID controllers must have write-back cache enabled
  • Use internal or direct-attached storage only

Storage Configuration

  • Minimum of two storage volumes:
    • One for the OS (≥100 GB)
    • One or more for data (must be larger than OS volume)
  • The smallest disk must be identifiable (e.g., 100 GB + 101 GB is valid; 2x 100 GB + 1x 200 TB is invalid)
  • Recommended: Dual-parity RAID configuration

Network Requirements

  • Standard backup repository ports must be open
  • You must allow direct or HTTP proxy access to repository.veeam.com on port 443 for:
    • OS and security updates
    • GPG key renewal (failure to update will require complete OS reinstallation)

Security Best Practices

  • Secure the Baseboard Management Controller (BMC) port using firewalls and strong credentials
  • Avoid deploying VHRISO on virtual machines due to:
    • Increased attack surface via hypervisor
    • Risk of backup inaccessibility during host outages

New Features in Build 2.0.0.8

  • Repair Mode: Reinstall the OS while preserving data partitions.
  • Live Boot: Built-in diagnostics and performance testing.
  • Zero-Touch Installation: Fully automated deployment using Kickstart.
  • IPv6 DHCP Support: Enhanced connectivity options.
  • Enhanced Ping Limits: Rate-limited pings for better troubleshooting.
  • Improved Workflow: Clearer installation steps and safeguards against accidental disk formatting.

Conclusion

The Veeam Hardened Repository ISO aims to provide hardened and immutable repositories in as many deployments as possible. I think they are making progress in achieving this goal. I believe that every Veeam Backup Fabric deployment, whether small or large, should have hardened repositories with immutable backup copies. That is my more recent stance. I used to do it for at least one copy, as that worked out well with refresh projects, but I want to end up with all repositories and backup data copies being immutable and stored on a hardened repository.

I am currently building a lab for the Veeam Hardened Repository ISO to gain experience with it and be well-prepared for the arrival of Veeam Backup & Replication V13. I hope to share some information on that later.