Zwei Standorte, ein Proxmox-Cluster — und die Frage: Wie überleben wir, wenn ein Standort komplett ausfällt? Die naheliegende Antwort heißt Proxmox Replication über pvesr. Damit lassen sich VMs auf einem ZFS-Pool an einem Standort in regelmäßigen Abständen auf den ZFS-Pool des anderen Standorts spiegeln. Das ist kein synchroner Storage, kein automatisches HA, kein Ersatz für Backups — aber es ist eine erstaunlich pragmatische Disaster-Recovery-Strategie, wenn man die Grenzen kennt.

Dieser Artikel zeigt, wie das konkret funktioniert, was zu beachten ist und wie es sich von verwandten Konzepten abgrenzt.

Was Proxmox-Replication ist — und was nicht

pvesr (Proxmox VE Storage Replication) ist eine Funktion, die auf ZFS-Snapshots und ZFS-Send/Receive aufbaut. Eine VM, deren Disks auf einem ZFS-Pool liegen, wird inkrementell auf einen zweiten Proxmox-Node mit eigenem ZFS-Pool repliziert.

Was es ist:

Asynchrone Replikation auf Block-Ebene (ZFS-Snapshot → Send → Apply)
Inkrementell nach dem initialen Voll-Sync
Konfigurierbar pro VM und pro Frequenz (1 Minute bis stündlich/täglich)
In das Proxmox-UI integriert, kein extra Toolset nötig
Funktioniert in Cluster und auch zwischen unabhängigen Nodes (Cluster-Linkage stark empfohlen)

Was es nicht ist:

Kein synchroner Storage: zwischen zwei Replikationen liegen mindestens 1 Minute (Best Case) — Datenverlust bei Failover ist möglich
Kein automatisches Failover: Wenn der Primär-Standort ausfällt, müssen Sie manuell auf den Sekundär switchen
Kein Backup-Ersatz: Eine versehentlich gelöschte Datei in der VM wird in der nächsten Replikation mitgelöscht — Sie brauchen weiterhin den Proxmox Backup Server
Kein HA-Cluster: Ein klassischer HA-Cluster braucht Shared Storage (Ceph, NFS, iSCSI) im gleichen Subnet — pvesr ist dafür gerade nicht gedacht

Wann ist Replication das richtige Werkzeug?

Konkrete Szenarien aus DATAZONE-Projekten:

Szenario A: Hauptbüro + Außenstandort mit Backup-Funktion

Eine GmbH mit 80 MA hat das Hauptbüro in Stadt A, der Geschäftsführer wohnt 30 km entfernt mit kleinem Büro. Im Hauptbüro stehen 3 Proxmox-Nodes, im Außenbüro 1 Proxmox-Node. Die wichtigsten 5 VMs (AD, Mailserver, ERP-Frontend, File-Server, Webserver) werden alle 15 Minuten zum Außenstandort repliziert. Bei einem Brand im Hauptbüro kann der Geschäftsführer mit überschaubarem Datenverlust die Geschäftsfähigkeit aufrechterhalten.

Szenario B: Hot-Cold-DR mit zweitem Rack im Ausweich-Standort

Mittelständler mit eigenem Mini-Rechenzentrum baut ein zweites Rack im 5 km entfernten Lagerstandort auf — verbunden über WireGuard und 1 Gbit/s. Replikation aller produktiven VMs alle 30 Minuten. Im Ernstfall wird manuell auf den Cold-Standort umgeschaltet; RPO 30 Minuten, RTO ca. 1 Stunde.

Szenario C: Mehrere kleine Filialen

Filial-Setup mit jeweils einer Proxmox-Box pro Filiale. Zentrale repliziert für jede Filiale ein “Hot-Standby”-VM-Set. Bei Hardware-Defekt in der Filiale wird die VM zentral hochgefahren und die User über VPN angebunden.

In allen drei Szenarien ist Replication nicht die einzige Komponente — sondern Teil einer DR-Strategie mit Backup, Dokumentation und Notfallplan.

Voraussetzungen

Bevor Sie pvesr einrichten, müssen einige Dinge gegeben sein:

