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?
Moderiert von Cruiz:
In das am wenigsten unpassendste Forum verschoben.