Zuverlässige private Datensicherung unter Einbeziehung von ZFS

[karmon]

Ich bin mit ZFS noch ziemlich am Anfang.
Habe mir schon einiges durchgelesen, aber dennoch noch keine Antwort auf folgende Frage gefunden:

Treten in einem Pool, der aus einem mirror-vdev mit 2 Platten besteht, Prüfsummenfehler bei Platte 1 auf, so holt sich ZFS ja die (hoffentlich) korrekten Daten von Platte 2 und bessert die fehlerhaften Daten aus.
Bei einem Pool, der aus einem single-vdev mit nur einer einzigen Platte besteht, heißt es, dass ZFS zwar Fehler erkennt, aber mangels Redundanz keine Fehler beheben kann.
So weit, so gut.
Wären jetzt aber die gleichen Dateien in einem anderen Pool vorhanden, ließe sich dann dem Pool, auf dessen einziger Platte Prüfsummenfehler gefunden wurden, korrekte Daten aus einem anderen Pool zuführen?
Oder geht das nur durch händisches Rüberkopieren?

Konkreter Fall:
Ich habe bisher eine einzige externe Platte (300 GB, ext3) zur Sicherung von für mich relevanten Daten (hauptsächlich eigenes Bildmaterial, aber auch andere Dateien).
Nach etwas mehr Einlesen in die Materie ist mir klar, dass Redundanz ein wesentlicher Punkt beim Thema Sicherung/Backup ist.
Darum mein Plan, einen Pool aus 2 externen Platten (je 1 TB) als Mirror aufzubauen, sämtliche Daten rüberzuziehen und dort zu sichern.
Die alte Platte soll gelöscht und darauf im Anschluss unter ZFS ein zweiter Pool eingerichtet werden, auf dem sämtliche Bilder noch einmal gesichert werden sollen (quasi eine weitere Sicherung).
Mal angenommen, dass ZFS irgendwann in dem Pool mit dieser einen Platte Prüfsummenfehler feststellen sollte, so wäre es nicht schlecht, wenn man diesem Pool die Anweisung geben könnte, dass er sich für eine Reparatur die Daten aus dem anderen Pool holen soll.
Ist so etwas möglich?