ZFS-basierter Storage

Die VM muss auf einem ZFS-Pool liegen. Das gilt für beide Seiten. Storage-Typen, die funktionieren:

local-zfs (Default-ZFS-Pool auf der lokalen Platte)
Beliebiger ZFS-Pool, der als Proxmox-Storage konfiguriert ist

Storage, der nicht funktioniert (für pvesr): Ceph, LVM, iSCSI ohne ZFS, NFS, CIFS, Directory-Storage.

Netzwerk-Konnektivität

Port 22 (SSH) muss zwischen den Nodes offen sein — zfs send läuft über SSH
Idealerweise eine dedizierte Replikations-Schnittstelle (eigenes VLAN oder physisches Interface) — Replikation kann den Link sättigen
Bei standortübergreifender Replikation: WAN-Bandbreite mit Reserve einplanen. Eine 100-GB-VM beim initialen Sync braucht bei 100 Mbit/s mindestens 2 Stunden bei voller Last (und blockiert in der Zeit andere VMs auf dem Link)

Cluster oder Stand-alone?

pvesr funktioniert am besten innerhalb eines Proxmox-Clusters — die Authentifizierung und das Reporting laufen über Corosync. Zwei standalone Nodes können theoretisch auch repliziert werden, aber dann fehlen die UI-Statusanzeigen und der Failover wird umständlicher.

Empfehlung: Bauen Sie einen Cluster über beide Standorte. Bei nur zwei Standorten ist die Quorum-Frage zu beachten — entweder ein QDevice als drittes Cluster-Mitglied (kleine VM oder Raspberry Pi an einem dritten Ort), oder bewusster Verzicht auf Cluster-Funktionen jenseits der Replication.

Siehe auch Proxmox 3-Node-Cluster mit TrueNAS für Cluster-Grundlagen.

Konfiguration im UI

Der gerade Weg über das Proxmox-Web-UI:

Im Dropdown links eine VM auf einem ZFS-Pool auswählen
Reiter Replication öffnen
Add klicken
Target: Ziel-Node auswählen
Schedule: Wie oft? Cron-Format oder Vorlagen (*/15 = alle 15 Min, 0 */1 = stündlich, etc.)
Rate Limit (MB/s): WAN-Bandbreite einplanen — z.B. 50 MB/s, damit nicht der ganze Link blockiert ist
Comment: Beschreibung
OK

Der Job startet beim nächsten geplanten Zeitpunkt — oder Sie klicken Schedule now für den initialen Sync.

Konfiguration via CLI

Für Skripte und Automatisierung gibt es pvesr:

# Replikations-Job für VM 100 zum Node "node2" alle 15 Minuten
pvesr create-local-job 100-0 node2 --schedule "*/15"

# Mit Bandbreitenlimit (in KB/s, z.B. 50000 = 50 MB/s)
pvesr create-local-job 100-0 node2 --schedule "*/15" --rate 50000

# Status aller Replikations-Jobs
pvesr status

# Manuell triggern
pvesr run --id 100-0

# Job löschen
pvesr delete 100-0

Die Job-ID 100-0 steht für VM 100, Replikations-Job Nummer 0. Eine VM kann mehrere Replikations-Ziele haben (z.B. lokaler Sekundär-Node + Remote-Standort).

Initial-Sync: Der Knackpunkt bei großen VMs

Die erste Replikation ist ein Voll-Transfer — alle Daten der VM-Disks wandern über das Netzwerk. Bei einer 500-GB-VM und einem 100-Mbit/s-Standortverbindung dauert das im Idealfall ca. 11 Stunden — in der Praxis länger.

Drei Optionen, das zu beschleunigen:

Initial-Sync über externe Disk. ZFS-Snapshot der VM lokal exportieren auf eine USB-3-Disk, zum Sekundär-Standort fahren, dort importieren — und erst danach Replikation aktivieren. Die Replikation erkennt den bestehenden Snapshot und macht ab dort inkrementell weiter.
Initial-Sync innerhalb des Hauptbüros, dann Hardware-Umzug. Sekundär-Node im Haupt-LAN aufstellen, vollständig syncen, dann zum Sekundär-Standort transportieren. Bei kleinen Setups oft die schnellste Lösung.
Bandbreite kaufen oder über Nacht arbeiten. Wenn die Datenmenge im Verhältnis zur Bandbreite tragbar ist.

