[TUTORIAL] ZFS Snapshot Synchronisierung

Hallo,

habe mich die letzten Tage mit verschiedensten Replikations- / Synchronisierungswerkzeugen beschäftigt, um Snapshots der VMs zu erstellen:
- Zrep
siehe http://www.bolthole.com/solaris/zrep/zrep.documentation.html, das auch in der iX 2017 nach dem dreiteiligen ZFS Tutorial empfohlen wurde.
- PVE-zsync
siehe: https://pve.proxmox.com/wiki/PVE-zsync Proxmox eigenes Tool
- sanoid / syncoid
siehe: https://github.com/jimsalterjrs/sanoid
und die ZFS auto-scripte von ZFS-Rocks

Die funktionieren eigentlich alle zuverlässig, genau so wie sie sollen.
Jedoch sind mir zwei Dinge Wichtig: ich möchte die Synchronisierung NICHT als root laufen lassen, also muss das Tool auch unter einem andern user-Konto lauffähig sein, gerne mit ssh-Keys (das kleinere Problem). Außerdem möchte ich die ZFS Snapshots zweistufig aufbauen:
1: Lokal zB Snapshots auf dem lokalen System im 15min Takt mit individueller Aufhebefrist (stündlich, täglich, monatlich, und evtl. Jährlich)
2: UNABHÄNGIG von der lokalen Snapshoteinstellung möchte ich einmal nachts ein Snapshot über eine langsame Internetleitung (zB. 16.000KBit/s) auf ein zentralen Snapshot-Backup-Server übertragen.
2b: damit das Funktioniert, wäre es hilfreich, dass ich den ersten "Voll-Snapshot" zB per USB Festplatte übertragen könnte. Das scheint mir bei den getesteten Tools auch nicht möglich zu sein, weil sie zwingen eine Erstinitialisierung durchführen, bei der das Ziel leer sein muss.
EDIT: genau das geht doch mit obigem Zrep! Und das ist weiter unten zB Post Nr. 9 beschrieben.

Meine bisherige Erfahrung ist die, dass beim Replizieren bzw. Synchronisieren der Snaphots über das Netzwerk, keine wirkliche unabhängige Einstellung möglich ist:
entweder gibt es kaum bis gar keine individuelle Einstellung, wie bei PVE-zsync, oder -wie bei Zrep- es werden immer sämtliche lokalen Snapshots mit synchronisiert, auch wenn das Tool nur einmal die Nacht läuft, oder wie bei syncoid die Individuellen Einstellungen gelten immer auf beide Werkzeuge.
Ich kann zwar per cron bestimmen, wann über das Netzwerk Repliziert wird, ich kann aber diesen Job nicht völlig unabhängig von den lokalen Snapshots einer VM laufen lassen.

Sehr ungern würde ich Tools wie ZnapZend oder pyznap selbst kompilieren, wo doch mein Motto lautet, auf dem Proxmox System selbst so wenig wie möglich zu "fummeln". Daher habe ich diese beiden bisher nicht ausprobiert.
Hat da jemand ein Vorschlag für mich?
 
Last edited:

dlimbeck

Proxmox Staff Member
Staff member
Aug 1, 2018
137
9
18
pve-zsync in der aktuellsten Version erlaubt es --source-user und --dest-user anzugeben, und es sollte auch funktionieren sofern alle notwendigen Rechte vorhanden sind (auch um ZFS Datasets anzulegen). Wobei der cron job zumindest als "root" ausgeführt wird, wenn ein automatisches synchronisieren erwünscht ist (pve-zsync create)
 
Hallo dlimbeck
das war ja ne schnelle Antwort!
Ja, PVE-zsync wäre mir auch am sympatischsten, weil am nähestens am Proxmox - klar.
ABER: gibt es es irgendwie ein Trick, vielleicht durch mehrere verschiedene Cronjobs oder dergleichen, um eine nicht lineare Aufhebezeit hin zu bekommen EDIT: (zB: täglich= 8 , monatlich = 12)?
Grüße,
maxprox
 
Last edited:

dlimbeck

Proxmox Staff Member
Staff member
Aug 1, 2018
137
9
18
Es müsste gehen mit pve-zsync sync es manuell zu starten statt über einen cron job.
 
