In my last blog post, I covered the basics and requirements of HA in v13.0.1. With a short how-to and a step-by-step guide, I wanted to show how quickly HA can be set up in your own environment and what added value it brings. In my day-to-day work as a Systems Engineer at Veeam, I've also come into contact with HA at many customer sites. Most of the feedback was positive, but unfortunately there were also some issues around stability and node connectivity. That's why I'm even more excited about the release of v13.1, which brings further improvements to this topic. In this article, I want to focus on these improvements: what's changing in the new version, and what else we can expect. For everyone who just wants the summary, here's the TL:DR: TL:DR Requirements for HA remain unchanged (2x VSA, VDP Premium license, Remote Console) — HA is still exclusive to the Veeam Software Appliance. Cross-subnet deployment: HA nodes no longer need to be in the same subnet. A cluster DNS name now resolves to two external IPs (one per node) via round robin, with the primary node accepting connections and the secondary rejecting them. User synchronization: users created on the primary node are now automatically synced to the secondary node every 2–3 minutes (read-only on the secondary). Private fixes synchronization: private fixes are now synced from primary to secondary as well; installation is blocked on the secondary. More transparency: switchovers now show the replication lag and let you choose whether to wait for full sync or proceed anyway; the Remote Console also indicates when the secondary node is being updated. Edit HA cluster: cluster settings can now be edited without disassembling and recreating the cluster. REST API: full HA cluster management (create, edit, switchover, failover, disassemble) is now available via REST API. Basics and Requirements - Again To avoid repeating everything we already discussed last time, here's a short recap (you can find the previous post here -> Link). Even in the newest version, the requirements remain the same. We still need: 2x VSA VDP Premium license The Remote Console, to initiate switchovers and failovers or to configure HA in general So HA will continue to be available only on the Veeam Software Appliance. That said, the aggressive expansion of the WebGUI is a good sign for HA. We can expect that operations such as setting up an HA cluster, or performing switchovers and failovers, will be configurable via the WebGUI in the future. Cross-Subnet Deployment Many customers gave immediate feedback when HA was released in v13.0.1: why did both nodes have to be in the same subnet? In practice, many components are split across different network segments or entire sites, either to support DR strategies or to improve resilience. Sure, there were workarounds, but nothing Veeam delivered out of the box — which was a blocker for many. Good news: this limitation has been removed in v13.1. Instead of relying on a single cluster IP (or cluster DNS name) to connect to the HA cluster, a cluster DNS name is now used. When this name is resolved via DNS, it returns two external IP addresses in round-robin fashion — one per node. The cluster is designed so that the "correct," i.e. primary, node accepts the connection, while the secondary node refuses it. In addition, each node now has an additional internal IP address for node-to-node and internal cluster communication. So the important thing to know: DNS needs to work, and HA handles everything else in the background. If you still want to use a standard HA cluster (same subnet), the setup doesn't change compared to v13.0.x. We still need a cluster IP, a cluster DNS name, a primary node IP, and a secondary node IP, as shown here: And now, by comparison, the cross-subnet HA cluster: After that, it should look something like this: As we already know, the console caches the IP addresses of both nodes. So in a worst-case scenario, we don't need to determine the IPs first — we already know exactly where to connect and which node is (or still is) the primary. This is handled via the corresponding firewall rules on the nodes: the primary allows connections, while the secondary drops them. While testing this in my homelab, I also noticed that the WebGUI on port 443 is blocked on the secondary node. This way, you can always be sure you're connected to, and working on, the primary node. Just make sure you have configured the DNS server settings for the HA cluster with a cross-subnet configuration: • DNS name resolution for the cluster • Two A (or AAAA) records for the same cluster hostname, one for each external IP. When a client resolves the cluster hostname, the DNS returns both addresses. User Synchronization One thing that wasn't at all obvious after an HA deployment — and was only listed under Known Issues in the Help Center — was that users on the primary node were not synchronized to the secondary. This resulted in failed logins, missing permissions, and general confusion. This behavior has now been changed. Users on the primary node are synchronized to the secondary every 2–3 minutes. If you want to edit these users, you need to do so on the primary, since the synced-over users on the secondary are only available in a read-only state. Please keep in mind that user synchronization completely replaces the users on the secondary node with those on the primary node. This includes the following data: - Passwords - MFA Configurations In addition, during my lab tests, I noticed some limitations depending on whether Security Officer is used or not. User synchronization only works if the Security Officer status matches on both nodes—that is, either SO is configured on both nodes or on neither. Private Fixes Synchronization Similar to users, private fixes are now synchronized from the primary to the secondary node. Here too, the secondary node blocks the installation of fixes, since the same principle applies: the primary is the only source of truth. Please also note that private fixes that were already installed before the cluster was created will not be synchronized. This synchronization process can also be observed in the VBR console: More Transparency About HA Switchover and Upgrade Under certain circumstances — for example, right after creating an HA cluster — it can happen that all settings and configuration haven't been fully synchronized from primary to secondary yet. We now have the option, during a switchover, to decide whether to wait for synchronization to complete or to accept a replication lag of X MB/GB. This gives us more control and transparency over management. What I find especially nice here is the display showing how large the lag is and what the last known state was. The following message then appears: (not my screenshot) Separately from this, the Remote Console now also shows when the secondary node is being updated — a small but important addition for more transparency. Edit HA Cluster Capability This improvement will make every Veeam homelab owner happy — at least it made me happy :D. I can't count how many times I had to disassemble an HA cluster just to test various use cases, or because I wanted to adjust the cluster itself. Fortunately, this setting was added, allowing you to edit the cluster without having to disassemble and recreate it. REST API Enhancement HA cluster management can now also be controlled via REST API. This includes the operations already available in the Remote Console: Create cluster, in both standard and cross-subnet mode Edit cluster Switchover Failover Disassemble cluster Summary All in all, a really nice quality-of-life update with more insight behind the scenes.

