Für die Nachwelt möchte ich noch grob mein Vorgehen dokumentieren, vielleicht erspart es dem ein oder anderen bei einem ähnlichen Problem ein paar unnötige Fehler.
Die Platte (2,5 Zoll SATA, 1 TB) war bereits aus ihrem Gehäuse ausgebaut. Zur Diagnose habe ich sie direkt in einem Rechner am SATA-Port des Mainboards angeschlossen. Zwar habe ich auch diverse USB-Adapter, aber zusätzliche Controller und Adapter machen die Analyse weder schneller noch zuverlässiger. Den Rechner habe ich mit Grml Live Linux gebootet. Grml hat auch einen Forensik-Modus, dieser wäre vielleicht auch die sinnvollste Wahl gewesen; ich habe aber weder Erfahrung damit, noch hatte ich mich dazu eingelesen, also habe ich Grml ganz normal gestartet. Man muss sich im klaren sein, dass der Kernel hier auf jeden Fall schon mit der Platte kommunizieren will - um das Gerät an sich zu erkennen und auch um z.B. die Partitionstabelle einzulesen.
Beim Start des Rechners hat die Platte keine auffälligen oder ungewöhnlichen Geräusche gemacht, schonmal ein gutes Zeichen. Zuerst habe ich mich mit [m]dmesg[/m] versichert, dass keine Meldungen auf Probleme mit der Kommunikation zur Platte an sich hindeuten. Alles war normal. Ansonsten hätte man hier ggf. schon überlegen müssen wie wichtig die Daten sind und ob man das Ganze nicht lieber an ein Datenrettungsunternehmen übergibt. Mit [m]lsblk[/m] habe ich mich überzeugt, dass die Platte normal im System sichtbar war.
[m]smartctl -H /dev/sdb[/m] zeigte an, dass die Platte sich selbst für voll funktionsfähig hielt, genauere Daten gab’s mit [m]smartctl --all /dev/sdb[/m]. Welche Werte hier hilfreiche Informationen liefern kommt ein bisschen auf das Modell der Platte an. Erfahrungswerte gibt’s z.B. im Blog von Backblaze. Bekommt man hier die Meldung [m]SMART overall-health self-assessment test result: FAILED![/m] oder findet kritische Werte, sollte man sich überlegen, ob man mit eigenen Wiederherstellungsversuchen die Situation ggf. verschlimmern möchte oder sich lieber gleich professionelle Hilfe holt.
Im vorliegenden Fall war hier alles ok. Man kann die Platte jetzt noch veranlassen eine genauere Selbstanalyse zu starten und sich das Ergebnis nach ein paar Stunden ansehen. Dies macht meiner Meinung nach aber nur Sinn, wenn es darum geht, ob man die Platte in Zukunft weiterverwenden will. Steht die Datenrettung im Vordergrund, sollte man IMHO zuerst versuchen den Inhalt der Platte zu duplizieren.
Jetzt sollte man ein komplettes Image der Platte erstellen. D.h. man versucht möglichst nur einmal über die komplette Platte zu lesen, um zumindest den jetzigen Zustand wiederherstellen zu können, falls bei der weiteren Analyse etwas schief geht. Meiner Meinung nach ist dies der wichtigste Schritt, auch wenn dies i.d.R. mehrere Stunden kostet.
Ich habe also ein komplettes Image der Platte erstellt. Dazu hatte ich noch eine größere Platte mit ausreichend freiem Platz im Rechner. Dieses Image habe ich nicht mit [m]dd[/m] erstellt, denn [m]dd[/m] wird beim ersten ernsthaften Lesefehler abbrechen. Stattdessen habe ich GNU ddrescue verwendet (ACHTUNG, nicht mit [m]dd_rescue[/m] verwechseln). [m]ddrescure[/m] hat mehrere Vorteile. Zum einen gibt es bei Fehlern nicht sofort auf. Andererseits beißt es sich auch nicht an Fehlerhaften Sektoren fest, diese werden zunächst übersprungen und es wird versucht, soviel wie möglich der unbeschädigten Bereiche zu kopieren. Sektoren mit Lesefehlern werden erst in weiteren Durchgängen weiter eingegrenzt und erneut probiert. Außerdem sollte man nicht nur ein Ziel-Device oder eine Ziel-Datei sondern auch ein Log-File erstellen bzw. mit angeben. Dies ermöglicht einem, [m]ddrescue[/m] nach einem Abbruch wieder an der alten Stelle weitermachen zu lassen, aber auch sich hinterher eine Übersicht der Fehlerhaften Bereiche anzuzeigen (z.B. mit ddrescueview). Ein weiterer Vorteil ist die Statusanzeige von [m]ddrescue[/m], mit ihr kann man gut den Fortschritt verfolgen und sieht wieviele Fehler bisher aufgetreten sind sowie welche Datenmenge in Folge (noch) nicht gelesen werden konnte. Im Extremfall kann man hier die “Notbremse” ziehen, also abbrechen und eigene Versuche einstellen.
Zum Glück gab es bei dieser Platte keine Fehler. Die Platte ist also mechanisch ok, Probleme sind offenbar in den Datenstrukturen (Partitionstabelle und/oder Dateisystem).
Um die Platte zu schonen habe ich den Rechner erstmal heruntergefahren und sie wieder ausgebaut. Für alles Weitere habe ich das Plattenimage herangezogen. Als nächsten Schritt empfehle ich hier, sich eine Checksumme von der Image-Datei anzulegen. Ich habe dies mit [m]sha1sum[/m] getan. Wiederholt man diesen Schritt am Ende seiner Analyse, kann man so leicht prüfen, ob man dabei das Image-File modifiziert hat oder nicht (wichtige Lektion aus der Vorlesung “Forensische Informatik” vom LS1!) Wenn man ganz vorsichtig sein will kann man jetzt noch eine Kopie der Image-Datei anlegen. Ich habe für Zugriffe auf das Image stattdessen ein Read-Only Loopback-Device angelegt ([m]losetup -r[/m]). Falls man doch Schreibzugriffe braucht, kann man wie gesagt eben noch ein Backup von der Image-Datei erstellen oder man könnte sich in das Snapshot-Feature des Linux Device-Mappers einlesen oder die Image-Datei in eine Virtual Machine mit Snapshot-Feature einbinden.
Der bisherige Teil war nur eine vorsichte Voranalyse und eine aufwändige aber wichtige Vorsichtsmaßnahme, die eigentliche Analyse ging erst jetzt los:
Laut Partitionstabelle gab es eine ca. 120 GB große NTFS/exFAT Partition (beide Partitionstypen haben die selbe ID). Diese Partition lies sich auch als NTFS mounten, enthielt aber bis auf Standardverzeichnisse nichts. Laut lilly hätte sich jedoch eine 1TB große exFAT Partition finden müssen. Ich habe dann TestDisk ausprobiert. Testdisk hat sich erstmal darüber beschwert, dass es keine Schreibrechte auf mein Loop-Device hat - dies finde ich schon sehr bedenklich. Ein Datenrettungstool sollte IMHO Read-Only Rettungs-Operationen von Reparatur-Versuchen deutlicher abgrenzen. Mit Testdisk kann man versuchen verloren gegangene Partitionstabellen-Einträge zu rekonstruieren, gelöschte Dateien wiederherzustellen usw… bei meinen ersten Versuchen lies es sich aber von der seltsamen NTFS-Partition verwirren. Daher habe ich mich nicht weiter mit dem Tool auseinandergesetzt.
Schließlich habe ich einfach ohne spezielle Tools sondern nur mit einem Hex-Editor auf der Platte herumgesucht und zum Glück neben dem NTFS-Header an anderer Stelle noch einen exFAT Header gefunden. Anhand dessen Adresse habe ich die Startposition der Partition berechnet und dann auf der echten Platte mit [m]sfdisk[/m] eine neue Partitionstabelle geschrieben. Anschließend konnte lilly wieder auf ihre wichtigste Datei zugreifen und auch der Rest sah gut aus.
Was hatte es nun mit der NTFS-Partition auf sich? Nun, vorher hatte sich jemand anders mit der Datenrettung versucht. Die Timestamps im NTFS fallen in diesen Zeitraum. Ich kann nun schlecht rekonstruieren in welchem Zustand die Platte war als das ursprüngliche Problem auftrat. Vielleicht war die Partitionstabelle ganz weg und jemand hat z.B. auch mit Testdisk oder einem anderen Tool versucht diese zu rekonstruieren. Zum Glück wurde dabei der exFAT-Header nicht beschädigt, in dem Fall wäre meine Analyse deutlich schwieriger geworden. In wie fern durch diese fälschlich wiederhergestellte NTFS-Partition Daten in der eigentlichen Partition doch beschädigt wurden habe ich nicht untersucht (die wichtigste Datei war zumindest ok). Auf jeden Fall zeigt es aber, dass der Schritt mit dem Image/Backup nicht ausgelassen werden sollte!