So gern ich pve-zsync verwenden würde, denke ich doch, dass es mit dem jetzigen Funktionsumfang für mich nicht wirklich brauchbar ist,
ich sehe zZ keine Möglichkeit,
->1: die erste (Initial- bzw. Voll-) Übertragung über zB eine externe Festplatte zu realisieren, weil ich zZ keine 100 oder 200 GB über die Internetleitung bekomme
->2: um lokal und remote unterschiedliche, zB lokal gar keine pve-zsync Snapshots vorhalten zu müssen. Genauer: pve-zsync erstellt immer zuerst einen lokalen Snapshot, der dann repliziert wird. Lokal und remote liegt immer 1:1 der gleiche Snapshot Zustand vor. Da ich aber Lokal zusätzlich und unabhängig von pve-zsync deutlich mehr und öfter Snapshot erstellen möchte, würde ich lokal den (mindestens) DOPPELTEN Snapshot Speicher benötigen. Ich habe dann unnötigerweise die Snapshots doppelt auf dem Proxmox Server. Bei Zrep zB wächst nur der remote Speicher, also der auf der Backupmaschine an, auf dem lokalen Proxmox verbleiben bei Zrep gar keine Snapshots.
->3: Ich sehe zZ keine Möglichkeit für die automatische nicht lineare Aufhebezeit (zB: täglich= 8 , monatlich = 12)?

Grüße,
maxprox
 
Jetzt bin ich wieder einen Schritt weiter.
Zur Zeit stellt es sich so dar, dass zZ die Beste Kombi für lokal + remote replizierte Snapshots folgende ist:

