best practice: ZFS, Datasets zwischen Pools synchron halten

pit234a

Well-Known Member
Hi.

Bisher habe ich den weiteren Möglichkeiten von ZFS keine große Beachtung geschenkt. Naja, da gibt es was Neues, wofür ich aber schon lange eine funktionierende Lösung habe, also ok, was solls...
Durch einige Teilnehmer hier angeregt, habe ich mir nun als zusätzliches Backup-Medium eine externe Festplatte gekauft und dort auch ein ZFS drauf gelegt. Eher mal zum Testen habe ich dann geschafft, einen snapshot auf meinem PC zu erstellen, ihn zu einem gewünschten Dataset auf der externen Platte zu kopieren, dann dort zu clonen und damit habe ich nun überraschend einfach eine Kopie des ursprünglichen Datasets von meinem PC. Das hat mir gut gefallen.

Aber, wenn ich dort nun in Zukunft diesen neu gewonnen Klon synchron halten will, dann ist mir nicht ganz klar, wie das geht oder wie man das am einfachsten macht.
Dass ich snapshots incrementell senden kann, habe ich erfasst. Aber, die bewirken ja zunächst gar nichts auf dem Klon. Muss ich dann jeweils einen neueren snapshot senden, "zurückrollen" (eigentlich wäre das ja ein vorwärtsrollen in Bezug auf den Klon) oder wieder clonen? Oder kann ich direkt auf den Klon einwirken, als wenn ich rsync laufen lassen würde.

Und überhaupt, wie macht ihr denn das am liebsten?
Nutzt ihr generell Mechanismen aus ZFS um externe Backups zu erstellen und zu pflegen? Oder lieber rsync oder ähnliches.
Begnügt ihr euch evtl mit den (kopierten) snapshots?

Es wäre mir sehr lieb, konkrete Befehle mit ZFS in euren Antworten zu lesen, aber am liebsten auch mit etwas Kommentar, was denn warum überhaupt gemacht wird.
 
Ich hab das mit den inkrementellen Snapshots nie so ganz auf die Reihe bekommen und fahre einfach ganze Backups.
Heißt snapshot erstellen, durch pigz (parallel gzip) jagen, auf eine seperate Platte schreiben, snapshot löschen und auf der seperaten Platte aufräumen (nur die letzten vier Snapshots behalte ich).
Code:
NOW=`date +%Y%m%d` && FS='tank/datastore2' && zfs snapshot ${FS}@$NOW && zfs send ${FS}@$NOW | pigz > /media/backup/datastore2_$NOW.gz && zfs destroy ${FS}@$NOW
 
Danke schon mal für die Antwort.

Bringt es denn wirklich noch etwas, die snapshots zu zippen? Ich habe ja schon lz4-Compression auf meinen Pools aktiviert (also, seit es das in ZFS gab).
 
Kommt darauf an wie man die Snapshots archivieren möchte und ob man damit einen Platzgewinn erreichen mag. Wenn man mit Replikation arbeitet, hat zfs bislang etwaige Datasets dekomprimiert, nur um sie am Ziel wieder ggf. komprimieren zu müssen. Die einzige Quelle wo ich flugs etwas dazu finden konnte war https://www.socallinuxexpo.org/sites/default/files/presentations/zfs-send-and-receive.pdf - Denn man wollte das Feature einbauen dass bereits komprimierte Snapshotdaten 1:1 übertragen werden, wenn das Ziel gleichermaßen komprimiert ist. So würde man die CPU deutlich entlasten.
 
Ich hab keine Compression aktiv und die Daten auf dem Volume sind VM Disks. Eigentlich mit thin provisioning, aber bei einem Snapshot + wegspeichern belegt der die volle Größe (986G vs.234G).
 
