staging.inyokaproject.org

Hallo, fleißiger Leser! 😀

"Ich hörte vom schleichenden Datentod - der Ami sagt dazu 'bit rot'. Dagegen will ich mich erwehren - will mich zu ZFS bekehren."

Leider liest man allerorten, für die Reparaturfunktion ("self-healing") von ZFS seien zwangsläufig Festplattenspiegel ("mirrors") oder Z-RAID oder notfalls Dateidubletten ("ditto blocks" [copies=2]) nötig.

"A single ZFS disk, unmirrored and without "copies=n"-option, can detect corruption but not repair."

Das ist auch logisch, denn die ZFS-Prüfsummen allein dienen lediglich zum "Prüfen". Sind ja keine "Reparatursummen" 😉 . Zur Reparatur beschädigter Datenblöcke benötigt ZFS redundante Daten - Sicherungskopien oder Paritäten - der zu-reparierenden Datenblöcke. Logisch. Ich wollte mich allerdings nicht damit zufriedengeben, dass ich mir nun neue Festplatten leisten und meine Datenplatte ab sofort als ZFS-Spiegelverbund bzw. als Z-RAID betreiben müsse oder 50% meiner Platte für redundante Daten opfern soll. Ich mochte nicht zusätzlich Hardware, Strom und Geld investieren, nur um Datenfehler mit ZFS nicht nur entdecken, sondern auch reparieren zu können.

"RAID dient der Datenverfügbarkeit - nicht der Datensicherung."

Das haben wir alle noch im Ohr. Und das gilt auch für die "ditto blocks". Und ob nun ZFS-Spiegelverbund, Z-RAID oder "ditto blocks" - eine separate Sicherungsplatte ist dennoch nötig. Die Datenredundanz durch so eine obligatorische Sicherungsplatte muss doch auch bei ZFS für die Reparatur beschädigter Daten irgendwie ausreichen. Auch jetzt nutze ich eine einfache separate Sicherungsplatte, wie sie viele andere vermutlich auch daheim haben, um mich vor unwiederbringlichem Datenverlust durch ausfallende Festplatten abzusichern. Hohe Datenverfügbarkeit durch Spiegel/RAID oder "ditto blocks" benötige ich nicht. Bin doch kein freischaffender Clouddienst-Anbieter.

Meine bisherige Recherche hat mich nun tatsächlich zu der Annahme geführt, dass auch mit ZFS ein einfaches Datenarchiv sehrwohl möglich sein dürfte, ohne auf dessen Behebung von Datenverfall verzichten zu müssen. Ohne Spiegel. Ohne RAID. Ohne "ditto blocks".

• Gemeldete Beschädigungen an den gespeicherten Dateien können selbstverständlich auch unter ZFS mittels der Dateikopie von einer separaten Sicherungsplatte manuell wiederhergestellt werden - einfach auf Dateiebene.

• Gemeldete Beschädigungen an den ZFS-Metadaten (Prüfsummen und Verzeichnisstruktur) können vermutlich nicht einfach durch eine Kopie von der Sicherungsplatte ersetzt werden. Da die Prüfsummen und die Dateisystemobjekte aufgrund ihrer baumartigen Struktur ("Merkle-Baum") hierarchisch aufeinander aufbauen und sich bei Veränderungen an gespeicherten Datei-Blöcken auch die übergeordneten Metadaten-Blöcke bis hin zum Über-Block mitverändern, kann man diese sich ständig ändernden Metadaten nicht mit alten Metadaten von einer Sicherungsplatte ersetzen oder wiederherstellen. Eine manuelle Reparatur von Metadaten ist aber anscheinend gar nicht notwendig, denn die Behauptung, ein ZFS-Pool ohne Spiegel, ohne RAID und ohne Tralala besäße keinerlei Selbstheilungsfunktion, scheint so pauschal gar nicht korrekt zu sein. Selbst wenn in den Einstellungen eines ZFS-Pools die "ditto blocks" für Dateien nicht aktiviert sind ("copies=0"), werden in einem ZFS-Pool dennoch immer "ditto blocks" der Metadaten erstellt - standardmäßig. Sollten also einmal Datenblöcke mit wichtigen Metadaten beschädigt worden sein, repariert sie der ZFS-Pool automatisch mithilfe dieser Metadaten-Dubletten. Und ZFS-Metadaten inklusive ihrer heilenden Dubletten fallen dem Speicherplatz bekanntlich kaum spürbar zur Last. Der ZFS-Entwickler Bill Moore beschreibt die Existenz und Funktionsweise dieser Dubletten ("ditto blocks") in seinem Artikel von 2006:

