Veeam Backup & Replication v13 – Proxmox VE Cluster mit lokalen Workern hinzufügen

Ich hatte vor kurzem den Fall, dass ein Proxmox VE Cluster in Veeam Backup & Replication v13 eingebunden werden sollte. Zwischen dem Veeam Backup Server und den Proxmox Hosts befand sich eine Firewall, wodurch nicht direkt jede Verbindung möglich war.

Das eigentliche Hinzufügen der Proxmox Hosts ist nicht sonderlich kompliziert, allerdings gibt es ein paar Punkte, die man beachten sollte. Besonders die Worker-VMs, die Veeam für Proxmox nutzt, benötigen eigene Kommunikationswege. Wenn hier ein Port oder die Namensauflösung fehlt, sieht der Fehler auf den ersten Blick nicht immer eindeutig aus.

Ausgangslage

In diesem Beispiel gibt es einen Proxmox VE Cluster mit drei Hosts. Jeder Host nutzt lokalen Storage, also keinen zentralen Shared Storage.

Die Umgebung sieht vereinfacht so aus:

Veeam Backup Server:
backup01.example.local
10.10.10.20

Veeam Repository:
repo01.example.local
10.10.30.20

Proxmox VE Cluster:
pvecluster01

Proxmox Hosts:
hvhost01    10.10.20.11
hvhost02    10.10.20.12
hvhost03    10.10.20.13

Worker-Netz:
10.10.40.0/24

Veeam Worker:
veeam-worker-hvhost01    10.10.40.101
veeam-worker-hvhost02    10.10.40.102
veeam-worker-hvhost03    10.10.40.103

Der Veeam Backup Server läuft in diesem Beispiel auf einem Windows Server. Die Proxmox Hosts sind bereits als Cluster eingerichtet und produktiv im Einsatz.

Proxmox Cluster in Veeam hinzufügen

Wichtig ist, dass der Proxmox Cluster in Veeam nicht als ein einziges zentrales Cluster-Objekt hinzugefügt wird. Stattdessen werden die einzelnen Proxmox Hosts hinzugefügt.

In diesem Beispiel also:

10.10.20.11
10.10.20.12
10.10.20.13

Alternativ kann natürlich auch mit DNS-Namen gearbeitet werden. Wichtig ist nur, dass diese Namen auch von den Worker-VMs sauber aufgelöst werden können. In dieser Umgebung wurde bewusst mit IP-Adressen gearbeitet, da das Worker-Netz zu diesem Zeitpunkt noch keine passende DNS-Auflösung für die Proxmox Hostnamen hatte.

Lokale Worker pro Proxmox Host

Veeam empfiehlt bei Proxmox die Verwendung von Worker-VMs. Diese Worker übernehmen die eigentliche Kommunikation und Datenverarbeitung für Backup- und Restore-Vorgänge.

Bei einem Cluster mit lokalem Storage ist es sinnvoll, auf jedem Proxmox Host einen lokalen Worker zu deployen.

In diesem Beispiel:

hvhost01 -> veeam-worker-hvhost01
hvhost02 -> veeam-worker-hvhost02
hvhost03 -> veeam-worker-hvhost03

Damit sitzt der Worker möglichst nah an den VM-Daten. Gerade bei lokalem Storage möchte man vermeiden, dass unnötig Daten quer über andere Proxmox Hosts oder Management-Netze laufen.

Benötigte Firewall-Freigaben

Da zwischen Veeam, Proxmox und den Workern eine Firewall vorhanden war, mussten die Verbindungen gezielt freigegeben werden.

Die wichtigsten Ports in diesem Aufbau waren:

Veeam Backup Server -> Proxmox Hosts:
TCP 8006
TCP 22

Veeam Backup Server -> Worker-VMs:
TCP 19000
TCP 443

Worker-VMs -> Veeam Backup Server:
TCP 10006
TCP 2500-3300

Worker-VMs -> Proxmox Hosts:
TCP 8006
TCP 22

Worker-VMs -> Repository / Gateway:
TCP 6162
TCP 2500-3300

Worker-VMs -> NTP:
UDP 123

Der Port 8006 ist dabei die Proxmox API, Port 22 wird für SSH genutzt. Die Worker brauchen zusätzlich die Verbindung zum Veeam Backup Server und zum Repository.

Problem 1: Worker-Core-Service nicht erreichbar

Nach dem Deployment der ersten Worker-VM wurde diese sauber erstellt, gestartet und hat beim ersten Start auch Updates installiert. Danach blieb der Test in Veeam allerdings bei folgendem Punkt hängen:

In progress : Connecting to the worker core service
Failed : Failed to connect to the worker core service: Assertion failed: Vbr platform is already registered

Die Meldung wirkte zuerst so, als wäre innerhalb der Worker-VM oder bei der Registrierung etwas nicht korrekt. In diesem Fall war die Ursache aber deutlich einfacher: Der Port TCP 10006 vom Worker zum Veeam Backup Server fehlte in der Firewall.

Nach der Freigabe von

Worker-VM -> Veeam Backup Server: TCP 10006

konnte die Verbindung zum Worker-Core-Service erfolgreich hergestellt werden.

Weitere Informationen zu den Firewall-Ports und notwendigen Freigaben gibt es in der Veeam Knowledgebase:
https://helpcenter.veeam.com/docs/vbr/userguide/used_ports.html?ver=13

Problem 2: Verbindung vom Worker zum Proxmox Host schlägt fehl