With the High Availability feature in Veeam Software Appliance 13.0.1 , Veeam provides a neat way to make the backup server highly available. In this blog post I’ll briefly show how to configure HA, which prerequisites must be met, and what alternatives exist if HA cannot be used. Intro - The Basics The feature itself reduces downtime of the backup server in the Veeam Software Appliance. In general, two nodes are required; they can synchronize even across relatively high latencies. A manual switchover is possible, and a major advantage is automatic updates for both nodes. The goal is to offer fast disaster recovery without the need to keep a dedicated standby backup server, and then finally to restore the configuration backup. ( https://helpcenter.veeam.com/docs/vbr/userguide/high_availability_hiw.html?ver=13 ) Requirements The following components are required for this feature: Two Veeam Software Appliances At minimum, Veeam Data Platform — Premium  licensing (the package that includes Veeam Backup & Replication, Veeam One, and Veeam Recovery Orchestrator) Three IP addresses: Two for the Primary and Secondary nodes One for the cluster (virtual IP) All addresses must be in the same Layer-2 network / same subnet Strongly recommended: proper DNS entries for the Primary node, Secondary node and the cluster name Please also read the considerations and limitations regarding HA beforehand. https://helpcenter.veeam.com/docs/vbr/userguide/high_availability_limitations.html?ver=13 How to configure HA — Step by Step Log in to the Veeam Host Management Console of the first node. In the navigation panel, open Backup Infrastructure . Under High Availability , select Submit Request . If no Security Officer  account was configured during the Veeam Software Appliance installation, the request will be approved automatically. If a Security Officer  account is configured, you must wait for the officer to approve the request. The approval is valid for 8 hours, so make sure to assemble the cluster within that time frame. In my test lab, I now have to log in to the same Veeam Host Management Console with my security officer and approve this request. If you have installed the Veeam Software Appliance but have never logged in to the Veeam Host Management Console with the Security Officer, you will need to complete a few steps, as shown here Log in to the Veeam Host Management Console using the security officer account. Change the password as instructed. Configure your multi-factor authentication (MFA) Keep your recovery token safe! It is very important. If you forget or lose your password, or if your Security Officer account is locked after three failed login attempts, you can use a recovery token to regain access to your account. Specify a passphrase and hint for the sensitive data stored in configuration backups. After we have officially logged in, we can already see the request. We approve it. We repeat this step on Node 2 as well! Then we return to the Veeam Backup & Replication Console. The following steps cannot currently be performed in the VBR Web UI Preview. We navigate to Backup Infrastructure , click on Managed Servers -> Linux , and select our first node. In my case, this is “vsa-n01” Now we can open the context menu by right-clicking or press the “Create HA Cluster” button at the top under the Server tab. Then suddenly the following error message appeared: There is a known issue in version 13.0.1 that can prevent the creation of an HA cluster if a capacity tier is configured. If the following error message appears even though all local repositories have been removed and the capacity tier has been configured, please wait for a patch or try the workaround described below. Scenario: v13.0.1 GA Capacity Tier is configured Trying to create a HA cluster Workaround: Remove the Capacity Tier from the SOBR configuration. Create the HA cluster. Add the Capacity Tier back to the SOBR. Actually, that wasn't the case here. In my lab, I only had the freshly installed VSAs, no other repository. So I went ahead and added an additional repository on a dedicated Windows server and switched the configuration backup there. After that, I removed the local repository. That helped. Here we assign a cluster DNS name and assign our virtual IP address. We select the IP address of the first node (on the VSA where we are currently located). Enter the IP address of the second VSA and the credentials. We confirm the connection. We click on Finish . Immediately afterwards, the setup of our HA cluster will begin, as shown here. We wait patiently, and then everything should look green. In my case, it took about 15 minutes (TestLab). Looks good :) A quick note: Now we should only connect to the cluster DNS name or its IP address, not to the nodes individually. Performing Switchover Initiating a switchover is super easy. We navigate back to Backup Infrastructure , select our second node (Secondary), and can start the switchover to another node again at the top or by right-clicking. Don't worry. The switchover needs to be confirmed again. Then it's time to wait. After a while, we are even kicked out of the console. That's it! After that, we can log in again and see that the nodes have been swapped in the primary and secondary functions. Performing Failover Now let's simulate a failure! I go over and shut down my primary VSA and log in to the VBR console. Oh dear. Our primary node is down. We are now connecting to the second node via Connect . Veeam now switches to the second node. The second node is now upgraded to primary and can then resume its function as the backup server. The process took about 10 minutes for me. Once you are in the VBR Console, you will be told quite clearly that your second node (now secondary) is offline, so it's time to take action and fix the error. In my case, it was simply a matter of starting the VM. The failed Veeam software appliance then starts normally and logs in to the current primary to synchronize and see who is now primary. You can read about the exact workflow here. https://helpcenter.veeam.com/docs/vbr/userguide/high_availability_failover.html?ver=13 Alternatives to HA If you cannot meet the requirements listed above, you could try the following alternatives: Create a standby backup server that can start operating in an emergency with a configuration backup. If your backup server runs as a VM, you can also use VBR to replicate your own backup server to another hypervisor node and and manually start the replica in an emergency if your production data center has failed.

When working with Veeam Recovery Orchestrator (VRO), you might occasionally run into situations where the system makes decisions that aren’t immediately intuitive. Recently, a partner approached us with a scenario that raised exactly that kind of question: How does VRO choose which backup copy to use when multiple copies exist? Let’s walk through the use case, the unexpected behavior, and what we learned from digging into it. The Scenario In this environment, VRO is running at the disaster recovery site and orchestrating a vSphere-to-vSphere restore plan . The plan uses the following steps: A backup-to-disk job writes backups to a local backup repository. Immediately afterward, two backup copy jobs  run in parallel to copy the backup data to two additional repositories — let’s call them Repository A  and Repository B . The restore plan is configured to use backup copies , as described in the VRO documentation. The goal is to use the restore points created by the backup copy jobs as the source for the recovery process. But something strange happens: VRO correctly uses a backup copy restore point, but it always selects the restore point stored on Repository A  — even though the customer wants VRO to use the copies on Repository B. So the question is: How does VRO decide which backup copy to use when multiple equally valid copies exist? Testing the Behavior To better understand the selection logic, I replicated the scenario in a lab: Two backup copy jobs were created. One copy job ran first, followed by the second job so that the second job would create the “most recent” backup chain. Initially, this worked as expected: the repository with the newer chain (Repository A in this test) was used. After reversing the job order, I expected VRO to pick Repository B instead — but surprisingly, VRO still selected Repository A . This suggests that VRO does not  make its decision solely based on job execution order or chain timestamps. So How Does VRO Choose? According to Alec King from Veeam: VRO does not consider the timestamp of the backup copy job. It selects based on the timestamp of the restore point itself. This is the key detail. All backup copies created from the same source backup job share the same restore point timestamp , even if they were copied at different times. Because of that, when multiple identical restore points exist across several repositories, VRO sees them as equally valid , and its selection may not reflect the user’s preference. In other words, the system has no inherent logic today to prioritize Repository A over Repository B or vice versa. This explains the “strange behavior” — VRO isn’t doing anything wrong; it simply has no mechanism yet to choose between duplicate restore points  from different locations. The Good News: Repository Selection Is Coming Alec also shared that repository selection logic already exists for Azure recovery locations , but not yet for VMware-to-VMware scenarios. https://helpcenter.veeam.com/docs/vro/userguide/cloud_location_backup_servers.html?ver=13 The Veeam team is actively working on adding repository selection for VMware environments  in an upcoming VRO release. While not fully confirmed, it’s on their roadmap and will directly address this use case. Is There a Workaround? Unfortunately, no reliable workaround exists today. Copying the backup again (e.g., a backup copy of a backup copy) won’t help because: VRO still checks the restore point timestamp — and that remains identical across all copies. The only long-term fix will be the upcoming repository selection feature. Conclusion If you’re running multiple backup copy jobs in VRO and relying on the “Use backup copies” option, be aware that: VRO selects restore points based on restore point timestamp , not on backup copy job details. Multiple identical restore points across repositories are considered equal. You currently cannot force VRO to prefer a specific repository. Veeam is actively working to add repository selection for VMware restore plans in a future release. Once available, this enhancement will give users precise control and eliminate the ambiguity seen in scenarios like this.

Hello World! Welcome to my very first blog post — and my very own website! I’ve actually been toying with the idea of writing blog posts for quite a while but never really followed through… until now. I always felt there were already thousands of blogs out there and that adding another one wouldn’t make much of a difference. I also had huge respect for my IT colleagues, many of whom are far deeper in the technical weeds than I am. But the fact that you’re reading this right now means something changed. One thing has remained true though: information — whether researched manually or powered by AI — is always based on sources. Blog posts are perfect platforms for sharing insights, documenting use cases or how-to's, and exploring troubleshooting steps. So if you don’t want to miss my journey as a “blogger,” feel free to check back regularly! But First: Who Am I? My name is Marvin Michalski . I’m from the beautiful city of Koblenz, and I’m a trained IT specialist in system integration. I’ve always had a passion for IT — probably because I spent way too many hours in front of a console as a kid. I started my apprenticeship in 2017 at a small local IT service provider in the area, and I was lucky enough to finish just before the pandemic hit in January 2020. As a consultant, I gradually specialized in virtualization, storage, and backup — back then mostly with VMware vSphere, DataCore SANsymphony, and Veeam Backup & Replication. In early 2023, I got the rare opportunity to work for the company whose software I had simply fallen in love with: Veeam Software. So as a complete newcomer, I began my journey as a Systems Engineer — full of doubts and uncertainty about whether I could live up to the challenge. And here I am now… What Topics Will I Cover on This Blog? Primarily technical content around virtualization, storage, and backup. Naturally, many posts will involve Veeam — simply because it’s both my passion and my job. But I’ll always try to remain objective and share my honest thoughts. Here’s the important disclaimer: All views and opinions expressed here are my own and do not necessarily reflect those of my employer. Besides Veeam-related topics, I’ll write about anything else that comes to mind in the virtualization and storage world. I also try to create shorts and videos for YouTube, LinkedIn, and Instagram — so if you’re active there, feel free to check out my channels. You’ll find the links in the footer of this website. Outside of work, I enjoy staying active, spending time with friends, and getting absorbed in a good series or movie. Whenever I find the time, I squeeze in some gaming — and in summer, you’ll usually find me on my motorcycle. Thank you very much for reading, and I hope you’ll enjoy my posts. Things are about to get much more technical from here on out 😉