Oracle.com :: Ditto blocks - The amazing tape repellent (12.05.2006)

Anstatt also irgendwelche teuren Spiegelverbünde oder RAID-NAS-Systeme betreiben zu müssen und somit noch zusätzliche Festplatten zu verschleißen, sollte die gewohnte Sicherung auf eine separate, gut verstaute Sicherungsplatte auch für ZFS völlig ausreichend sein, ohne auf die Erkennung und Behebung von Datenverfall verzichten zu müssen:

Einfaches ZFS-Datenarchiv

• Die externe Festplatte und die Sicherungsplatte erhalten jeweils einen eigenen ZFS-Pool (ohne Spiegel, ohne RAID, ohne "ditto blocks" ("copies=0").

• Die persönlichen Dateien werden in den ZFS-Pool der externen Festplatte geschrieben. Und wie gewohnt werden regelmäßig Sicherungen auf die Sicherungsplatte durchgeführt, entweder mittels der eigenen Synchronisationsprogramme oder auch mittels des "snapshot"- und des "send | recieve"-Befehls (inklusive des "-i"-Parameters für inkrementelles Kopieren).

• Alle Dateien liegen nun redundant auf der Sicherungsplatte vor. Beschädigte Dateien können wie gewohnt manuell von der Sicherungsplatte wiederhergestellt werden. Beschädigte Metadaten werden - wie gesagt - vom Pool selbst repariert, mittels der "ditto blocks" der Metadaten. Jetzt muss erst ein wirklich schwerer Fehler an der Festplatte auftreten, der es fertigbringt, wichtige Metadaten UND ihre Kopien mitzureißen, damit der Pool nicht mehr zu retten ist.

• Es sollte sogar möglich sein, auch jenen neuen oder bearbeiteten Dateien auf der externen Festplatte Schutz vor Datenverfall zu bieten, die dort seit der letzten Sicherung erst neu entstanden und noch nicht auf die Sicherungsplatte gesichert worden sind. In dem Moment, in dem man nämlich in einem ZFS-Pool die "ditto blocks"-Option aktiviert ("zfs set copies=2 Bilderplatte"), werden nicht nachträglich "ditto blocks" für die Daten erstellt, die sich bereits im Pool befinden, sondern lediglich für die Datenblöcke, die ab sofort geschrieben werden. Und in dem Moment, in dem man die "ditto block"-Option deaktiviert, werden die vorhandenen "ditto blocks" augenblicklich gelöscht, also der durch sie verbrauchte Speicherplatz wieder freigegeben. Das müsste man nutzen können, um auch den Daten, die noch nicht auf die Sicherungsplatte gesichert wurden, Schutz vor Datenverfall zu bieten. Und zwar ohne dabei 50% einer Festplatte für "ditto blocks" zu verschwenden oder einen Spiegel- oder RAID-Verbund betreiben zu müssen:
  
  [1.] Man führt also eine frische Sicherung seiner Daten von der externen Festplatte auf die Sicherungsplatte durch. Danach aktiviert man die "ditto block"-Option auf der externen Festplatte ("zfs set copies=2 Bilderplatte").Alle Datenblöcke, die nun ab sofort in diesem Pool neu geschrieben werden, werden redundant im Pool abgespeichert, sodass nun auch diese Daten bei Datenverfall automatisch geheilt werden können. Diese Datenredundanz verbraucht ein wenig Speicherplatz, allerdings weit weniger als die 50% und schon gar keine komplette Spiegelplatte.
  
  [2.] Ist es nach ein paar Wochen mal wieder Zeit für eine Sicherung, schließt man die Sicherungsplatte an und sichert darauf wie gewohnt die neuen Dateien von der externen Platte. Da die neuen Daten nun auch dort fein gesichert sind, werden deren "ditto blocks" auf der externen Festplatte ja nicht mehr benötigt. Man deaktiviert die "ditto block"-Option ("zfs set copies=0 Bilderplatte") und deren Speicherplatz wird wieder freigegeben.
  
  [3.] Direkt danach aktiviert man die "ditto block"-Option natürlich wieder und der Kreislauf beginnt wieder von vorn.

Leider konnte ich - außer unter https://www.reddit.com/r/zfs/ - keine ZFS-Foren finden, in denen ich das Konzept zur Diskussion stellen könnte (Oracle oder irgendwelche NAS-Hersteller haben vermutlich wenig Interesse daran ☺ ). Deshalb wollte ich Euch um ein paar Gedanken und Anregungen bitten.

Mich interessiert Eure Meinung. Ist das Konzept stimmig? Oder nutzt ihr mittlerweile bereits bessere Archivlösungen gegen Bitverfall?

Kannst ja mit ZFS Snapshots machen, je nach Bedarf, stündlich, täglich oder was auch immer. Datensicherheit dürfte auch die COW (Copy On Write) Grundfunktion von ZFS bringen. Wenn aber das Massenspeichermedium im Eimer ist hilft nur Hardware auf der der Inhalt gesichert wird.

Meine Erfahrungen mit ZFS waren auf FreeBSD auf einer einzelnen SSD über ein Jahrzehnt auch ohne RaidZ trotz immer häufiger gewordenen Stromausfälle hervorragend. Da ist nichts verloren gegangen. Aber die FreeBSDler haben auch viel Arbeit in die Integration von ZFS reingesteckt, die FreeBSDler haben ja auch einen anderen Bootloader dem sie den Umgang mit ZFS schon vor langer Zeit beigebracht haben. Ubuntu hat sicherlich insgesamt mehr Entwickler, aber es dürfte alles noch viel frischer sein und könnte noch ein paar rauhe Kanten haben.

Hallo und herzlich willkommen in der Community fireabend!

Ich bin mir nicht sicher, wie deine Laufwerke so aussehen, zumal du die drei Begriffe Archivierung, Sicherung und Synchronisation so zu verwenden scheinst, als wären sie beliebig untereinander austauschbar.

Ohne jetzt weiter auf mein Verständnis dieser Begriffe einzugehen: Sollen deine beiden Festplatten (extern und Sicherung) in jedem Fall denselben Datenbestand haben - mit der Ausnahme, dass neue Daten zunächst auf der externen Festplatte landen und dann auf die Sicherungsplatte übertragen werden?

Wenn dem so ist, besteht tatsächlich eine sehr gute Chance, dass du dich mit dieser Lösung gegen den Bitverfall schützen kannst. Sobald auf einer der beiden Festplatten ein Bitfehler festgestellt wird, kopierst du die betroffenen Dateien von hü nach hott und es passt wieder.

Schwieriger wird es, wenn sich der Datenbestand zwischen externer und Sicherungsfestplatte zu unterscheiden beginnt. Die neuen Daten können wir erst einmal außen vor lassen, aber sobald es um ältere Daten geht, die nur noch auf einem der beiden Medien liegen sollten, bist du bei einem Bitfehler wieder genauso weit wie zu Beginn: Du weißt zwar, dass die Daten kaputt sind, aber nicht, wie du sie reparieren sollst.

Ungeachtet der Anwendbarkeit würde ich diesen Ansatz weder für mich privat noch auf der Arbeit umsetzen, wenn nicht mindestens noch zwei drei andere Leute in meinem Umfeld von allein auf die Idee kommen könnten und ich mir eine konsequente Umsetzung vorstellen könnte. Zu clevere Abweichungen von Standards haben meiner Erfahrung nach in der Regel zur Folge, dass man sich um den Scheiß selbst kümmern muss, dass er einem immer dann auf die Füße fällt, wenn man gerade absolut keine Zeit dafür hat und dass man sich spätestens ein halbes Jahr nach der ersten Umsetzung selbst verflucht, dass man so ein idealistischer Narr war. 😉

Um es nochmal kurz aus einem anderen Blick zu umreißen: Wenn dir deine Daten nicht wertvoll genug sind, um sie mit einer einfachen, erprobten und etwas materialintensiveren Methode zu schützen/archivieren, sind sie dir vielleicht doch gar nicht so wichtig.