Praktischer Hinweis: Planen Sie das initiale Sync-Fenster realistisch. Erfahrungswert aus Projekten: Rechnen Sie den theoretischen Wert × 1,5 für Protokoll-Overhead, Wartezeiten, Throttling.

Inkrementelle Replikation: Realistische Bandbreiten

Nach dem initialen Sync werden nur noch Differenzen übertragen. Wie viel das ist, hängt vom VM-Profil ab:

Web-Server (statische Inhalte): wenige MB pro Replikationsintervall
Mailserver: Hunderte MB bis wenige GB pro Stunde
Datenbank-Server mit Schreiblast: GB-Bereich pro Stunde (oft sinnvoll: nicht die VM, sondern den DB-Logical-Replication-Stream nutzen)
Backup-VMs: ungeeignet — die replizieren ihrerseits ständig große Datenmengen

Faustregel: Bei der ersten Woche Produktivbetrieb genau hinschauen — wie groß ist das Inkrement? Reichen die 100 Mbit/s der Standortverbindung? Falls nicht, hilft entweder mehr Bandbreite, weniger häufige Replikation oder eine kleinere VM-Auswahl.

Snapshots und Retention

Proxmox-Replication legt für jeden Job einen Snapshot pro Replikationszyklus an. Das ist normal und gewollt — aber wer alle 15 Minuten repliziert und 30 Tage aufbewahrt, hat schnell 2.880 Snapshots auf der Quelle.

Standardmäßig hält pvesr nur zwei Snapshots pro Job (den letzten und den vorletzten). Das ist sinnvoll und sollte nicht ohne Grund verändert werden — Snapshot-Retention ist eine Aufgabe für Backup, nicht für Replication.

Failover: Manueller Schwenk

Im Disaster-Fall (Primär-Standort weg) gehen Sie wie folgt vor:

1. Quelle ist nicht mehr erreichbar

Annahme: Stromausfall, Internet-Ausfall oder Hardware-Tod am Primär-Standort.

2. Auf Sekundär-Node: VM aktivieren

# Auf dem Sekundär-Node:
qm rollback 100 __replicate_100-0_<timestamp>
# Den letzten erfolgreich replizierten Snapshot finden via:
zfs list -t snapshot -o name | grep <vmid>

Alternativ über das UI: VM in der Liste auswählen → Hardware → Disk → bei Bedarf der letzte Snapshot wird automatisch verwendet → VM starten.

3. Replikations-Job löschen

Der ursprüngliche Job zeigt zum nicht-erreichbaren Primär-Standort. Löschen Sie ihn und richten Sie einen inversen Job ein, sobald der Primär wieder online ist — diesmal vom Sekundär in Richtung Primär.

4. Wenn der Primär zurückkommt

Niemals beide VMs gleichzeitig starten — das wäre Split-Brain. Stattdessen:

Auf dem Primär: VM stoppen, nicht starten
Replikation invers einrichten (Sekundär → Primär)
Nach vollem Re-Sync: Stop auf Sekundär, Start auf Primär (oder dort weiterbetreiben)

Dieser Schwenk-Prozess sollte dokumentiert und geübt sein — ähnlich wie der Restore-Test (Backup-Test-Tag).

Abgrenzung zu Alternativen

vs. HA-Cluster mit Ceph

Ein klassischer HA-Cluster bedeutet: Shared Storage (Ceph, NFS, iSCSI), Live-Migration, automatisches Restart auf einem anderen Node. Voraussetzung: alle Nodes im gleichen Subnet, geringe Latenz (idealerweise < 1 ms zwischen Nodes), schnelle Storage-Anbindung.

Replication ist nicht HA. Wer “kein Datenverlust, automatisches Failover” braucht, braucht Ceph oder ein anderes Shared-Storage-Modell — siehe Proxmox High Availability Clustering und Ceph vs. ZFS.

