ZFS hat wieder mal meine Daten gerettet

Billige Hardwarekomponenten gaukeln Betriebssystemen manchmal Zustände vor, die gar nicht erreicht sind. So ist es möglich, dass Festplatten ein erfolgreiches Schreiben zurückmelden, obwohl die Daten nur im platteninternen Cache liegen, der wohlgemerkt seine Daten verliert, sobald der Strom weg ist.

Eigentlich kann ZFS keine Daten verlieren, muss sich aber natürlich auf die Rückmeldungen der Hardware verlassen. In meinem Fall wurde offensichtlich gerade auf einen zpool mit ca. 3TB persönlichen Daten geschrieben, als ich die Maschine hard resetted habe. ZFS war der Meinung, die Daten wurden geschrieben, dabei waren sie wohl noch im Cache.

Beim nächsten Hochfahren kam dann der Schock: Der Pool ist zerstört und die Daten sind nicht mehr abrufbar. zpool status -v hat da sogar eine nette Formulierung, die in etwa lautet: "The pool has failed and can not be recovered. Destroy the pool and recover it from backup."

Tja. Und was tun, wenn man für sich selbst wieder mal andere Regeln anlegt als für alle anderen und erstmal auf ein Backup verzichtet hat?

Durch die Suche in Mailinglisten bin ich dann auf eine Möglichkeit gestossen, doch noch an die Daten zu kommen: ZFS ist ein copy-on-write Filesytem. Will heissen, Daten werden nicht überschrieben, sondern nur die Änderungen zur Vorversion werden abgelegt. (in etwa) Da ZFS über diese Änderungen buchführt, ist es theoretisch möglich, das Filesystem in einen vorherigen Zustand zurückzuversetzen. Nähere Informationen dazu finden sich übrigens bei http://www.c0t0d0s0.org/archives/6067-PSARC-2009479-zpool-recovery-suppo... Wie dort erwähnt wird, ist dieses Zurückversetzen eher eine arkane Kunst, als Standardarbeit. Nicht nur, dass es sehr aufwändig gewesen wäre, es hätte auch die Gefahr bestanden, den Pool endgültig zu zerstören.

Nach etwas mehr Suche habe ich dann entdeckt, dass neuere ( noch nicht als stabil freigegebene ) OpenSolaris Versionen eine Erweiterung der zpool tools beinhalten, die eben diese Arbeit automatisieren! zpool clean -F und zpool import -F weisen ganz artig darauf hin, dass man so zwar einen defekten Pool wieder herstellen kann, aber eben ein paar Minuten an Arbeit verlieren wird, die seit der letzten Änderung vergangen sind. In meinem Fall waren das 11 Minuten. Das kann ich verschmerzen, wenn ich dafür die 3TB Daten bekomme, die sonst noch da drauf sind. Nach dem Absetzen des Befehls dauerte es nicht lange und der Pool war wieder da!

Mein Server zuhause läuft zwar jetzt mit SVN_134 , einer noch nicht offiziell stabilen Version, aber Probleme hätte ich bisher nicht bemerkt. Ganz im Gegenteil - ich kann jetzt auch Deduplication einsetzen, auf das ich schon sehnlichst gewartet habe.

Also: Verwendet OpenSolaris für Eure Fileserver - es lohnt sich!