(Ich kann bzw. will nicht einen einzigen Pool erstellen, in welchem sich die Kapazität aller Platten nach der kleinen 300 GB-Platte richten muss (und ich somit bei den 1 TB-Platten 700 GB ungenutzt lassen müsste).

Vielleicht kann jemand diese Frage beantworten?

[heisenberg]

Wären jetzt aber die gleichen Dateien in einem anderen Pool vorhanden, ließe sich dann dem Pool, auf dessen einziger Platte Prüfsummenfehler gefunden wurden, korrekte Daten aus einem anderen Pool zuführen?

Das ist afaik nicht möglich.

Oder geht das nur durch händisches Rüberkopieren?

Afaik: Ja.

Möglicherweise kann man das Kopieren auch automatisieren mit einem Script, denn ZFS protokolliert ja afaik die Namen der Dateien mit Datenfehlern.

Weitere Überlegungen:

Wenn Du Die 3. Platte als weitere Redundanz für die Daten der 1 TB Platten nehmen willst, dann reicht das ja nicht. Da hilft Dir das mit dem händischen kopieren auch nicht weiter. Wenn die kleine Platte voll ist, ist sie voll.

Insofern könntest Du auf den Platten eine 300 GB Partition erzeugen, und dann einen ZFS Mirror Pool mit 3 Platten erzeugen, also doppelte Redundanz. Den restlichen Platz kannst dann mit 700 GB Partitionen zu einem weiteren separaten normalen 2-Platten-Mirror-Pool konfigurieren.

Ich sehe aber nur bei wichtigen Daten die Notwendigkeit von mehr als einem Mirror. Außerdem wäre mir da vor einem weiteren Mirror ein Backup wichtiger.

Ich betreibe auch ein paar Pools mit alten Platten. Ich sehe da durchaus aber selten Datenfehler. Das wichtige dabei sind regelmäßige(wöchentlich) volle Datenprüfungen(zfs scrub), wo man dann auch mitbekommt, wenn die Fehler werfen (Monitoring/Email/...). Durch den scrub werden Fehler erkannt und behoben; d. h. schleichende Datenkorruption im Datenbestand entsteht nicht. Wenn ein Pool nicht gescrubbed wird und eine Platte fällt aus, können vorhandene Parity-Fehler nicht mehr korrigiert werden, obwohl man das mit Scrubs leicht vermeiden kann.

Meistens lösche ich dann die Fehlerzähler und führe direkt noch einen scrub aus. Passiert das zu oft, ersetze ich die Platte, weil sie vermutlich bald ausfallen wird.

Das kritische wären da für mich bei ZFS insgesamt nicht einzelne Parity-Fehler, sondern komplett ausfallende Platten. Der Scrub ist auch regelmäßiger Belastungstest. Wenn eine Platte ohnehin schon nahe an der Ausfallgrenze ist, bekommt sie durch die regelmäßigen Scrubs den Todesstoss - und das ist sehr gut. Denn wenn die Platten alle so gut wie nie belastet werden und im Lauf der Zeit dann irgendwann gleich mehrere eigentlich an der Ausfallschwelle sind und eine Platten-Streß-Situation tritt auf, dann kann es sein, dass gleich mehrere ausfallen. Dann sind die Daten weg.

Ich würde also mit den 1 TB einen mirror einrichten und die 300 GB als Single für das Backup, wie Du das schon hast.

[karmon]

Vorweg schomal vielen Dank für deine schnelle Antwort.

Wenn Du Die 3. Platte als weitere Redundanz für die Daten der 1 TB Platten nehmen willst, dann reicht das ja nicht. Da hilft Dir das mit dem händischen kopieren auch nicht weiter. Wenn die kleine Platte voll ist, ist sie voll.

Grundsätzlich richtig. Nur ist die Platte derzeit deswegen fast voll, weil sie eben auch viele andere Dinge beinhaltet, die zwar einiges an Platz einnehmen, die für mich in der Wichtigkeit aber bestenfalls an dritter Stelle stehen (z.B. Image-Dateien vom OS). Den Kram würde ich (nach einigem Ausmisten) auf den 1 TB-Mirror rüberziehen und nach dem Neu-Einrichten der kleinen Platte mit ZFS nur noch eigenes Bildmaterial abspeichern. Dann hätte ich noch für einige Jahre genug Platz.

Insofern könntest Du auf den Platten eine 300 GB Partition erzeugen, und dann einen ZFS Mirror Pool mit 3 Platten erzeugen, also doppelte Redundanz. Den restlichen Platz kannst dann mit 700 GB Partitionen zu einem weiteren separaten normalen 2-Platten-Mirror-Pool konfigurieren.

Das wäre natürlich auch noch eine Idee.
Ich hatte bisher eine Partionierung gar nicht mehr auf dem Schirm, nachdem ich mehrmals gelesen hatte, dass man ZFS idealerweise die komplette Platte überlassen soll.
Vielleicht bezog sich diese Empfehlung aber auch nur auf den Fall, wenn auf einer Platte Partitionen mit anderen Dateisystemen eingerichtet sind? Keine Ahnung.

Ich sehe aber nur bei wichtigen Daten die Notwendigkeit von mehr als einem Mirror. Außerdem wäre mir da vor einem weiteren Mirror ein Backup wichtiger.

Nun, diese Daten (eigene Fotos und Videos der letzten 2 Jahrzehnte) sind für mich sehr wichtig, auch weil nicht wiederherstellbar, wenn sie mal beschädigt oder gar weg wären.
Und der 1 TB-Mirror auf externen Platten soll ja ein wichtiger Teil des Backups sein (was die Bilder angeht, eigentlich schon ein Archiv).
Nach dem Sichern wandern die beiden Platten dann wieder in die Schublade bzw. in den Schrank.
Das Bildmaterial war bisher ansonsten auf internen Platten im Rechner und die vor 14 Jahren gekaufte 300 GB-Platte war ein erster Schritt in Richtung Sicherung. Diese Platte kam bestenfalls alle paar Monate mal raus und hat, trotz ihres Alters, weniger Stunden drauf, als die Platte in meinem Hauptrechner innerhalb einer Woche in Betrieb ist.
Aus heutiger Sicht war meine bisherige Sicherung natürlich sträflich nachlässig, aber ich hatte bisher zum Glück nie einen Verlust zu beklagen (wobei ich natürlich nicht sagen kann, wie es mit schleichendem Bit-rot aussieht, der für mich erst seit diesem Jahr überhaupt ein Begriff ist).

Auf das Thema Datenzerfall/Bit-rot und, im Zuge der Vorsorge dagegen, auf ZFS bin ich auch deswegen gekommen, da ich beschädigte Bilder, wie sie auch hier (https://en.wikipedia.org/wiki/Data_degradation) gezeigt werden, auf einem USB-Stick schon mehrfach selbst erlebt habe. Das ist mir nicht mal auf einer noch deutlich älteren Festplatte passiert, aber es hat mich auf das Problem an sich aufmerksam gemacht.
Auch wenn das bis jetzt ausschließlich mit einem USB-Stick einer Drogeriekette (*M) passiert ist, bin ich seitdem bei USB-Sticks sehr misstrauisch.

Mein Plan ging deswegen auch hin zu einem Mirror mit eventuell sogar 3 Platten, um genug Redundanz zu haben, bis ich in den nächsten Jahren hoffentlich noch auf weitere Möglichkeiten zur halbwegs sicheren, längeren Aufbewahrung stoße.
Eine dritte Platte könnte ich einem Mirror, im Gegensatz zu einem RaidZ, auch später noch problemlos hinzufügen.

Das kritische wären da für mich bei ZFS insgesamt nicht einzelne Parity-Fehler, sondern komplett ausfallende Platten.

Die Argumentation kann ich gut nachvollziehen. Darum wird es bei mir im Zweifel ein 3-fach Mirror. Eine ausfallende Platte wird dann sofort ersetzt.
Bei genug Redundanz ist für mich schleichender Datenzerfall über die Jahre allerdings das größere Thema.
Ich möchte nicht, dass Bilder im Laufe der Zeit so aussehen, wie das, was sich auf dem einen USB-Stick im Laufe von wenigen Jahren getan hat.
Darum auch die Entscheidung für ZFS und der Möglichkeit, durch Redundanz beschädigte Daten wieder herzustellen.
Und deshalb auch meine Frage, ob das von Pool zu Pool möglich ist (offenbar leider nein), denn bei der einzelnen 300 TB-Platte gäbe es aufgrund fehlender Redundanz keine Möglichkeit für ZFS, Dateifehler automatisch zu beheben, so wie es in einem Pool mit Mirror-vdev möglich ist.
Eine Alternative zu deiner Idee mit dem Einrichten einer 300-GB-Partition auf der 1 TB-Platte wäre eventuell auch, zu der kleinen Platte ein passendes Pendant mit noch guten Laufwerkswerten zu besorgen und damit einen zweiten kleineren Mirror aufzubauen.

[heisenberg]

Hallo Karmon,

ZFS-Devices immer online!

Grundsätzlich sind afaik ZFS Pools darauf ausgelegt "online" zu funktionieren. D. h. alle Einzelgeräte sollten immer online sein. Wenn sie das nicht sind, ist das eine Störung und eine Störung kann gemäß der gewählten Redundanz abgefangen werden oder nicht. Dafür mit Offline-Datenträgern zu spielen, auf solche Spielereien, Dinge dafür einzusetzen, wofür Sie nicht gedacht sind, würde ich mich nicht einlassen - es sei denn aus Freude am experimentieren. Aber experimentieren und eine möglichst robuste Datensicherung passt für mich denkbar schlecht zusammen.

In Deinem Fall würde ich deswegen die Backup-Platte(n) im Schrank(= 2 x 1 TB?) und die Backup-Platte am Rechner (= 1 x 300 GB?) mit getrennten Dateisystemen benutzen. Dafür überall ZFS wegen der Checksummen zu benutzen, finde ich sinnvoll, um die Datenintegrität leicht regelässig prüfen zu können.

Wenn Du all zu große Sorge wegen Bit-Rot hast, kannst Du die Daten ja auch mehrfach auf der Platte speichern. D. h. mehrere Verzeichnisse mit dem gleichen Inhalt. Dann hast Du bei einem normalen Mirror mit bei doppelter Ablage insgesamt 4 Versionen der gleichen Datei. Die Wiederherstellung im Fehlerfall beider primärer Kopien musst Du dann aber manuell bewerkstelligen.

Man kann auch mit anderen Methoden Arbeiten z. B. mit einer Backup-Software, die Checksummen nutzt. Da gibt so einige. Allerdings sollte man sicherstellen, dass das verwendete Backupprogramm, die Checksummen auch verwendet. tar macht das im Default-Modus beispielsweise nicht. Weiterhin könnte man selbst Checksummen für alle Dateien erstellen z. B. mit sha256sum. Das ganze immer in der Kombination mit mehrfacher Ablage der Archive, um dann genug Replicas zu haben, um bei defekten Dateien genug gute Kopien zu haben.

Lagerung

Bei Deiner Anwendung Die Platten sind für ein Backup da, liegen im Schrank wäre für mich noch der Punkt Lagerung wichtig. Für lange Lebensdauer Deiner Lagerfestplatten ist eine möglichst konstante Lagertemperatur wichtig - idealerweise um die 20°C. Ebenso wichtig ist es die Platten vor Feuchtigkeit zu schützen, sonst kann es sein, dass Du irgendwann die Platten aus dem Schrank holst und keine funktioniert mehr. Da ist es vielleicht auch noch mal gut selbst etwas im Internet zu recherchieren. Ich habe das jetzt gerade selbst nur kurz gegoogelt.

Ansonsten würde ich die Festplatten - wie bereits geschrieben - regelmäßig, z. B. jährlich Datenchecks(zfs scrub) unterziehen, vielleicht sogar mehrfach hintereinander. Damit siehst Du ja, ob Du BitRot-Probleme hast oder nicht. Auch die SMART-Werte würde ich danach checken, ob die Platten durch die Scrubs irgendwelche schlechten Werte aufweisen.

Ich hatte bisher eine Partionierung gar nicht mehr auf dem Schirm, nachdem ich mehrmals gelesen hatte, dass man ZFS idealerweise die komplette Platte überlassen soll.

Das hat afaik Performancegründe, was bei Dir beim Thema Backup wohl eher kaum eine Rolle spielen dürfte.

Kompatibilität

Gerade bei Festplatten wäre auch noch der Kompatibilitätsaspekt wichtig, wenn das bei Linux eher weniger zum Zuge kommen dürfte. Also z. B. bei einem Technologiesprung wie damals z. B. von IDE -> SATA braucht man natürlich einen Rechner, der die alte Schnittstelle noch bedient. Das scheint mir aber hier(USB) kein Problem zu sein.

Backup-Konzept

Dein Backup-Konzept habe ich jetzt noch nicht so wirklich verstanden. Da wäre es wichtig, dass das durchdacht ist.

Bis jetzt habe ich verstanden:

• Du hast einen oder mehrere PCs mit Live-Daten.
• Du hast eine 300 GB Platte für's Backup, die immer am Rechner hängt und kontinuierlich Daten mit Backupdaten befüllt wird.
• Du hast einen Mirror aus 2 x 1 TB im Schrank, der gelegentlich ein Datenupdate von der 300 GB Platte bekommt.

Habe ich das so richtig verstanden?

[cosinus]

Also mir kommt das Ganze ein wenig kompliziert rüber. Ich mach es bei meinem privaten Debian-PC so:

- als Backupplatten hab ich ganz normale SATA-Platten, die in einen USB3-Festplattendock kommen
- wenn ich ein Backup mache, steck ich erstmal die nächste Platte ins Dock
- dann mounte ich die Platte nach /external
- über ein alias in der .bashrc mach ich mit mksquashfs aus den wichtigsten Verzeichnissen squashfilesystem Archive, die in /external erstellt werden (Mit Datum im Dateinamen)
- bei Bedarf mach ich noch ein fullrsync des Systems, Ziel ist dann /external/fullrsync

[karmon]

Grundsätzlich sind afaik ZFS Pools darauf ausgelegt "online" zu funktionieren. D. h. alle Einzelgeräte sollten immer online sein. Wenn sie das nicht sind, ist das eine Störung und eine Störung kann gemäß der gewählten Redundanz abgefangen werden oder nicht.

Bei den beiden gespiegelten Platten, die bestenfalls nur alle paar Monate zur Sicherung von z.B. Fotos an den Rechner angeschlossen werden und danach wieder in ihr "Lager" wandern, würde ich jedesmal ein "zpool import" und vor dem Aushängen ein "zpool export" machen. So ließe sich der Pool auch sauber an einem anderen Rechner importieren. sollte dies, aus welchen Gründen auch immer, erforderlich sein.
Ansonsten müsste ich ja bei einem Dateisystem wie ext3/4 bleiben, was ich allein schon wegen der Prüfsummen, die ZFS bietet, nicht will.

Wenn Du all zu große Sorge wegen Bit-Rot hast, kannst Du die Daten ja auch mehrfach auf der Platte speichern. D. h. mehrere Verzeichnisse mit dem gleichen Inhalt. Dann hast Du bei einem normalen Mirror mit bei doppelter Ablage insgesamt 4 Versionen der gleichen Datei.

Das wäre zwar auch eine Möglichkeit, aber zum einen hätte ich dabei nur die Hälfte des Platzes zur Verfügung und zum anderen wäre es bei Ausfall einer Platte schon wieder eng.
Darum würde ich lieber dem Mirror eine 3. Platte spendieren. Wäre dann statt 4-facher Datenredundanz "nur" die 3-fache, aber ein Ausfall einer Platte wäre dafür nicht so kritisch.

Ansonsten würde ich die Festplatten - wie bereits geschrieben - regelmäßig, z. B. jährlich Datenchecks(zfs scrub) unterziehen

Hätte ich fürs erste so alle 3-6 Monate eingeplant. Werde ich dann schauen, wie das alles in der Praxis ist.

Das hat afaik Performancegründe, was bei Dir beim Thema Backup wohl eher kaum eine Rolle spielen dürfte.

Ja, die Leistung steht absolut hinten an. Ob das nun etwas länger dauert oder nicht, ist mir nicht so wichtig.

Also z. B. bei einem Technologiesprung wie damals z. B. von IDE -> SATA braucht man natürlich einen Rechner, der die alte Schnittstelle noch bedient. Das scheint mir aber hier(USB) kein Problem zu sein.

Nein, das ist in der Tat kein Problem.
Ich habe sogar noch einen Rechner aus dem Jahr 2000 mit den längst veralteten Schnittstellen, die damals eben üblich waren. Somit kann ich auch noch die alten IDE-Platten auslesen und der Neugierde halber schauen, ob nach den mehr als 2 Jahrzehnten die Dateien noch ok sind oder nicht (letztes Jahr war das alles noch problemlos möglich ).

Bis jetzt habe ich verstanden:

Du hast einen oder mehrere PCs mit Live-Daten.
Du hast eine 300 GB Platte für's Backup, die immer am Rechner hängt und kontinuierlich Daten von dem/den Rechner(n) sichert.
Du hast einen Mirror aus 2 x 1 TB im Schrank, der gelegentlich ein Datenupdate von der 300 GB Platte bekommt.

Habe ich das so richtig verstanden?

Fast.
Punkt 1 passt soweit, da ich an einem einzigen Rechner, alle Daten auf der internen Platte habe (z.B. auch alle Fotos von der SD-Karte direkt dort ablege).
Bei Punkt 2 ist es so, dass diese externe 300 GB-Platte nur alle paar Monate mal an den Rechner angeschlossen wurde, um mal wieder einen größeren Schwung Bildmaterial zu sichern (das nur recht selten in größeren Mengen neu anfällt). Diese ext. Platte verschwand in der Vergangenheit dann wieder in der Schublade (manchmal für ein ganzes Jahr, wenn kaum was angefallen ist; von einer kontinuierlichen Sicherung kann man da beim besten Willen gewiss nicht sprechen ) und war quasi die einzige Sicherung des Inhalts der internen Platte (aus heutiger Sicht durchaus leichtsinnig).
Diese Sicherung soll nun der 1 TB-Mirror bestehend aus 2 oder auch 3 Platten übernehmen.

In welcher Form ich die 300 GB-Platte dann weiterverwende, da habe ich mich noch nicht festgelegt. (Sie hat, wie schon erwähnt, kaum Stunden auf dem Zähler und noch beste Smart-Werte.)
Von dir habe ich nun den ein oder anderen Gedankenanstoß für eine Verwendung bekommen und eventuell nutze ich sie tatsächlich häufiger auch im Alltagsbetrieb.


@ cosinus
Squashfs hat mir bis eben nichts gesagt und beim Durchlesen der Beschreibung habe ich gesehen, dass es nur lesbar ist. Wie soll dann ein Block oder eine Datei neu geschrieben werden, wenn sich tatsächlich mal ein oder mehrere Bits drehen und die Datei repariert werden soll (so wie es z.B. ZFS bei entsprechender Redundanz automatisch macht)?
Das ist ja der Grund, weshalb ich mich für die Sicherung von für mich wichtigen Daten ausschließlich nach Dateisystemen umgeschaut habe, die Prüfsummen berechnen und defekte Dateien reparieren können, wenn eine Redundanz vorhanden ist.
So habe ich mich in Btrfs und ZFS eingelesen und mich schließlich für letzteres entschieden.
(Vielleicht ist in nicht allzu ferner Zukunft auch BCacheFS eine Alternative.)

[cosinus]

Squashfs-Archive nehm ich auch nur für die wichtigsten Verzeichnisse. Also sowas wie etc, var und root.
Wenn ich zusätzlich meine große Datenablage sichern will, nehm ich rsync.

[jdr]

Moin,

@karmon: Ich finde deine Idee ehrlich gesagt etwas kompliziert. ZFS-Mirror mit den beiden 1 TB Platten gehe ich noch mit. Wenn du da einen regelmäßigen Scrub laufen lässt, die SMART-Werte im Blick hast etc. sollte das OK sein. Ich persönlich habe keine Erfahrung mit ZFS auf USB-Platten, aber unzuverlässiger als ein extfs wird es auch nicht sein.

Jetzt zu dem alten 300 GB Schätzchen. Gegen die Verwendung als zusätzliche Backupplatte spricht erstmal nichts. Wenn du das mit ZFS machst, werden bei einem Scrub eventuelle Fehler erkannt (natürlich nicht korrigiert) und soweit ich weiß auch bei zpool status die betroffenen Dateien aufgelistet, z. B.

Code: Alles auswählen

(...)
errors: Permanent errors have been detected in the following files:
  und hier sind dann deine Dateien, die hinüber sind
(...)

Jetzt kommt die spannende Frage: Wie gehst du damit um? Wenn wirklich aus irgendwelchen Umständen mal ein paar Bits gekippt sein sollten, die Festplatte aber eigentlich noch OK ist, könntest du die entsprechende(n) Datei(en) einfach neu draufkopieren. Wobei ich nicht weiß, wie wahrscheinlich so ein Ereignis bei einer vernünftigen Festplatte wirklich ist. Ich habe meinen ZFS-Pool aus 4x 3 TB DT01ABA300 seit ca. 8 Jahren und zwischendurch auch mal spannende Dinge gemacht wie sukzessive die unterlagerten Laufwerke auf LUKS umgestellt und nach jedem Scrub ist mein zpool status zum Glück unfassbar langweilig mit scrub repaired 0B in xx:xx:xx with 0 errors. Bei einem Billigheimer USB-Stick halte ich etwas Entsprechendes für wesentlich wahrscheinlicher.

Ich habe auf meinen externen Platten immer ein ganz stinknormales ext4 (teilweise auch auf LUKS). Ab und zu lasse ich mal cshatag drüber laufen, das mtime und sha256-Prüfsumme in den Extended Attributes speichert. Wenn sich die Prüfsumme ändert, obwohl die mtime gleich geblieben ist, meckert das Programm. Ist aber bisher auch noch nicht passiert. Eine weitere Möglichkeit wäre par2, da kannst du einen Prozentsatz an Redundanz einstellen (der geht dir natürlich als Speicherplatz verloren) und prüfen/reparieren.

[karmon]

Squashfs-Archive nehm ich auch nur für die wichtigsten Verzeichnisse. Also sowas wie etc, var und root.

Nun, wir haben da offenbar etwas unterschiedliche Anforderungen.
Das Sichern des Systems ist für mich derzeit nicht wichtig, da ich dieses, trotz eines gewissen Zeitaufwandes, wieder jederzeit neu installieren und einrichten kann.
Mein Hauptanliegen ist die redundante Sicherung und Aufbewahrung von nicht-wiederherstellbaren Daten.

Ich finde deine Idee ehrlich gesagt etwas kompliziert.

Inwiefern?
Nach der 3-2-1-Backup-Strategie bei wichtigen Daten (3 Kopien, 2 davon auf unterschiedlichen Medien, 1 davon an einem geographisch anderen Ort) mache ich eigentlich deutlich zu wenig, da ich mich bisher nur auf die "3" konzentriert habe.
Gibt genug Leute, die ein NAS mit mehreren Platten betreiben und davon wiederum ein komplettes Backup haben.
Ich will nur einen ZFS-Mirror auf 2-3 externen Platten einrichten, auf denen die für mich wichtigen Daten dauerhaft aufbewahrt werden sollen. Eine Platte wird dann ersetzt, wenn sie steigende Fehlerraten zeigt oder komplett ausfällt.

Die Frage ist für mich eher, wie ich die dann freiwerdende bisherige 300 GB-Platte weiterverwende. Die hat keinerlei Fehler und ist für eine weitere Verwendung definitiv geeignet (dann halt ohne direkte Redundanz wie in einem Mirror).

Wenn wirklich aus irgendwelchen Umständen mal ein paar Bits gekippt sein sollten, die Festplatte aber eigentlich noch OK ist, könntest du die entsprechende(n) Datei(en) einfach neu draufkopieren.

Ja, so würde ich es dann auch machen.
Ob ich sie bei ext3 belasse oder auch auf ZFS umstelle, werde ich mir dann noch überlegen.

Danke für den Hinweis auf cshatag und par2. Das schaue ich mir mal näher an.

[jdr]

Ich finde deine Idee ehrlich gesagt etwas kompliziert.

Inwiefern?
Nach der 3-2-1-Backup-Strategie bei wichtigen Daten (3 Kopien, 2 davon auf unterschiedlichen Medien, 1 davon an einem geographisch anderen Ort) mache ich eigentlich deutlich zu wenig, da ich mich bisher nur auf die "3" konzentriert habe.
Gibt genug Leute, die ein NAS mit mehreren Platten betreiben und davon wiederum ein komplettes Backup haben.
Ich will nur einen ZFS-Mirror auf 2-3 externen Platten einrichten, auf denen die für mich wichtigen Daten dauerhaft aufbewahrt werden sollen. Eine Platte wird dann ersetzt, wenn sie steigende Fehlerraten zeigt oder komplett ausfällt.
Die Frage ist für mich eher, wie ich die dann freiwerdende bisherige 300 GB-Platte weiterverwende. Die hat keinerlei Fehler und ist für eine weitere Verwendung definitiv geeignet (dann halt ohne direkte Redundanz wie in einem Mirror).

Haha, das "etwas kompliziert" bezieht sich lediglich auf deinen Wunsch, die Reparatur etwaiger Prüfsummenfehler auf der 300-GB-Platte über ZFS handhaben zu wollen. Ich bin die letzte Person, die etwas gegen das Anlegen "zu vieler" (gibt es das in diesem Zusammenhang?) Backups hat.
Nur als Beispiel, ich selbst bin da schon fast etwas paranoid:

1. Alle meine Daten (der größte Anteil sind - wie auch bei dir - Bilder) sind auf dem richtigen NAS, das aber aufgrund der Leistungsaufnahme verbunden mit den unverschämten Energiekosten in unserem schönen Land nur bei Bedarf eingeschaltet wird.
2. Die Daten sichere ich am 1. und 3. Sonntag des Monats mit zwei verschiedenen Lösungen (rsync mit Hardlinks direkt auf dem NAS // dar auf meiner Windows-Workstation) auf zwei verschiedene externe Festplatten, die natürlich nur zu diesem Zweck angeschlossen werden.
3. Die Daten sichere ich ebenfalls am 1. und 3. Sonntag des Monats auf zwei verschiedene Cloudspeicher. Selbstverständlich verschlüssele ich die Daten vorher selbst.
4. Die Daten werden über ein zweites "NAS" auch auf die Workstations, Notebooks etc. synchronisiert. Das ist ein Mini-PC, der nur ein paar Watt zieht und daher 24/7 läuft. Ich weiß, Synchronisation ist kein Backup im eigentlichen Sinne, aber da es sogar einen Papierkorb gibt, hilft das trotzdem gegen Festplattenausfälle, versehentlich gelöschte Dateien etc.
5. Bei meinen Eltern habe ich noch einen Raspberry Pi stehen, der sich 1x täglich die Daten vom Mini-NAS via rsync rüberzieht.
6. Von den häufig veränderten Daten (insbesondere Dokumente) lege ich nochmal zusätzliche tägliche oder stündliche Sicherungen auf Cloudspeicher an (selbstverständlich auch von mir selbst verschlüsselt).

Ja, nachdem ich das jetzt so niedergeschrieben hab, bin ich sicher, dass ich es übertreibe.

Bei dir fehlt 1 geographisch anderer Ort noch, oder? Dann könntest du ja damit beginnen, die 300 GB Festplatte z. B. im Büro aufzubewahren.

[heisenberg]

Hier auch mal eher ein paar allgemeine Punkte, die nicht unbedingt auf Dein Szenario zutreffen müssen.

Bzgl. dem was jdr geschrieben hat:

Ja. Das enthält 2 Punkte die mir auf jeden Fall auch wichtig sind. Dazu möchte ich noch weitere zwei ergänzen:

1. Automatisierung
2. Backup-Gerät evtl. nur bei Bedarf einschalten(Strom sparen)
3. Pull statt Push-Sicherung
4. Resourcenanforderung von ZFS

Automatisierung

Manuelle Backups haben das Problem, dass die auch einfach vergessen kann. Kurze Backupintervalle sind ansonsten manuell auch nicht wirklich praktikabel.

Nur bei Bedarf einschalten

Es wäre eine Möglichkeit, dass man ein Backup-Gerät per Zeitschaltuhr oder BIOS regelmässig hochfahren lassen kann. Nach dem Backupprogramm, kann man wieder den Shutdown durchführen.

Pull statt Push-Sicherung

Eine Pullsicherung zieht sich vom Produktiv-PC selbst die Daten. Das hat den Vorteil, dass ein a) kompromittierter PC die Daten der Backupablage nicht zerstören kann oder b) eine versehentliche Löschung der Backup-Datenablage vom Produktiv-PC aus eher unwahrscheinlich ist, weil der erst einmal keinen Zugriff hat.

Resourcenanforderung von ZFS

Grundsätzlich finde ich ZFS schon recht schick wegen der integrierten Prüfsummen und der für mich wirklich angenehmen Handhabung. Ein möglicher Nachteil für mich ist, dass ZFS gewisse erhöhte Resourcenanforderungen stellt. D. h. wenn man einen kleinen Backupserver einsetzen möchte, fallen gewisse stromsparende Plattformen da auch schon mal weg. Z. B. OpenWRT. Da braucht man dann schon eine "PC-"-artige-Hardware(amd_64), die teurer ist. Also ZFS scheint viel RAM wohl nicht wirklich zwingend zu benötigen. Das ist möglicherweise nur wieder für optimale Performance notwendig. Trotzdem hat sich da z. B. OpenWRT entschieden ZFS nicht zu unterstützen, weil ZFS trotzdem eher zu fett ist.

Eigene Erfahrungen

Vor einigen Jahren hatte ich in einer WG-Umgebung mal einen Mini-Server laufen, der eine USB-Festplatte angschlossen hatte und regelmässig(stündlich) das Backup durchgeführt hat. Damals mit rsnapshot. Mit dem stündlichen Backup hatte man dann auch laufende Arbeitsergebnisse gesichert, falls die mal versehentlich verloren gehen.

[cosinus]

Nun, wir haben da offenbar etwas unterschiedliche Anforderungen.
Das Sichern des Systems ist für mich derzeit nicht wichtig, da ich dieses, trotz eines gewissen Zeitaufwandes, wieder jederzeit neu installieren und einrichten kann.
Mein Hauptanliegen ist die redundante Sicherung und Aufbewahrung von nicht-wiederherstellbaren Daten.

Das mit squashfs mach ich nur weil das kein großer Aufwand ist. Hab das alles über alias shortcuts. Und falls ich mal neu installieren muss, hab ich noch meine alten Logs und Konfigs. Die großen Ordner mit Musik und Videos sichere ich mit rsync. Redundanz schaffe ich mit vier Backupfestplatten.

[uname]

@karmon
Falls du noch eine Lösung suchst: Schon etwas älter (2007) und nicht ganz ernst gemeint aber immer wieder gut.

CSI:Munich
https://www.youtube.com/watch?v=1zw8V8g5eT0