Datenrettung bei externer Festplatte

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

Datenrettung bei externer Festplatte
Hey,
ich weiß leider nicht genau in welches Forum das gehört, aber ich wollte mal fragen, ob sich hier jmd mit Datenrettung auskennt und bereit wäre mir zu helfen.

Meine externe Festplatte hatte vermutl. einen Kurzschluss und jetzt möchte mein PC sie jedes mal, wenn ich sie anschließe neu formatieren. Hat jmd eine Idee, wie ich meine Daten noch retten kann?

LG


Soweit ich weiss koennen die Admins den Thread aber nachtraeglich verschieben.

Beim eigentlichen Thema kann ich dir nicht helfen, sorry ^^


Selber hab ich da auch keine Ahnung von aber vielleicht hilft dir dieser Artikel oder dieses Video weiter.

1 „Gefällt mir“

Wenn die Festplatte sicher keinen mechanischen Schaden hat: aus dem externen Gehäuse ausbauen, in den PC einbauen und schauen obs davon besser wird. Auf jeden Fall mal ein Abbild mit ddrescue oder so machen.
Falls mechanischer Schaden: Finger weg! Falls Geld vorhanden an Profis schicken.

2 „Gefällt mir“

Wichtige Daten?

Ja: Nichts selber ausprobieren und professionelle bezahlte Hilfe suchen. Kenne da jetzt aber keine Namen die ich dir nennen könnte.

Nein: Festplatte ausbauen und in den PC direkt einbauen oder aber USB-Adapter für Festplatte (z.B. ORICO 6518US3).
Wenn dann das gleiche Problem auftritt, ist dann wahrscheinlich doch etwas direkt an der Festplatte passiert.
Dann könnte man wie bulsa erwähnt hat ddrescue oder ähnliche Programme zum zwischenspeichern benutzen und dann mal ein paar Tools drauf loslassen. (So schlimm wars bei mir bisher aber noch nicht, deshalb kann ich dir da keine spezifischen Tools nennen).

2 „Gefällt mir“

Im Prinzip kann ich bulsa und nakami zustimmen.

Wenn du die Chance maximieren musst, wieder an die Daten heran zu kommen, z.B. weil darunter die einzige Kopie deiner Masterarbeit ist, dann bleibt nur der Gang zu einem seriösen Datenrettungsunternehmen. Ich weiß nicht, wie gut sie wirklich sind, aber spontan einfallen würde mir: krollontrack.de/datenrettung/ (der Diagnosepreis liegt dort wohl bei ca. 110 EUR und aufwärts, dazu kommen dann noch Kosten für die eigentliche Wiederherstellung und ggf. einen Ersatzdatenträger)

In dem Fall gilt auch: Keine Weiteren Versuche unternehmen, nicht an mehr an den Strom und/oder Rechner anschließen, schonmal stoßsicher lagern/verpacken.

Falls das dein Budget sprengt, bzw. du bereit bist, ein gewisses Risiko einzugehen, könnte man auch vorsichtig noch ein paar Dinge analysieren.

Grundsätzlich gilt aber: Jeder zusätzliche Analyseschritt / Rettungsversuch kann dazu führen, dass die eigentlich richtige Lösung nicht mehr funktioniert. Weitere Versuche können also unter Umständen dazu führen, dass auch die professionelle Wiederherstellung schwerer oder gar unmöglich wird.

Solltest du dich nun trotzdem entscheiden, lieber zuerst die nichtprofessionelle Variante auszuprobieren, lass es jemanden machen, der zumindest schon Erfahrung mit dem Thema hat (und genug eigene Daten riskiert hat). Denn auch da gibt’s so einige Fallstricke und unterschiedlich risikoreiche Vorgehensweisen. Z.B. gibt es nicht nur ddrescue sondern auch dd_rescue (meiner Meinung sollte man letzteres meiden, habe damit schon schlechte Erfahrungen gemacht); man sollte auch nie versuchen das Problem auf der ursprünglichen Platte zu beheben (z.B. wenn “nur” logische Dateisystemfehler vorliegen), sondern immer ein direkt-Backup auf eine zweite, mindestens genau so große Platte anstreben, ggf. sind wichtige Dateien zu priorisieren, aber die Anzahl der Lesezugriffe auf die betroffene Platte sind zu minimieren und Schreibzugriffe sind komplett zu vermeiden. Falls du möchtest kannst du mal (nach Absprache) in der FSI vorbeikommen und ich kann mir deine Platte ansehen, aber auch bei mir gelten alle Warnhinweise die ich und andere hier schon geschrieben haben.


