Veeam v13: High Availability Cluster Setup from Scratch

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.

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. The official docs are explicit: if DNS is wrong, cluster assembly will fail. Sorting out DNS after the fact is painful.

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 also 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. If you do, the secondary's configuration database gets replaced by the primary's during assembly.

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.

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.

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. This queries both nodes, confirms the HA service is running, and verifies replication is active and synchronized. If the secondary shows a warning, check TCP connectivity between nodes first, then confirm the Patroni service is running on both.

You can view session statistics by right-clicking the cluster and selecting Statistics. This shows the HA maintenance sessions that periodically sync configuration data. Healthy completed sessions confirm replication is working.

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 from that server after a switchover or failover, because the individual node IP is no longer the active primary.

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.

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 original primary transitions to standby. The process takes around 10 minutes.

After your maintenance work on what is now the standby, you can leave the new node assignment in place or switchover again to restore the original layout. There is no requirement to switch back.

Use failover when the primary is down and not recovering in a reasonable timeframe. Veeam ONE includes dedicated HA cluster alarms for this. The Veeam Backup and Replication HA cluster primary node state alarm can be configured to trigger automated failover when the primary becomes unavailable - meaning Veeam ONE can initiate failover without manual intervention. If you have Veeam ONE and are deploying HA, configure that alarm and its automated action before you need it.

Without automated failover, trigger it manually: connect the console to the cluster endpoint (it connects to whichever node is reachable), 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. Veeam detects it, resyncs its configuration from the current primary, and places it in standby. You do not need to rebuild the cluster from scratch after a failover.