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.
Jörg W. schrieb: > Read/only mounten > sollte helfen. Das wars! ich hab einfach
1 | |
auf dem Ziel-Dataset gesetzt. Damit musste man nicht mal unmounten. Vermutlich wurde irgend eine atime oder sowas gesetzt beim Aufrufen von ls.
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.
Lies Dich mal ins Thema Snapshots ein: https://docs.oracle.com/cd/E19253-01/820-2313/6ndu3p9cf/index.html Dann weißt Du auch wie Du Snapshots benennen kannst ... und ein Snapshot ist zwar genial - aber eben immer nur ein sehr eingeschränktes Backup
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.