Dabei fing es so harmlos an…

Bevor ich meinen Homeserver vor ein paar Monaten zusammenbastelte, machte ich mich natürlich schlau was sich in Sachen Dateisysteme inzwischen alles getan hatte und welches sich für meine Zwecke am besten eignen würde. Nach ein paar Tagen, die ich mit Recherchen um rumprobieren verbrachte, fiel meine Entscheidung auf BtrFS. Das ist zwar nach wie vor im experiementellen Status, aber sollte angeblich sehr robust und auch schon ausgereift sein. Also Softraid angelegt, Verschlüsselung drübergelegt und das ganze mit ner Prise BtrFS garniert. Bis letzte Woche lief dann auch alles einwandfrei. Dann allerdings kam die Idee Backups nun auch auf einer USB-Platte anzulegen und dafür USB 3.0 zu nutzen, welches der HPN54L natürlich nicht unterstützt. Also kurzerhand ne PCIe-Karte eingebaut, alles angeschlossen und drauflos gescriptet. Zumindest in der Theorie. In der Praxis stürzte der Server nach etwas Last auf der Karte ständig ab und lies sich nicht mal mehr reseten. Dabei ging dann auch ein größeres VM-Image flöten, welches zu dem Zeitpunkt natürlich geöffnet war. In der Folge bekam ich beim Zugriff ständig csum-Fehler. Besonders beim täglichen Backup nervte das schon etwas und so kam der Wunsch, die Datei nach Möglichkeit zu retten oder zumindest die Fehler zu beseitigen.

Dafür gibt es wie für jedes andere Dateisystem unter Linux diverse Tools. Auch hier kurz schlau gemacht, benutzte ich das mitgelieferte „btrfsck“, welches allerdings mit einer Fehlermeldung abbrach. Also weitergelesen, rumprobiert und irgendwann stiess ich auf den Tipp, dass man die Option „–init-csum-tree“ nutzen könnte, um den csum-Baum neu anzulegen und das Problem damit zu beseitigen. Hätte ich mich an der Stelle weiter schlau gemacht, wäre ich irgendwann auch einen Foreneintrag gestossen, der darauf hinweist, dass der Baum nicht neu aufgebaut, sondern schlichtweg gelöscht wird. Aber hinterher ist man ja immer schlauer…

Nachdem der Befehl etliche Stunden durchrödelte, lies sich das Device zwar mounten, aber das wars dann auch schon. Jetzt hagelte es Fehler und nach kurzer Zeit kam dann auch prompt ein Kernel-Panic. So kam ich an die Daten nicht mehr ran. Zum Glück gibt es aber zumindest eine Möglichkeit aus solch kaputtreparierten Devices die Daten heraus zu ziehen. Sie versteckt sich hinter der Option „restore“ des Tools „btrfs“. Einfach das Devices und den Ort wohin geschrieben werden soll angeben und schon gehts los. Als kleiner Fallstrick hat sich die Option „path-regex“ erwiesen, die nicht allzu intuitiv die Möglichkeit bietet und bestimmte Dateien wiederherzustellen. Hier ein kleines Beispiel:

btrfs restore /dev/mapper/vg_raid-raid /mnt/backup/restore/ -v –path-regex ‚^/(|abc(|/.*))$‘

 

Hier wird alles aus dem Unterordner „/abc“ rekursiv von Device vg_raid-raid wiederhergestellt. Es landet im Ordner „restore“ des Mounts „backup“ und weils so schön aussieht, schalten wir auch noch Verbose mit der Option -v ein. Bei mir hats bestens funktioniert, wenn ich auch lang für ein Beispiel für den regulären Ausdruck suchen musste. Vielleicht sollte ich noch erwähnen, dass nur die reinen Daten zurückgeholt werden. Änderungsdatum, Rechte, Soft- und Hardlinks etc. sind allesamt futsch.