uff.
Habe gerade einen ziemlichen Schreck überstanden, als ich nämlich wegen anderer Spielereien meinen Rechner neu startete und dabei plötzlich keine Daten mehr in /usr/home waren. Das Dataset war noch vorhanden und es war auch eine gute Anzahl an Bytes belegt angezeigt, nur eben keine Daten mehr drin.
Vor dem Neustart hatte ich nochmal "aufgeräumt" und meine testweise erstellten snapshots gelöscht, also auch jene vom /usr/home.
Nach diesem Schock hatte ich erst mal die Schnauze voll und stellte meine Daten nach alter Väter Sitte mit rsync wieder her.
Ziemlich froh, dass das auf Anhieb gut geklappt hat.

Das muss ich mir überlegen, ob ich da in Zukunft mit den Werkzeugen von ZFS weiter arbeiten möchte. Es scheint mir zwar einige Vorteile zu haben, aber scheinbar muss man sich an den Umgang doch erst gewöhnen, obwohl er auf Anhieb total einfach erscheint.
 
oje.
Ich weiß nun nicht, was ich da vermurxt hatte, aber der Fehler war nicht etwa, dass meine Daten verschwunden waren, sondern, dass nahezu alle Datasets meines zroot Pools nicht mehr gemountet wurden. Das merkt man gar nicht so ohne weiteres, vor allem, weil ich durch ein Script beim Booten in meinem ~./Desktop einige Dateien erzeuge und deshalb ein /usr/home/NAME existiert. Das System funktioniert auch problemlos und ich konnte /usr/home dann mit Daten aus meiner Sicherung füllen. Erst, nachdem ich genauer hingesehen hatte, ist mir das alles aufgefallen.
Nun konnte ich das alles wieder herstellen und reparieren (außer der Dataset für /var, der nicht mehr wollte aber vielleicht schon früher versagt hatte, denn auch da ist alles dagewesen und so habe ich diesen Dataset zerstört). Das war insgesamt eine schöne Übung, aber sie hat mir auch wieder einige graue Haare wachsen lassen.

Übrigens war neben meinen Experimenten mit dem ZFS auch ein Upgrade auf neuere features angestanden, den ich zwischendurch mal durchgeführt hatte.
Ich kann nicht nachvollziehen, was ich falsch gemacht habe, aber vielleicht war es alles zusammen oder ein doofer Zufall oder doch ein unglücklicher und zunächst unbemerkter Befehl von mir gewesen.
Irgendwie aber schon geil, dass alles ohne Datenverlust über die Bühne ging.

Und ich glaube, ZFS-Snapshots will ich vielleicht doch nicht mehr missen.
 
Und die gute Mär von der Geschicht'
ZFS ersetzt ein Backup nicht. :D

Mit Snapshots werde ich mich auch bald befassen, dieser Thread ist für mich lehrreich.

Viele Grüße,
Holger
 
Zuletzt bearbeitet von einem Moderator:
Ich schiebe Snapshots immer mal wieder in einen zpool, der auf USB Sticks liegt - demnächst werde ich mal mehrere Sticks in einem raid-z probieren;-)
Für den privaten Bereich finde ich das ( klar, ist irgendwo Spielerei ) für mich ausreichend.

Was die Snapshots betrifft, so wird die Sache sehr vereinfacht - wenn man im Pool viele Datasets mit einer gut durchdachten Struktur angelegt hat.

Vor diesem Hintergrund sollte @Holger vielleicht auch noch mal in seinem Leitfaden für Einsteiger überlegen, ob die im zfs on Root gewählte Strategie mit deutlich weniger datasets als sie zB durch die automatische Installation bei der zfs Wahl erstellt werden - wirklich empfehlenswert ist

Grüße walter
 
pit234a, ich bin mir nicht sicher, ob ich Dein initiales Posting ganz richtig verstanden habe - ZFS kennt ja den Begriff der Clones, was schreibbare "Forks" von Snapshots sind, die ein eigenes Dataset mit impliziter Abhängigkeit vom Eltern-Objekt darstellen. Deckt sich das mit Deiner Verwendung des Begriffs Klon? Weil wenn ja, ist mir nicht klar, wozu Du das übertragene Dataset nochmal gecloned hast.

Unabhängig davon: Wenn man auf beiden Seiten ZFS hat, ist der Einsatz von rsync völlig obsolet, ja gar blasphemisch ;).

