Es gibt sie. Diese Tage, an denen man denkt, dass ein Backup doch auch nicht die schlechteste Idee gewesen wäre.
2010 kaufte ich mir eine QNAP SS-439 Pro NAS, die knapp über 4 Jahre lang gute Dienste geleistet hat. Bis vor ein paar Tagen.
Plötzlich war sie aus und meine Einschaltversuche führten zwar dazu, dass der Netzteillüfter läuft, aber das war es auch schon. Keine blinkenden LEDs, keine Sounds, nichts und auch mit entfernten Platten tat sich nicht mehr.
Immerhin war ja zu hoffen, dass die Platten an sich dadurch nicht völlig zerstört waren.
Erste Idee und auch der Vorschlag im QNAP Supportforum war natürlich das gleiche Gerät erneut zu besorgen. Verkauft wird es allerdings schon seit längerem nicht mehr und ein 3 Jahre altes Gerät bei eBay für den selben Preis wie ein neues zu erwerben klang auch nicht so richtig attraktiv.
Also was tun?
Wenn es ein echtes Hardware-RAID wäre, wäre man wohl entweder ziemlich aufgeschmissen oder hätte zumindest größere Probleme. Glücklicherweise verwenden die QNAP Geräte aber ein normales Linux Software RAID.
Da es mir aber zu riskant war einfach ein Linux mit den Platten zu booten und zu versuchen RAIDs zu starten entschied ich mich dafür erstmal ein Low-Level Backup der Platten zu machen.
Dazu verwendete ich meine neue Lieblings-Live-Linux-Distro grml mit Forensic Startoptionen, die garantieren, dass alles read-only gemounted wird und keine RAIDs, LVMs oder ähnliches gestartet werden.
An diesem Punkt hilft es Zugang zu einem größeren Storagesystem zu haben, wo man die Images mal eben hinlegen kann.
Dorthin kopierte ich die drei wichtigen Disks dann mittels dd.
Bei einer Platte gelang das leider nicht, da immer wieder I/O Fehler auftraten. Die beiden anderen gingen aber und da es sich um ein RAID 5 handelte bestand also weiterhin Hoffnung.
Ich konvertierte die gebackupten Raw Files nun mittels VBoxManage convertfromraw in VirtualBox Disks und startete erneut grml.
Es stellte sich heraus, dass die QNAP mehrere Partitionen auf den Disks angelegt hatte, jeweils für das eigene System, Swap und die eigentlichen Daten. Das RAID für die Swap-Partition startete auch schon wunderbar von selbst, das eigentlich wichtige brauchte etwas Starthilfe.
Nach einigem Rumprobieren und dann mdadm --run --force gelang aber auch schließlich das.
An diesem Punkt ist vielleicht zu erwähnen, dass ich die QNAP wahrscheinlich nicht gerade typisch eingesetzt habe. Im Prinzip hatte ich nur ein großes iSCSI Target, das ich von meinem Windows Rechner aus gemounted und mit einer TrueCrypt verschlüsselten NTFS Partition versehen hatte.
Das nun gestartete RAID Device war allerdings nicht direkt meine iSCSI-LUN, sondern enthielt ein ext3 Filesystem. Direkt im Root gab es allerdings ein interessant aussehendes .@iscsi.img Verzeichnis. Und in der Tat enthielt es auch gut aussehende Dateien.
Ja, Dateien, obwohl ich nur eine einzige iSCSI LUN angelegt und gemounted hatte.
Die Gesamtgröße der beiden schien aber zu passen, nachdem ich keine einfache Möglichkeit fand die beiden Files in-place als ein Device zu mounten, musste ich sie eben aneinanderhängen.
Nach nicht ganz so kurzer Zeit war auch das geschafft und es wurde mal wieder spannend. Mit kpartx -av nase.img konnte ich die File inklusive ihrer Partition tatsächlich erfolgreich mappen.
Mit dem ebenfalls in grml enthaltenen tcplay versuchte ich dann die TrueCrypt Partition zu mounten und tatsächlich waren da meine Daten zu sehen 
Nachdem ich nun inzwischen zwangsläufig eine neue Storagelösung besitze mussten die Daten irgendwie kopiert werden. Zunächst versuchte ich das wieder über den Umweg einer grml-VM, die auf die Daten via CIFS Shares zugriff und dann rsync verwendete.
Im Prinzip funktionierte das auch ziemlich super, allerdings hatte ich den Eindruck, dass es Probleme mit UTF-8 Dateinamen gab und es auch nicht so besonders schnell läuft.
Ich suchte also nach Möglichkeiten das ggf. Windows-nativ zu machen. Seit Windows 7 gibt es die Möglichkeit virtuelle Disks im VHD Format zu attachen, ganz ähnlich wie Loopdevices unter Linux.
Problem war nur, dass meine Raw Disk nicht im VHD Format vorlag.
Die Konvertierung von raw nach VHD ist mit dem in QEMU enthaltenen qemu-img Tool möglich, dauerte allerdings – wie übrigens nicht wenige dieser Schritte – wieder fast einen Tag.
Da ich inzwischen leicht ungeduldig war suchte ich nach einer schnelleren Lösung.
Zunächst versuchte ich OSFMount, was tatsächlich auch erfolgreich das Image mounten konnte – allerdings war die Disk/Partition danach nicht im Windows Disk Management zu sehen und auch TrueCrypt sah sie nicht als Device.
Die Rettung war schließlich vhdtool.exe. Ein Microsoft Tool, was eine Raw Disk in VHD konvertiert, in dem es nur wenige Bytes zur Datei hinzufügt.
Leider wird es von Microsoft nicht mehr supported, daher musste ich es aus fragwürdigen Quellen im Internetz beziehen.
Nun konnte ich das Image einfach im Disk Management attachen und die Partition ganz normal in TrueCrypt mounten.
Im Endeffekt stellte sich zwar heraus, dass die paar Dateinamen, die ich als kaputt vermutete, schon immer kaputt waren. Aber ich konnte mir zumindest einbilden, dass es schneller ging.
Vielleicht mache ich in Zukunft Backups!