vs. Stretched Cluster

Ein Stretched Cluster ist ein HA-Cluster über zwei Standorte mit synchroner Storage-Replikation. Das ist möglich mit Ceph, aber teuer (synchrone Replikation braucht extrem niedrige Latenz, oft eigenes Dark-Fiber zwischen Standorten) und in der Praxis für KMU-Budget meist überdimensioniert.

vs. Proxmox Backup Server (PBS)

PBS ist die richtige Antwort auf “Ich brauche Zeitversioneung und langfristige Aufbewahrung”. pvesr ersetzt PBS nicht. Beides parallel betreiben ist die richtige Architektur:

PBS: stündliche/tägliche Backups mit langer Retention (30/90/365 Tage)
pvesr: Echtzeit-Replikation (15 Min) für DR-Failover

vs. Cloud-DR (Azure Site Recovery, etc.)

Cloud-DR ist eine Alternative, wenn der zweite “Standort” gleich ein Cloud-Anbieter ist. Trade-off: laufende Kosten und Daten-Egress vs. eigene Hardware-Investition.

Praxis-Empfehlungen aus Projekten

Aus DATAZONE-Erfahrung:

Mit kleinen, weniger kritischen VMs starten. Probieren Sie die Replikation an einem Testsystem, bevor Sie den Mail-Server replizieren.
Bandbreitenlimit immer setzen. Ein VM-Snapshot ohne --rate kann den WAN-Link für 30 Minuten sättigen — und alle anderen Standort-Dienste blockieren.
Replication-Status monitoren. pvesr status zeigt Fehler, aber wer ein Monitoring-System (Grafana/Prometheus/Zabbix) hat, sollte den Replikationsstatus dort einhängen — siehe Grafana + Prometheus Stack.
Failover-Übungen halbjährlich. Einmal pro Halbjahr einen geplanten Schwenk auf den Sekundär-Standort durchspielen — inklusive Switch-Zurück.
Dokumentation pflegen. Welcher Schwenk-Prozess für welche VM? Wer hat im Notfall die Hoheit, die Entscheidung zu treffen? Ein “Runbook” gehört dazu.
Snapshot-Hygiene. Bei Migration einer VM oder beim Löschen alter Replikations-Jobs bleiben oft verwaiste Snapshots zurück. Regelmäßig zfs list -t snapshot checken.

Häufige Fehler

Replikation läuft, aber Sekundär ist nicht aktuell. Häufig: WAN-Link ist zu langsam für das Intervall. Lösung: längeres Intervall oder mehr Bandbreite.
Snapshots laufen voll. Bei kurzen Intervallen + Schreiblast wachsen die Snapshots auf der Quelle. Lösung: Größere Pool-Reserve.
VM startet auf Sekundär nicht. Hardware-Version oder Treiber-Unterschiede. Lösung: gleiche Proxmox-Version + ähnliche CPU/Netzwerk-Setup auf beiden Seiten.
Replikation hängt nach Reboot. SSH-Schlüssel müssen zwischen Nodes ausgetauscht sein — wenn Sie nach einer Neuinstallation der Node-OS-Disk hier reagieren, ist Re-Trust nötig.

Fazit

Proxmox-Replication ist ein nüchternes, gut funktionierendes Werkzeug für asynchrone DR zwischen zwei Standorten. Es ist nicht HA, nicht synchron und kein Backup-Ersatz — aber innerhalb seines Spielfelds ist es robust und für KMU-Budgets erreichbar. Wer das verstanden hat, kann mit überschaubarem Hardware-Aufwand eine Standort-Resilienz aufbauen, die noch vor wenigen Jahren Enterprise-Lizenzen erforderte.

Wir bei DATAZONE setzen pvesr regelmäßig in Kunden-Projekten ein — meist in Kombination mit Proxmox Backup Server und einem dokumentierten Schwenk-Prozess. Wenn Sie eine solche DR-Strategie planen, helfen wir gern bei Architektur und Schwenk-Übung.

Proxmox Replication zwischen zwei Standorten