Ich sichere wichtige Datasets meines Fileservers in unregelmäßigen Abständen auf ein Remote-System, natürlich per Snapshots und zfs send | zfs receive. Der Fileserver selbst erstellt regelmäßige Snapshots mit zfSnap, die Remote-Sicherung läuft aber nur alle paar Wochen. Da mich für das Remote-Backup der ganze "Kleinkram" an dazwischenliegenden Änderungen nicht interessiert, erstelle ich eigene Snapshots und sende dann inkrementelle Snapshots mit -i (also nicht -I). Am Ziel empfange ich die Daten und lasse direkt ein Rollback auf die aktuelle Version machen mit -F. Dadurch synchronisieren sich die Datasets sehr einfach und komfortabel.

Beispiel per SSH:
Code:
src:$>  zfs send -i @oldsnap tank/dataset@newsnap | pv | ssh target zfs receive -F -d dozer/dataset

pv ist optional und dient nur der Fortschrittsanzeige, praktisch über Internet-Leitung. Das o.g. Beispiel lässt sich auch mit -R auf der Sendeseite ergänzen, dann werden auch Properties und Kind-Datasets übertragen.

Gruß
 
Was die Snapshots betrifft, so wird die Sache sehr vereinfacht - wenn man im Pool viele Datasets mit einer gut durchdachten Struktur angelegt hat.

Vor diesem Hintergrund sollte @Holger vielleicht auch noch mal in seinem Leitfaden für Einsteiger überlegen, ob die im zfs on Root gewählte Strategie mit deutlich weniger datasets als sie zB durch die automatische Installation bei der zfs Wahl erstellt werden - wirklich empfehlenswert ist

Hallo Walter,
sobald snapshots ins Spiel kommen, werde ich ganz sicher dieses Wenige-Datasets-pro-Pool-Konzept nochmal überlegen. Danke, sehr plausibel, Dein Hinweis.

Viele Grüße,
Holger
 
Vor diesem Hintergrund sollte @Holger vielleicht auch noch mal in seinem Leitfaden für Einsteiger überlegen, ob die im zfs on Root gewählte Strategie mit deutlich weniger datasets als sie zB durch die automatische Installation bei der zfs Wahl erstellt werden - wirklich empfehlenswert ist

Also ich "versende" Datasets immer rekursiv. Da ist es mir egal, um wieviele Datasets es sich handelt.
 
Mit Snapshots werde ich mich auch bald befassen
Strategie mit deutlich weniger datasets
Was ich gar nicht verstanden hatte und so auch nicht in den Dokumentationen zu lesen war (zumindest nicht für mich erkennbar), das ist das Verhalten der Snapshots, ihr Nutzen und wann sie sich "mit Daten füllen". Wenn ich etwa einen Snaphot erstelle, hat er quasi keine Daten und wenn ich ihn dann sende, dann füllt er sich usw. Außerdem glaube ich bemerkt zu haben, dass ein mv zwischen unterschiedlichen Datasets dann einen echten Bit-Transport bedeutete, wenn diese nicht zum gleichen Elternteil gehörten. Innerhalb einer Hierarchie scheint ein mv adhoc zu erfolgen, also ohne Datentransport und nur mit neuer Zuordnung. Das muss ich mir abernochmals ansehen, es ist mir nur retrospektiv aufgefallen. Sehr hilfreich ist auch gewesen, das snapdir auf visible zu stellen und dann mit einem Dateimanager zu browsen. Das muss man mal gesehen haben, dass man da Dateien einfach per Drag und Drop wieder herausnehmen kann. Dann versteht man auch, dass so ein snapshot eine Art Papierkorb ist und dass nur die Änderungen zum Erstellungszeitpunkt ihn auf seinem Dataset vergrößern, weil er nur diese Daten tatsächlich einpflegen muss, während alles andere nur Verwaltungseinträge sind.
Das ist mir ohne Spielerei und nur vom Lesen her so nicht eingegangen.
Wenn zwei das gleiche Lesen, verstehen sie nicht immer das Selbe.

