How the HA cluster works
The v13 HA cluster is a two-node active/passive setup for the Linux Software Appliance. One node is primary and runs all backup and replication operations. The secondary sits in standby, continuously receiving a replicated copy of the primary's configuration database. If the primary goes down, you promote the secondary and work resumes against the same repositories.
Replication between nodes uses Patroni, the PostgreSQL high availability framework. The primary's configuration database is continuously streamed to the secondary as WAL logs. TCP must be open between nodes for this to work - if the TCP connection drops, WAL logs accumulate on the primary until the secondary reconnects. The secondary is read-only and cannot run backup jobs independently while in standby.
What replicates between nodes: the VBR configuration database and configuration state. What does not replicate: backup data. Your repositories are completely separate infrastructure. Both nodes can reach them, and they stay exactly where they are during a failover. The only thing that moves is which node is active.
A virtual cluster IP address floats between nodes. You always connect to that IP - or its DNS name - rather than to individual node addresses. When failover or switchover happens, the virtual IP migrates to the new primary. Everything pointing at the cluster IP keeps working without reconfiguration.
| VERSION AND LICENSE REQUIREMENT |
| HA cluster requires VBR 13.0.1 or later. It was not included in the initial 13.0.0 release. You also need Veeam Data Platform Premium license applied to the primary node. The feature is not available in Foundation, Advanced, Essentials, Community Edition, or NFR licenses. |
Requirements and hard limitations
| Requirement | Detail |
| License | Veeam Data Platform Premium Edition, applied to primary node only |
| VBR version | 13.0.1 or later on both nodes |
| Node platform | Veeam Software Appliance (Linux) only on both nodes. Windows-based VBR cannot participate |
| Node count | Exactly two nodes. No three-node configurations |
| Network | Both nodes and the virtual cluster IP must be on the same subnet. Static IPs required for all three. IPv4 and IPv6 cannot be mixed |
| DNS | Both nodes must have the same DNS suffixes. Forward and reverse DNS records for all three addresses must resolve correctly before assembly |
| TCP between nodes | TCP must be open between primary and secondary for WAL log streaming |
| Local repositories | Cannot be used within an HA cluster. The default local repository on the backup server is not usable. All repositories must be external |
| Management tool | Windows-based VBR console only. The wizard cannot be run from the Web UI or Host Management console |
| Storage API plug-ins | Not automatically installed on HA nodes. Must be installed manually on both nodes |
What to prepare before you start
You need three static IP addresses on the same subnet: the primary node IP, the secondary node IP, and the virtual cluster IP. The primary node IP likely already exists if you have a running appliance. Reserve the other two before proceeding.
In DNS, create A records for the primary node hostname, the secondary node hostname, and the cluster endpoint hostname. Then create matching PTR reverse records for all three IPs. Test all six lookups from the machine you will run the Windows console on before touching the wizard. If DNS is wrong, cluster assembly will fail.
Deploy the secondary as a fresh Veeam Software Appliance using the same ISO version as the primary. Assign the static IP you reserved, set the hostname to match the DNS record you created, and complete the full appliance initial configuration wizard including the Security Officer account if you use one in your environment.
Install the Premium license on the primary node through the VBR Web UI: Settings (gear icon), License Information, License tab, Install. The secondary does not need a separate license install.
You can use an existing backup server as the primary node - you do not have to start fresh. Just make sure you do not designate the same backup server as both primary and secondary.
Submit HA enable requests through Host Management
Before you can run the cluster wizard in the Windows console, you must submit an HA enable request through the Host Management console on each node separately. This is the step that catches people by surprise because it is not in the Windows console at all.
On the primary node
In a browser, go tohttps://<primary-node-ip-or-hostname>:10443. Log in with the Host Administrator account. In the navigation, click Applications. Under the High Availability section, click Submit Request. If a Security Officer account is configured on this appliance, the Security Officer must log in separately and approve the request before it takes effect.
On the secondary node
Go tohttps://<secondary-node-ip-or-hostname>:10443. Log in with that node's Host Administrator account. Click Applications, then Submit Request under High Availability. Again, if a Security Officer is configured on that node, they must approve it.
| THE APPROVAL HAS A TIME LIMIT |
| The HA enable approval is valid for a limited time window after it is granted. Complete the cluster assembly in the Windows console before it expires. If it expires, you need to submit and approve the request again on both nodes. |
Assemble the cluster in the Windows console
Connect the Windows console directly to the primary node - not the cluster IP, that does not exist yet. Use the primary node's hostname or IP address.
Step 1 - Launch the wizard
In the console, go to Backup Infrastructure > Managed Servers > Linux. Find your primary node in the list. Right-click it and select Create HA Cluster.
Step 2 - Specify cluster settings
Enter the virtual cluster IP address and the cluster endpoint DNS name. These must exactly match the IP and A record you created for the cluster endpoint. Double-check them here - if you enter the wrong cluster IP, you will need to disassemble and rebuild to correct it.
Step 3 - Specify cluster node settings
The primary node IP is pre-populated from the machine you connected to. Confirm it is correct. For the secondary node, enter its IP address and specify the Host Administrator credentials for that appliance.
Step 4 - Review and finish
Review the summary and click Finish. Veeam assigns the virtual cluster IP to the primary node, connects to the secondary, initializes it as a read-only standby, deploys the HA service on both nodes, and starts synchronization. When it completes, disconnect the console from the primary node IP and reconnect using the cluster endpoint hostname or virtual cluster IP. From this point forward, always connect through the cluster endpoint.
| SELF-SIGNED CERTIFICATE |
| If you want the cluster DNS name included in the self-signed certificate alternative names, you must regenerate the certificate after assembling the cluster. This is not automatic. |
Verify the cluster is healthy
After reconnecting through the cluster endpoint, go to Backup Infrastructure > Managed Servers. The HA cluster appears as a single entry with both nodes shown underneath, labeled Primary and Secondary. Both should show healthy status.
Right-click the cluster and select Rescan to force a fresh status check. If the secondary shows a warning, check TCP connectivity between nodes first, then confirm the Patroni service is running on both.
Enterprise Manager and HA clusters
If your VBR server is connected to Enterprise Manager, you must re-add it in EM using the cluster virtual IP address or cluster DNS name after assembling the cluster. EM does not automatically update the server entry. If you leave the original individual node IP in EM, EM will lose the ability to collect data after a switchover or failover.
In the EM web console, go to Configuration > Backup Servers. Remove the existing entry for the VBR server, then add it back using the cluster virtual IP or cluster DNS name.
Switchover (planned)
Use switchover when both nodes are healthy, synchronized, and you need to take the primary down for planned maintenance. In the Backup Infrastructure view, right-click the HA cluster and select Switchover. Veeam confirms both nodes are in sync before proceeding, stops running jobs on the current primary, migrates the virtual cluster IP to the secondary, and promotes it to active. The process takes around 10 minutes.
After your maintenance work, you can leave the new node assignment in place or switchover again to restore the original layout. There is no requirement to switch back.
| TEST THIS BEFORE YOU NEED IT |
| Run a switchover in a non-emergency situation first. You want to confirm the virtual IP migration works in your network and the console reconnects cleanly. Discovering a DNS or network issue during an actual outage is a much worse experience. |
Failover (unplanned)
Use failover when the primary is down and not recovering. Veeam ONE includes dedicated HA cluster alarms and can be configured to trigger automated failover when the primary becomes unavailable - meaning failover can happen without manual intervention if you configure the alarm action before you need it.
Without automated failover, trigger it manually: connect the console to the cluster endpoint, go to Backup Infrastructure, right-click the cluster, and select Failover. Veeam promotes the secondary, assigns the virtual cluster IP to it, and resumes backup operations on the new primary.
After the failover and after the original primary is repaired and back online, it rejoins the cluster automatically as the new secondary. You do not need to rebuild the cluster from scratch after a failover.
Limitations table
| Limitation | Detail |
| Two nodes only | Exactly two nodes. No three-node or quorum configurations |
| Linux Software Appliance only | Windows-based VBR installations cannot participate |
| Premium license required | Veeam Data Platform Premium, applied to primary node only |
| VBR 13.0.1 minimum | Not available in the 13.0.0 release. Both nodes must run the same VBR version |
| Same subnet | Both nodes and virtual cluster IP must be on the same subnet |
| No local repositories | The default local repository on the backup server cannot be used. All repositories must be external |
| Console only for management | HA cluster cannot be managed via the Web UI or Host Management console. Windows console required |
| EM must be re-added after assembly | Enterprise Manager must be updated to use the cluster virtual IP or DNS name |
| Storage API plug-ins | Not automatically installed on HA nodes. Must be installed manually on both nodes |
| Syslog events | HA reconfiguration and failover events are not written to the syslog server |
| Manual failover by default | Failover is manual unless automated failover is configured through Veeam ONE alarms |
Failover is manual unless automated failover is configured through Veeam ONE alarms
https://www.anystackarchitect.com/veeam-v13-ha-cluster-setup/