Im nächsten Schritt hing der Test bei der Verbindung zwischen Worker und Proxmox Host:

In progress : Testing connection between the worker and cluster hvhost01

Im Log waren Verbindungsversuche auf den Namen des Proxmox Hosts und den Port 8006 zu sehen. Die Verbindung per IP-Adresse funktionierte, die Verbindung per Name allerdings nicht.

Das Problem war in diesem Fall also nicht der Port, sondern die Namensauflösung.

Der Worker versuchte den Namen

hvhost01

aufzulösen. Da im Worker-Netz aber zu diesem Zeitpunkt kein passender DNS-Eintrag vorhanden war, schlug der Test fehl.

Zum Test wurde die Verbindung per IP-Adresse geprüft:

timeout 5 bash -c '</dev/tcp/10.10.20.11/8006>' && echo OK || echo FAIL

Das funktionierte erfolgreich.

Lösung: Proxmox Hosts per IP-Adresse einbinden

Da die Namensauflösung im Worker-Netz nicht direkt umgesetzt werden sollte, wurden die Proxmox Hosts in Veeam per IP-Adresse hinzugefügt.

Also nicht:

hvhost01
hvhost02
hvhost03

sondern:

10.10.20.11
10.10.20.12
10.10.20.13

Danach konnten alle drei Hosts hinzugefügt und alle drei Worker erfolgreich getestet werden.

Wichtig ist dabei, die Einbindung konsistent zu halten. Man sollte also nicht denselben Proxmox Host einmal per IP-Adresse und einmal per DNS-Name hinzufügen.

VLAN für die Worker-VMs

Beim Deployment der Worker-VM gab es in Veeam keine offensichtliche Option, direkt ein VLAN-Tag für die vNIC der Worker-VM zu setzen.

Wenn die Worker in einem VLAN laufen sollen, gibt es zwei Möglichkeiten:

Möglichkeit 1: VLAN direkt an der VM in Proxmox setzen

Nach dem Deployment der Worker-VM kann das VLAN-Tag direkt in Proxmox gesetzt werden.

Zum Beispiel per CLI:

qm config 1201

Danach die bestehende Netzwerkkarte mit VLAN-Tag anpassen:

qm set 1201 -net0 virtio=BC:24:11:AA:BB:01,bridge=vmbr0,tag=40

Wichtig ist, die vorhandene MAC-Adresse aus der VM-Konfiguration zu übernehmen.

Möglichkeit 2: Passende Bridge verwenden

Alternativ kann eine Proxmox Bridge genutzt werden, die bereits im gewünschten Netzwerk bzw. VLAN liegt. Dann muss kein VLAN-Tag an der VM selbst gesetzt werden.

Welche Variante besser ist, hängt von der vorhandenen Proxmox Netzwerk-Konfiguration ab.

Erfolgreicher Endstand

Am Ende sah der Stand so aus:

hvhost01 wurde in Veeam per IP 10.10.20.11 hinzugefügt
hvhost02 wurde in Veeam per IP 10.10.20.12 hinzugefügt
hvhost03 wurde in Veeam per IP 10.10.20.13 hinzugefügt

veeam-worker-hvhost01 wurde auf hvhost01 deployed
veeam-worker-hvhost02 wurde auf hvhost02 deployed
veeam-worker-hvhost03 wurde auf hvhost03 deployed

Alle Worker wurden erfolgreich getestet

Damit war die Grundintegration abgeschlossen.

Kurzer Test nach der Einrichtung

Nach der erfolgreichen Einrichtung sollte man nicht direkt davon ausgehen, dass alles produktiv sauber läuft. Sinnvoll ist ein kleiner Test mit einer unkritischen VM.

Zum Beispiel:

1. Test-Backup einer kleinen VM auf hvhost01 erstellen
2. Restore Point prüfen
3. VM auf hvhost02 migrieren
4. Proxmox Hosts in Veeam rescanen
5. Backup-Job erneut starten
6. Optional File-Level Restore oder Instant Recovery testen

Gerade bei lokalen Storages und Migrationen ist es sinnvoll zu prüfen, ob Veeam die VM nach der Migration weiterhin korrekt findet.

Fazit

Die Proxmox-Integration in Veeam Backup & Replication v13 funktioniert grundsätzlich sauber, wenn die Kommunikationswege passen.

Wichtig sind vor allem diese Punkte:

Alle Proxmox Hosts einzeln in Veeam hinzufügen
Bei lokalem Storage pro Host einen lokalen Worker nutzen
Firewall-Freigaben nicht nur für den Veeam Server, sondern auch für die Worker einrichten
Port TCP 10006 vom Worker zum Veeam Server nicht vergessen
Worker müssen die Proxmox Hosts per Port 8006 und 22 erreichen
Namensauflösung beachten oder konsequent mit IP-Adressen arbeiten
VLAN der Worker-VMs ggf. direkt in Proxmox setzen

In meinem Fall war am Ende nicht Veeam selbst das Problem, sondern eine Kombination aus fehlendem Firewall-Port und nicht vorhandener Namensauflösung aus dem Worker-Netz.

Nachdem die Hosts per IP-Adresse eingebunden und die fehlenden Ports freigegeben waren, konnten alle drei Proxmox Hosts und alle drei Worker erfolgreich eingerichtet werden.

Disclaimer

Dieser Artikel wurde mit Unterstützung von dieser KI gemacht, von der gerade alle reden und die den RAM so teuer macht…