Zur Strategie des Installers mit seinen vielen Datasets gehört natürlich auch die Vorstellung, wie und was man mit seinem System machen will. So gibt es da ja dann einen Dataset für /usr/ports und einen für /usr/src (und ich habe die beide auch noch) und das macht für mich keinen großen Sinn. Wenn ich die Ports verliere, hole ich sie mir neu und das gilt auch für die sourcen. Da brauche ich selbst keinen snapshot und muss nicht unbedingt wieder etwas herstellen. Das ist vermutlich für Bastler eine ganz andere Situation. Ich lege auch einige Dinge ins tempfs und schalte im laufenden System die Logs ab und so weiter. Es gibt also da sehr wohl individuelle Präferenzen, die gegenüber der Auswahl des Installers verschieden sein können. Deshalb ist es gut, wenn holgerw das in seiner Dokumentation auch zeigt und erwähnt.
 
Deckt sich das mit Deiner Verwendung des Begriffs Klon?
Ja, ich wollte ganz bewusst Begriffe verwenden, wie sie im Handbuch zu ZFS auch benutzt werden.
Der Snapshot, den ich in die Ferne gesendet hatte, lag zwar da herum, aber ich konnte damit gar nichts anfangen. Ich hatte keinen Zugriff auf die Daten und deshalb glaubte ich, dass ich unbedingt einen Klon haben möchte. Auch dies war ein relativ wichtiges Missverständnis von meiner Seite. Ich hatte auch erwartet, dass die zukünftigen Snapshots direkt auf diesen Klon wirken und nicht auf den ersten Snapshot.

All mein Unwissen war auch Grund für diesen Beitrag.
Ich meine, natürlich kann ich Befehle per copy_and_paste übernehmen, aber mir ist die Sache nicht geheuer, wenn ich nicht ein klein wenig verstehe, worum es geht und was passiert. Aus euren Beispielen wollte ich lernen und Verständnis gewinnen.
Es hat bislang schon sehr viel genützt. Vielen Dank.

ist der Einsatz von rsync völlig obsolet, ja gar blasphemisch
;) meinetwegen. Aber versteh mal, ich hatte ein Backup (genau gesehen hatte ich zwei) und die Möglichkeit, weiter mit ZFS zu spielen oder mein System mit Gewissheit wieder herzustellen. Die Entscheidung traf ich nicht sofort, ich überlegte schon, mit ZFS weiter zu machen, aber es ist mir doch sehr leicht gefallen, rsync zu nehmen.
Zu der Zeit hatte ich den Snapshot aus dem ich den Clon gemacht hatte auch schon gelöscht. Ich hätte also vom Klon einen erneuten Snapshot bauen und zurücksenden müssen, dann einen Rollback machen (edit: eher wieder einen Klon), wenn ich es recht verstehe. Der Aufwand mit rsync erschien mir deutlich einfacher.
Derzeit rsynce ich auch regelmäßig mein ~/ zu einem Fileserver und nutze nicht die Möglichkeiten von ZFS dazu. Das ist ein wenig Philosophie, ein wenig Tradition und ein wenig auch einfach praktisch. Ich sehe in rsync einige Vorteile, kann Dateien oder Verzeichnisse vom Sync ausnehmen und ich kann unsynchron fahren, im Empfänger alle Daten sammeln (also nicht die überzähligen Dateien löschen). Das kommt meiner Idee vom Langzeit-Datengrab-Archiv entgegen.
 
Ein Snapshot braucht soviel Speicherplatz wie die Differenz zum aktuellen Zustand oder nächsten Snapshot ausmacht. Es wird beim Snapshot der Zustand X gespeichert und anschließend notiert was sich danach verändert hat. Wenn du den Snapshot in eine Datei oder einen anderen Pool kopierst, muss du natürlich alle Daten übertragen. Die gemeinsam genutzten Daten werden immer dem aktuellem Filesystem angerechnet, daher wahrscheinlich die Verwirrung.
 
Zurück
Oben