Hallo,
ich benutze auf meinem NAS ZFS. Wöchentlich erstelle ich mit rsync ein
Backup auf einer externen HD, das Backup ist ein inkrementelles Backup.
Das funktioniert soweit ganz gut, aber ich wollte jetzt endlich von
rsync weg und auf ZFS Snapshots wechseln. Meiner Meinung nach sollte das
schneller gehen, da ZFS ja bereits weiss, welche Änderungen zu
übertragen sind, im Gegensatz zu rsync, welches zuerst alle Dateien
vergleichen muss!
Dazu erstelle ich jeweils einen neuen Snapshot von meinem Dataset und
sende den mit "zfs send -Ri" auf die Backup-Platte. Das funktioniert
auch wunderbar, ABER auf der Backupplatte ist natürlich dann immer nur
der aktuelle Stand des Filesystems sichtbar, wenn ich die alten Stände
anschauen möchte, muss ich über den .zfs Ordner gehen und dort in den
Snapshots navigieren.
Plus, ich muss auf meiner Quelle auch alle alten Snapshots beibehalten,
das möchte ich ja aber nicht, eigentlich will ich auf meiner Quelle nur
den letzten Snapshot behalten (um inkrementelle Backups zu ermöglichen).
Bei meinem rsync Backup ist es so, dass auf der Backup-Platte ein neuer
Ordner mit dem Datum angelegt wird, und dort wird dann alles, was neu
ist, rein kopiert, der Rest sind dann Hard Links. Eigentlich möchte ich
sowas hier auch wieder machen, aber von den Möglichkeiten von Snapshots
und send/receive profitieren.
Wie geht das?
Das mit den hard links wird so nicht funktionieren, aber ansonsten, wenn
ich das richtig lese, sollte doch zfs receive exakt wieder einen
passenden Snapshot auf dem Ziel anlegen, oder? Damit müsstest du
unterhalb von .zfs/snapshots die alten Snapshots sehen können, toplevel
den letzten empfangenen.
zfs send -R ist in dieser Hinsicht vielleicht gar nicht so gut, denn
dann scheint zfs receive die alten (auf der Quelle schon gelöschten)
Snapshots zu entfernen – replica mode eben. Ohne -R sollten meiner
Meinung nach auf dem Ziel immer nur neue Snapshots angelegt werden.
Habe zfs send bislang nur benutzt, um komplette Dateisysteme zu
replizieren oder aber als Stream auf einem externen Medium abzulegen.
Jörg W. schrieb:> sollte doch zfs receive exakt wieder einen> passenden Snapshot auf dem Ziel anlegen, oder?
ja, das stimmt, allerdings gibt es Probleme mit den Snapshotnamen:
Snapshot 1 besteht noch von letzter Woche. Heute lege ich Snapshot 2 an,
mache ein inkrementelles "zfs send", und lösche danach Snapshot 1 und
benenne Snapshot 2 nach Snapshot 1 um. Denn ich will ja nicht immer alle
alten Snapshots aufbewahren. Aber die Snapshots auf dem Ziel kollidieren
dann halt.
Ausserdem habe ich noch ein anderes Problem festgestellt: sobald ich auf
dem Ziel-Pool schon nur mit "ls" oder ähnlich die Dateien anschauen
will, und danch wieder einen Snapshot senden will, kommt der Error
"cannot receive incremental stream: destination fass/bak has been
modified
since most recent snapshot", was nicht verständlich ist, denn ich hab ja
nichts modifiziert. :-(
Tobias P. schrieb:> Aber die Snapshots auf dem Ziel kollidieren> dann halt.
Dann benenne die Snapshots doch anders, bspw. <YYYY>-<MM>-<DD>T<HHMMSS>
(ISO8601 timestamp). Dann kannst du die alten löschen, ohne Kollisionen
zu haben.
> …, was nicht verständlich ist, denn ich hab ja> nichts modifiziert. :-(
Wahrscheinlich hast du dabei Metadaten modifiziert. Read/only mounten
sollte helfen.
Tobias P. schrieb:> Vermutlich wurde irgend eine atime oder sowas gesetzt beim Aufrufen von> ls.
Ja, denke ich auch. Kann man vielleicht auch mit noatime oder sowas
erreichen, aber da das ein Backup ist, ist r/o meiner Meinung nach
sowieso die sinnvollere Option.
Jörg W. schrieb:> Ja, denke ich auch. Kann man vielleicht auch mit noatime oder sowas> erreichen, aber da das ein Backup ist, ist r/o meiner Meinung nach> sowieso die sinnvollere Option.
ja, das macht so schon Sinn. Man soll im Backup ja nichts ändern können.
Die einzige kleine Unschönheit an diesem ZFS-Backup ist, dass man auf
die alten Stände nur über den .zfs/snapshot Ordner zugreifen kann; beim
rsync-Backup hatte man direkt im Hauptordner für jedes Datum
entsprechende Unterordner, was ein bisschen übersichtlicher war. Jetzt
sieht man im Hauptordner nur jeweils den letzten Stand, und die alten
Stände eben über die Snapshots. Ob man da wohl noch was konfigurieren
kann?
andererseits wird man wohl einen Tod sterben müssen, das ZFS-Backup ist
beim meinen 2TB Daten wesentlich schneller. Rsync muss sich da erst
durch jede einzelne Datei durch wühlen, was sehr lang dauert, selbst
wenn rsync nicht die Prüfsummen (MD5) der Dateien vergleicht sondern nur
das Datum.
Tobias P. schrieb:> Ob man da wohl noch was konfigurieren kann?
Im Prinzip müssten sich die Snapshots auch noch explizit irgendwo anders
read/only mounten lassen, aber ich glaube, ich würde mir die Mühe dafür
nicht machen.
Walter K. schrieb:> ... und ein Snapshot ist zwar genial - aber eben immer nur ein sehr> eingeschränktes Backup
Es gibt 2 Arten von Backups:
-1- Verlust von Files und Dirs, selektiver Restore diverser Stände,
-2- Verlust von Medien, Komplettrestore des letzten Stands.
Früher hat man das oft kombiniert. Heute neigt man dazu, das zu trennen.
Snapshots helfen nur gegen 1, das aber komfortabel.
Ich benutze ja nicht die Snapshots als Backup! sondern die Snapshots
werden nur verwendet, um ein inkrementelles ZFS send auf eine andere
Platte, welche über USB angeschlossen wird, vorzunehmen. Es würde
schlichtweg zu lange dauern, jedes mal ein Vollbackup herzustellen,
deshalb muss ich mit inkrementellen Backups arbeiten.
Er hat ja letztlich beides, da er den ZFS-Stream auf ein separates
Medium clont, dort aber halt wieder als (read/only) Dateisystem
auspackt, von dem er neben dem letzten Stand auch noch eine Anzahl an
älteren Snapshots aufhebt.
Edit: Tobias war schneller als ich. ;-)
Jörg W. schrieb:> Er hat ja letztlich beides, da er den ZFS-Stream auf ein separates> Medium clont, dort aber halt wieder als (read/only) Dateisystem> auspackt, von dem er neben dem letzten Stand auch noch eine Anzahl an> älteren Snapshots aufhebt.
genau. Wobei man noch erwähnen muss, dass das NAS mit raidz arbeitet,
während das Backup wirklich nur eine einzelne Platte ohne jegliche
Redundanz ist. Ich glaube, dass es unwahrscheinlich ist, dass der raidz
Pool in einen Zustand kommt, den er nicht selber heilen kann, und
gleichzeitig die Backupplatte den Schirm zumacht. Deshalb, und wegen des
bequemeren Handlings, Backup ohne Redundanz.
Eine eigene Frage?
Dieser Thread ist über 7 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
