WZ-IT unterstützt Sie mit dem passenden Angebot: Proxmox-Setup.
Die integrierte Proxmox Storage Replication überträgt Gast-Volumes zwischen Cluster-Nodes anhand von ZFS-Snapshots. Nach einem ersten vollständigen Abgleich werden nur Änderungen übertragen. Die Replikation ist asynchron: Änderungen seit dem letzten erfolgreichen Lauf können beim Ausfall fehlen (Herstellerhandbuch). Dieser Artikel zeigt Voraussetzungen, Einrichtung per Weboberfläche und pvesr, Betrieb und Fehlerbehandlung sowie die Grenzen gegenüber Backup, HA und pve-zsync. Stand: Oktober 2026.
Inhaltsverzeichnis
- 1. Voraussetzungen und Speicher prüfen
- 2. Replikationsjob anlegen
- 3. Betrieb, Abnahme und Störungen
- Ausfall und Migration
- pvesr und pve-zsync abgrenzen
1. Voraussetzungen und Speicher prüfen
Die integrierte Replikation arbeitet mit lokalem ZFS-Storage (zfspool). Der ZFS-Pool muss auf Quell- und Zielnode vorhanden sein und denselben Namen tragen, die Storage-ID muss am Ziel verfügbar sein. Außerdem braucht der Cluster Quorum und ausreichend Kapazität am Ziel.
pvesm status # Storage-IDs, Typ und Füllstand je Node
zpool list # ZFS-Pools des Nodes; Name auf beiden Nodes vergleichen
zfs list -r rpool/data # Datasets der Gast-Volumes (Pool-Name anpassen)
Erfassen Sie alle Gastdisks und prüfen Sie, welche tatsächlich repliziert werden. Ein nicht repliziertes zusätzliches Volume kann den Wiederanlauf auf dem Zielnode verhindern. Die Storage-Grundlagen erklären die Abgrenzung zu Ceph und LVM; die Zwei-Node-Anleitung behandelt das Quorum gesondert.
2. Replikationsjob anlegen
In der Weboberfläche wählen Sie beim Gast „Replikation“, legen Zielnode und Zeitplan fest und begrenzen bei Bedarf die Übertragungsrate. Auf der Kommandozeile dient pvesr create-local-job. Die Job-ID besteht aus Gast-ID und Jobnummer, die Nummer ist je Gast zu vergeben:
# VM 100, Job 0, Zielnode pve-target, alle 15 Minuten, auf 20 MB/s begrenzt
pvesr create-local-job 100-0 pve-target --schedule "*/15" --rate 20 --comment "VM 100 nach pve-target"
pvesr status
Der Zeitplan nutzt eine Untermenge der systemd-Kalenderereignisse; das kleinste Intervall ist eine Minute, das größte eine Woche. Beispiele:
| Zeitplan | Bedeutung |
|---|---|
*/15 |
alle 15 Minuten (Standard) |
*/5 |
alle 5 Minuten |
22:00 |
täglich um 22:00 Uhr |
mon..fri 22:00 |
werktags um 22:00 Uhr |
--rate begrenzt die Übertragung in MB/s, damit Replikation weder Storage noch Netzwerk überlastet. Ein Gast kann auf mehrere Zielnodes repliziert werden, aber nicht zweimal auf denselben. Der erste Lauf überträgt alle Daten; legen Sie ihn deshalb auf einen abgestimmten Zeitpunkt und beachten Sie das Netzwerk (Netzwerkplanung).
3. Betrieb, Abnahme und Störungen
Mit diesen Befehlen prüfen und steuern Sie die Jobs:
pvesr list # konfigurierte Jobs
pvesr status # letzter Lauf, Dauer, Fehlerzähler, nächster Lauf
pvesr schedule-now 100-0 # Job sofort einplanen
pvesr update 100-0 --schedule "*/5" # Zeitplan ändern
pvesr disable 100-0 # Job pausieren, mit enable wieder aktivieren
pvesr delete 100-0 # Job entfernen
Die Konfiguration liegt cluster-weit in /etc/pve/replication.cfg. Prüfen Sie nicht nur, dass der Job existiert, sondern das Alter des letzten erfolgreichen Laufs in pvesr status und das Protokoll des Jobs.
Fehlerbehandlung: Trifft ein Job auf ein Problem, geht er in den Fehlerzustand. Dann ruht der konfigurierte Zeitplan vorübergehend, und die Replikation wird im 30-Minuten-Takt erneut versucht. Nach einem Erfolg gilt wieder der ursprüngliche Zeitplan. Typische Ursachen:
- Zielpool voll oder nicht erreichbar, Netzwerkausfall zwischen den Nodes
- Storage-ID oder Pool-Name am Ziel fehlt oder weicht ab
- Snapshots oder Datasets auf dem Ziel wurden außerhalb der Replikation verändert oder gelöscht
- Nicht replizierbare Volumes am Gast, etwa auf anderem Storage-Typ
Als Abnahmekriterien halten Sie fest: Zeit seit dem letzten erfolgreichen Sync, Gastdisk-Abdeckung, freien Zielspeicher, Alarmierung bei ausbleibendem Sync und den geplanten Migrationsweg. Das Management-Netz sollte nicht durch Replikation belastet werden.
Ausfall und Migration
Wird ein Gast auf einen Node migriert, auf den er bereits repliziert wird, überträgt Proxmox nur die Änderungen seit dem letzten Sync. Das verkürzt die Migration deutlich.
Fällt der Quellnode aus, liegen die Gastdaten auf dem Zielnode, aber nur bis zum Stand des letzten erfolgreichen Syncs. Ohne HA starten Sie den Gast manuell: Die Gastkonfiguration muss vom ausgefallenen Node zum Zielnode verschoben werden (/etc/pve/nodes/<ausgefallen>/qemu-server/<vmid>.conf nach /etc/pve/nodes/<ziel>/qemu-server/, bei Containern lxc), bevor der Gast dort startet. Das geht nur bei bestehendem Quorum. Starten Sie niemals denselben Gast unabhängig auf beiden Seiten.
Replikation allein richtet keine HA-Ressource ein. Ein automatischer Ausfallweg braucht HA, Quorum und Fencing und ist getrennt zu planen; für Betreuung von Jobs und Störungen führt der Weg zu Managed Proxmox.
pvesr und pve-zsync abgrenzen
pvesr ist die integrierte Cluster-Replikation mit Jobs in /etc/pve/replication.cfg und GUI-Anbindung. Das separate Werkzeug pve-zsync synchronisiert ZFS-Daten mit eigenen Jobs und Betriebsbedingungen, auch auf Hosts außerhalb des Clusters. Behandeln Sie es nicht als austauschbaren Namen für die GUI-Replikation und kombinieren Sie beide nicht ungeprüft auf denselben Datasets.
Beide Wege brauchen ein eigenständiges Backup-Konzept: Replikation hält nur den letzten Stand vor und ersetzt keine aufbewahrten Datenstände. Für historische Sicherungen und Wiederherstellung siehe PBS Offsite-Backup. Für den Aufbau bietet WZ-IT Proxmox-Setup.
Weiterlesen
- Proxmox Storage: ZFS, Ceph & LVM - welches Dateisystem?
- Proxmox 2-Node-Cluster mit QDevice: Quorum ohne dritten Node
Zum passenden Angebot: Proxmox-Setup.