Habe ich mit einer Festplatte die jemand auf Fließenboden runterfallen lassen hat schon mal ausprobiert. Die Festplatte hatte einen Headcrash und wurde danach noch ausführlich ausprobiert (nahezu die gesamte Oberfläche im Eimer), die haben trotzdem noch ein Inhaltsverzeichnis rausbekommen und gesagt: diese 5% der Daten könnten wir noch retten wenn Sie wollen. Fazit: Das Geld definitiv wert, aber kaputt ist trotzdem kaputt.


Also erstmal vielen Dank für’s verschieben und für die ganzen Antworten.

Also aus dem Gehäuse ausgebaut hab ich sie bereits, da der Kontakt kaputt war und mein PC sie sonst gar nicht mehr erkannt hätte. Ein paar der Daten konnte ich mit Photo rec retten, allerdings fehlen mir noch viele der wichtigen Dokumente. Also wenn das möglich ist, dass ich in der FSI vorbeikomme und jmd sich meine Platte anschaut, wäre das wirklich super. Hättest du evtl diese Woche noch Zeit?


Wie groß ist die Platte? Hast du eine zweite, die mind. genau so groß ist?


Probier mal testdisk


Die Festplatte ist ein Terabyte groß, eine zweite besitze ich leider nicht. Danke für den Tipp mit testdisk, ich werd’s mir mal ansehen.


Testdisk wäre vielleicht auch bei den Tools dabei, die für Rettungsversuche ausprobieren würde, aber erst nachdem ich ein Vollbackup vom vorherigen Zustand erstellt hätte.

Zum einen sollte man erst einmal klären, ob nur Dateisystemstrukturen beschädigt sind, oder dies eine Folge eines physikalischen Problems ist. In letzterem Fall macht man mit Testdisk unter Umständen mehr Lesezugriffe als nötig und verschlechtert so seine Chancen.

Zum anderen scheint Testdisk nicht nur lesend Dateien wiederherzustellen sondern hat wohl auch Reparatur-Optionen, also Schreibzugriffe. Fehlversuche hier (im Sinne von falscher Ansatz) sorgen ggf. für schlechtere Voraussetzungen beim späteren, eigentlich richtigen Ansatz.

Von daher rate ich zur Vorsicht.

1 „Gefällt mir“

Alles klar, danke für die Infos.

Wäre es denn möglich, dass ich diese Woche noch in der FSI vorbeischaue? Ehrlich gesagt, wäre es mir lieber, wenn sich das mal jmd ansieht, der mehr Ahnung hat als ich, da ich nichts beschädigen möchte.


Du kannst morgen mal zw. 13 und 16 Uhr im FSI-Zimmer oder im CIP2 nach mir fragen, dann kann ich mir die Platte mal ansehen und weiter eingrenzen, was eine sinnvolle weitere Vorgehensweise ist.


Erstmal ein ganz ganz großes dankeschön an dich, dass du dir da zeit nimmst. Leider hab ich morgen von 13 - 18 uhr eine pflicht veranstaltung. Würde es denn evtl. danach oder mittwoch/donnerstag gehen?


Evtl. Mittwoch ab 16:00 oder Donnerstag ab 14:30.


Super, vielen dank :slight_smile: dann würde ich mittwoch gegen viertel nach 5 vorbeischauen, wenn das passt


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!

17 „Gefällt mir“

By the way:

Keine Ahnung mehr wo ich das aufgeschnappt habe, aber nehmt es als Anlass um euere aktuelle Backupstrategie zu überdenken/überprüfen. :wink:

5 „Gefällt mir“