Für lokal: SANOID https://github.com/jimsalterjrs/sanoid
lässt sich IMHO sehr einfach, übersichtlich und nachvollziehbar per /etc/*.conf Datei individuell und feingliedrig einstellen

Für die remote Replikation:
http://www.bolthole.com/solaris/zrep/zrep.documentation.html
https://github.com/olevole/zrep

Erst nach weitere Recherchen habe ich raus gefunden, dass sich (fast ) alle gewünschten Punkte mit obiger Kombi umsetzen lassen:

zrep setzt und liest individuelle zfs dataset parameter aus, die entsprechend manuell geändert werden können:

Code:
zfs get all rpool/data/vm-207-disk-1
...
rpool/data/vm-207-disk-1  zrep:src-fs           rpool/data/vm-207-disk-1  local
rpool/data/vm-207-disk-1  zrep:dest-host        192.168.8.100              local
rpool/data/vm-207-disk-1  zrep:src-host         fcprox                    local
rpool/data/vm-207-disk-1  zrep:dest-fs          r5pool/snap_test/win7lex  local
rpool/data/vm-207-disk-1  zrep:savecount        5                         local
Somit hat man doch, anders als ich zunächst gedacht hatte, erweiterte Einstellungsmöglichkeiten.
Der erste initiale Sync, der "Voll-Sync" kann auf einen bereits übertragenen Snapshot los gelassen werden, nachdem dieser per zB USB mit Standard zfs snapshot Befehlen übertragen wurde. Siehe Doku unter "Pre-existing filesystem" und meine Anleitung ganz unten.
Jetzt muss ich nur noch die Probleme mit den Zugriffsrechte für "non-root" Zugriff lösen, siehe hier:
https://forum.proxmox.com/threads/zfs-snaphost-as-normal-user-permission-denied.48599/
 
Last edited:
Schon mal über znapzend nachgedacht? Kann nicht nur synchronisieren, sondern auch noch die Snapshot-Historie managen.
Gruß
Ralf
Hallo Ralf,
ja, habe ich. Zum einen hatte ich es erst entdeckt, als schon (zu) viel Zeit mit obigem Ausprobieren vergangen war und dann hatte mich gestört, dass es dafür kein Debian Repository gibt. Wahrscheinlich ist das zur Zeit sogar das "mächtigste" Snapshot Tool, kann das sein?
Ich will's auf jeden Fall noch mal irgendwann testen.
 
Last edited:
VMs als Snapshots sichern

EDIT vom 2019-02-09

In der ersten Anleitung hat zwar die Sicherung funktioniert, die bis dahin noch nicht getestete Wiederherstellung per
Code:
zfs rollback
funktionierte so jedoch NICHT.
Es gab einen gravierenden Syntaxfehler:
Damit Proxmox den Storage und die Volumes der VMs akzeptiert, MÜSSEN die Volumes zwingend mit der Bezeichnung vm-VMID im Namen beginnen. Das war in der bis Anfang Februar veröffentlichten Anleitung falsch. Allerdings nur für den remote Teil, also den Teil, der per zrep die Snapshots auf den "offline" Proxmox-Backup-Server übertragen hat. Es ist in den jetzt angehängten Dateien korrigiert.
Immer daran Denken: Ein Backup ist immer nur so gut, wie die Wiederherstellung funktioniert ;-)
=> siehe jetzt auch die folgende Beschreibung der Wiederherstellung ganz unten.

Es ist eher was für Einsteiger in das Thema "Auto-Snapshots".
Im Anhang einmal im DokuWiki Rohtext, einmal als PDF.
Ich habe das alles so durchgetestet, alles läuft seit Wochen produktiv automatisch...
Falls jemand Fehler findet oder Verbesserungsvorschläge hat.... gerne

Grüße,
maxprox
 

Attachments

Last edited:
  • Like
Reactions: tecnewb

tecnewb

New Member
Jan 18, 2019
2
0
1
27
Hi,

sozusagen als Dank an die hilfsbereiten Forums people habe ich mal mein recht ausführliches HowTo angehängt. Es ist eher was für Einsteiger in das Thema "Auto-Snapshots".
Im Anhang einmal im DokuWiki Rohtext, einmal als PDF.
Ich habe das alles so durchgetestet, alles läuft seit ein paar Tagen produktiv automatisch...
Falls jemand Fehler findet oder Verbesserungsvorschläge hat.... gerne

Grüße,
maxprox
Hey, sehr übersichtlich, danke dafür
Allerdings stelt sich mir die Frage, was sprach bei der Entscheidung gegen Syncoid? Wäre das nicht einfacher gegangen?
 
Hi,
wir suchten/brauchten eine Lösung, die lokal mindestens stündlich Snapshots erstellt und davon möglichst unabhängig einstellbar, maximal einmal nachts ein Snapshot remote im LAN oder über das Internet überträgt.
Bei unseren Versuchen übertrug dabei Syncoid sämtliche tagsüber erstellen Snapshots, das gefiel uns nicht.
Zrep hat sich auch jetzt im produktiven Einsatz für uns, als genau das Tool heraus gestellt, wonach wir gesucht hatten.
Daher die Kombi: lokal sanoid und für die remote/backup/offlineübertragung zrep
Inhaltlich wie beschrieben.
 
Dec 19, 2012
232
4
18
Hallo.
Ich hänge mich an diesen interessanten Thread an, da wir (in viel kleinerem Maßstab) etwas ähnliches planen.
Kurz zum derzeitigen Stand:
Server A: Produktiv (mit genug Power)
Server B: Backup-System (alter Server mit weit weniger Power)
beide mit Proxmox 5.3 und einem ZFS-Pool ausgestattet.

Die Idee war: pve-zsync (oder eine der hier genannten Alternativen) zu nutzen, um im Desaster Fall ganz schnell und ohne die relativ lange dauernde Wiederherstellung auf den Backup-Server wechseln zu können. Da wir keinen Cluster-Betrieb haben (und auch nicht benötigen), ist das offenbar die schnellste/einfachste Methode, wenn man etwas downtime in Kauf nehmen kann, oder?

Hast du bei deinen Backup-Servern das Restore einmal manuell angeworfen, um die configs usw an der richtigen Stelle zu haben? Danach sorgt das regelmäßig laufende pve-zsync dann dafür, dass sich die VM-HDDs immer im gleichen Zustand befinden, korrekt?
Schöne Grüße.
 
Hallo whiterabbit,
jow, super Idee und passt 1:1 zu einem Teilbereich unseren Plans.
Bei unseren bisherigen Versuchen kam für uns pve-zsync nicht in Frage, weil uns -wie oben beschrieben- wichtige Einstellungen u. Funktionen fehlten. Uns geht ebenfalls um Netzwerke, wo ein Cluster oversized wäre, trotzdem sollte die Wiederverfügbarkeit in max. wenigen Stunden definiert möglich sein.
Das Snapshot- Sicherungskonzept läuft wie gewünscht und im obigen PDF beschrieben.
Schritt für Schritt die Wiederverfügbarkeit durch den Backup-Server durchzuspielen und zu dokumentieren schaffe ich frühestens nächste Woche.
Hast du bei deinen Backup-Servern das Restore einmal manuell angeworfen, um die configs usw an der richtigen Stelle zu haben?
Das würden wir mit einem cronjob + rsync versuchen. Weißt du, was außer den configs noch zwingend vom Produktivserver 1:1 übertragen gehört?
Spätestens wenn wir das durchgespielt haben melde ich mich wieder. Dann folgt PDF Nr.2.

PS: ist whiterabbit eine Anspielung auf die ersten 15Minuten Matrix Teil 1 ?

Grüße,
maxprox
 
Last edited:
Dec 19, 2012
232
4
18
Hi.
eine Anspielung auf die ersten 15Minuten Matrix Teil 1 ?
Natürlich -- was sonst :)

Ich habe mir den ersten Teil deiner Anleitung gerade nochmal vorgenommen (PDF liegt hier fertig ausgedruckt). Sieht gut aus. Wenn es bei uns mit Bordmitteln klappt (also via pve-zsync) würde das auch so gehen.

Kannst du denn ungefähr sagen, wann du Teil II in Angriff nehmen wirst?
Ich hatte es bisher so verstanden, dass config usw direkt mit gesichert werden. Zumindest legt die Doku das ja nahe:
With the Proxmox VE ZFS replication manager (pve-zsync) you can synchronize your virtual machine (virtual disks and VM configuration) or directory stored on ZFS between two servers. By synchronizing, you have a full copy of your virtual machine on the second host and you can start your virtual machines on the second server (in case of data loss on the first server).
Daher hatte ich mich auch gewundert, dass die VM auf Server 2 nicht in der WebGUI auftauchte, als ich zum Testen eine VM per "pve-zsync sync..." aus dem ZFS-Pool von Server A in den ZFS-Pool nach Server B kopiert hatte...?!?
 
Last edited:
...
Ich habe mir den ersten Teil deiner Anleitung gerade nochmal vorgenommen (PDF liegt hier fertig ausgedruckt). Sieht gut aus. Wenn es bei uns mit Bordmitteln klappt (also via pve-zsync) würde das auch so gehen.

Daher hatte ich mich auch gewundert, dass die VM auf Server 2 nicht in der WebGUI auftauchte, als ich zum Testen eine VM per "pve-zsync sync..." aus dem ZFS-Pool von Server A in den ZFS-Pool nach Server B kopiert hatte...?!?...
Ich hatte es bisher so verstanden, dass config usw direkt mit gesichert werden. Zumindest legt die Doku das ja nahe:
ja, genua, pve-zsync sichert die VMID.conf mit und soll sie beim restore auch wieder zurück spielen, daher wäre auch für mich pve-zsync erste Wahl... Ich guck mir das in 'nem Jahr noch mal an.
Wenn pve-zsync die VMID.conf nicht wie gewünscht zurückspielt hmmm - keine Ahnung ich nutze das ja nicht.

Kannst du denn ungefähr sagen, wann du Teil II in Angriff nehmen wirst?
nächste Woche... ;-)
 
VMs aus Snapshots Wiederherstellen
Das war doch mehr Arbeit als gedacht, umso besser, das unbedingt VOR dem Ernstfall durchgetestet zu haben.
Zum Beispiel habe ich so erst bemerkt, dass ich meine selbstbenannten Volumes auf der Backup-Maschine für Proxmox unbrauchbar gemacht hatte. Proxmox erwartet zwingend einen Volume-Name beginnend mit:
vm-VMID, das hatte ich Anfangs falsch, weil ich das schlicht nicht wusste. Ist oben unter "EDIT vom 2019-02-09" genauer Beschrieben und in allen angehängten Turorial Dateien korrigiert.
Wen's interessiert, wie oben, die Wiederherstellung in Form von zfs rollback einmal als DokuWiki Rohtext, einmal als PDF.

regards
 

Attachments

Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!