Externe Festplatte nur noch als RAW

sharptooth

Admiral Special
Mitglied seit
11.11.2001
Beiträge
1.766
Renomée
15
Hallo,

ein Freund hat mir eine externe Festplatte von Hitachi gegeben, die nur noch als RAW erkannt wird. Ich suche jetzt mit allen möglichen Programmen nach den Dateien (Fotos), Minitool Partition Wizzard und PC File Inspector File Recovery haben nichts gefunden. Suche jetzt mit Recuva.

Meine Frage ist aber folgende: wenn ich die Dateien wiederherstellen könnte (natürlich auf eine andere Festplatte), kann ich der externen Festplatte noch trauen und die Daten dorthin zurückspielen? Die Fotos hat mein Freund noch auf dem Laptop, wäre also nicht so schlimm, wenn ich sie nicht wiederherstellen könnte. Aber inwieweit kann man der Festplatte noch trauen? Und vor allem: woher kommt das mit RAW? Er meinte, er hätte nichts mit der Festplatte gemacht, da wäre plötzlich RAW gestanden.Von alleine kann das doch nicht vorkommen.

Sharpy
 
Nimm Testdisk bzw. Photorec :D Damit die Daten retten - und zwar BEVOR du irgendwelche Tests drüberlaufen lässt!
 
Ich lasse nochmals den PC Inspector drüberlaufen, diesmal findet er was, hatte vorher unbeabsichtigt nur nach Partitionen gesucht.

Wie gesagt, mir ging es nicht um Datenrettungstools, sondern um die Verlässlichkeit der Platte. Das mit Smart ist klar, ich schaue es mir nachher nochmals an. Aber wie kann eine HDD einfach so das Dateisystem verlieren? Hab gelesen, dass das bei einer Win Installation passieren kann, wenn man externe HDDs nicht abklemmt. Aber der Freund von mir hat bestimmt kein Windows installiert.

Sharpy
 
Kann tausend Gründe haben, u.a. auch Malware und bei einer externen Platte natürlich auch einen Defekt am Controller vom Gehäuse...
 
Das passiert auch leicht, wenn man die Platte einfach anzieht statt sie über "Hardware sicher entfernen und Medium auswerfen" abzumelden, vor allem kurz nach einem Schreibvorgang und der kann auch von einem Prozess im Hintergrund kommen. So kann es z.B. eingestellt sein, dass NTFS die letzte Zugriffszeit protokolliert und dann erfolgt bei jedem Lesezugriff auch immer ein Schreibzugriff.

Das einfache Abziehen kann 100mal gut gehen, aber einmal hat man doch Pech und die Platte ist eben RAW. Den Screen von CDI kannst Du aber trotzdem posten, der hat mit den Daten auf der Platte nichts zu tun und es ist auch wichtig zu wissen wie es um die Gesundheit der Platte steht, bevor man sich an die Datenrettung macht. Wenn da viele defekte Sektoren sind, sollte man die ganze Platte mit dem Linux tool ddrescue klonen und dann auf dem Klone die Daten mit Tools wie Testdisk, GetDataBack etc. retten, da sonst die Platte bei den viele dafür nötigen Kopfbewegungen kaputt gehen oder mehr Sektoren beschädigt werden können. Wenn eine HDD z.B. runter- oder manchmal auch nur umgefallen ist, so hat man meist nur noch wenig Zeit etwas zu retten, bevor zu ganz tot ist.
 
Hallo,

das mit dem Abziehen kann schon sein. Ich persönlich achte immer pingeligst drauf, eine Festplatte sicher zu entfernen, und wenn's nicht geht ("Ein Programm ... greift noch drauf zu...", was ich nicht identifiziere), schalte ich den PC vorher aus. Ich sag das nochmals meinem Kumpel.

Hier der CDI Screen. Sieht gut aus, die Festplatte ist ja fast wie neu :)
Ich glaube, das Argument C0 ist der Schuft. 55x ausgeschaltet, ohne sicher zu entfernen, oder?

Hitachi HDD.JPG

Sharpy
 
Möglich, die Platte ist jedenfalls gesund und nur das Filesystem ist geschädigt. Du kannst also direkt auf der Platte die Recovery Tools ausführen, aber denke daran, dass man die Dateien immer auf eine anderen Platte rettet und erst dann versucht etwas "in place" zu reparieren.
 
Ich spare mir die Mühe der Wiederherstellung. Einige Dateien habe ich wiederhergestellt, dann habe ich nochmals PCI drüberlaufen lassen, aber abgebrochen, weil es doch zu lange dauert. Wie schon gesagt, die Daten sind noch auf dem Computer vorhanden, es sind also keine verlorengegangen. Mir geht es nur darum, woran das mit dem RAW lag und ob man die Platte noch als Backupplatte nutzen kann. Das erste haben wir ja geklärt (Abziehen), das zweite scheint ja auch zu klappen, also die Platte noch weiterhin als Backup-Platte zu nutzen.

Sharpy
 
Das passiert auch leicht, wenn man die Platte einfach anzieht statt sie über "Hardware sicher entfernen und Medium auswerfen" abzumelden, vor allem kurz nach einem Schreibvorgang und der kann auch von einem Prozess im Hintergrund kommen. So kann es z.B. eingestellt sein, dass NTFS die letzte Zugriffszeit protokolliert und dann erfolgt bei jedem Lesezugriff auch immer ein Schreibzugriff.

Aber nur wenn gerade der/die MBR/GPT/Partitionstabelle geschrieben wird. Wenn normale Daten verwurschtelt werden, können maximal diese kaputt gehen. Die Partionsdaten werden in der Regel nur einmal geschrieben.
 
Korrekt - also Ursache bitte woanders suchen, falls sich das Problem nicht wiederholen soll...
 
Zuletzt bearbeitet:
Von S.M.A.R.T. nicht erkannter Plattenfehler, Defekt am Controller im externen Gehäuse, kaputtes Kabel, Defekt am Rechner, Malware, Fehler 40...
 
Dann würde ich meinem Kumpel vorschlagen, sich sicherheitshalber eine neue externe Festplatte anzuschaffen, kostet ja nicht die Welt.

Sharpy
 
Gute Idee, ebenso wie ein Malwarescan des betreffenden Rechners...
 
Zuletzt bearbeitet:
Na dann hoffe ich, das sich mein Rechner nicht angesteckt hat, wo ich die Festplatte dran angeschlossen hatte. Aber bei RAW kann ja nix "übertragen" werden.

Wieso sollte eigentlich durch Malware nur eine externe Festplatte betroffen sein und die Daten von der internen Festplatte nicht gelöscht werden?

Sharpy
 
Zuletzt bearbeitet:
Wenn normale Daten verwurschtelt werden, können maximal diese kaputt gehen.
Was eben so nicht stimmt!

Möglich, dass sollte man noch mal prüfen indem man den Rechner scannt.

sharptooth, lass Dich nicht verunsichern, die Platte ist in Ordung und Neukauf nicht zwingend nötig. Wenn die Daten auch alle noch auf dem Rechner sind, dann kannst Du eine "In Place" Reperatur ja versuchen und wenn es nicht klappt, einfach neu formatieren und gut ist.
 
Mal davon ausgehend, dass die Platte mit NTFS oder einem anderen Journaling-FS formatiert ist, dürften fehlerhafte Metadaten das Dateisystem nicht ernsthaft gefährden.
S.M.A.R.T. erkennt nur soviel, wie es seine leider oftmals mangelhafte Implementation in der Firmware der jeweiligen Platte zulässt.
Defekte Controller in externen Plattencases kommen leider sehr oft vor.
Defekte Kabel bedeuten nicht immer nur einen Wackelkontakt, sondern können sich z.B. auch in Schreib- und Lesefehlern, verursacht durch mangelhafte innere Isolierungen und dadurch verursachte Einstreuungen des Versorgungstroms in die Datenadern, äußern.
Klar ist der Hinweis auf einen Defekt am Rechner sehr unspezifisch. Er beinhaltet ja auch wiederum etliche mögliche Probleme, angefangen bei fehlerhaftem RAM bis hin zu einer einzelnen kaputten USB-Buchse.
 
Ist das Journaling denn überhaupt aktiviert gewesen? Das kann man leicht prüfen indem man eine cmd.exe öffnet und dort folgenden Befehl ausführt:

FSUTIL usn queryjournal X: (X: durch den LW-Buchstaben ersetzen)

Wer mal seine ganze Laufwerke testet wird feststellen, dass dies längst nicht bei allen der Fall ist! Das Abziehen kann also bei externen Platten durchaus zur Beschädigung des Filesystems führen, vor allem wenn in den Richtlinien hohe Geschwindigkeit statt schnelles Enfernen gewählt ist. Das Sichere Entfernen gibt es ja nicht zum Spaß!

Wenn ein Controller defekt ist, kann man auch keine S.M.A.R.T. Werte mehr auslesen und wie oft mangelhafte Implementation in der Firmware Festplatten vorkommen, kann ich nicht sagen, da ich bisher noch keine solchen gesehen habe.

Das die USB-SATA Bridgechips öfter mal kaputt gehen, ist bekannt und mir auch schon passiert. Aber dann geht meist gar nichts mehr und das bleibt dann auch so. Das ist hier aber offenbar nicht der Fall, die Platten war bei Erstellen der S.M.A.R.T. Werte ja über USB angeschlossen und von einem Wechsel des Gehäuses war nicht die Rede.

Wenn z.B. defekte Kabel Schreib- oder Lesefehler erzeugen, dann bekommt man den Fehler auch sofort gemeldet. Die ganze serielle Kommunikation, egal ob bei USB, PCIe oder SATA, ist immer mit ECC Prüfsummen abgesichert und die Wahrscheinlichkeit unentdeckter Bitfehler ist damit nun wirklich minimal, eher hat man ein gekipptes Bit im RAM. Wird ein Fehler erkannt, wird die Übertragung wiederholt, dann hat man schnell einen spürbaren Performanceverlust und wenn es gar nicht klappt, dann bekommt man eine Fehlermeldung.
 
Danke für die Hinweise soweit. Ich schlage vor, dass er die Festplatte weiter nutzt und zusätzlich noch eine weitere holt. Backup auf 2 verschiedenen Festplatten ist ja eh angeraten.

Sharpy
 
Nein, denn RAW bedeutet nicht automatisch, dass die Partitionstabelle defekt ist, es bedeutet vielmehr, dass das Filesystem defekt ist und die Metadaten von Filesystem werden durchaus dauernd überschrieben, können also schon durch unsicheres Entfernen kaputt gehen, ohne dass ein HW-Defekt vorliegt. Was eben so nicht stimmt!

Das halte ich für extrem unwahrscheinlich, dass Windows eine Partition welche als NTFS oder FAT32 in der Partitionstabelle gekennzeichnet ist als RAW anzeigt, selbst wenn Metadaten oder die Filetable defekt sind. Dazu müssten die schon komplett mit Datenmüll überschrieben werden.

Ist das Journaling denn überhaupt aktiviert gewesen? Das kann man leicht prüfen indem man eine cmd.exe öffnet und dort folgenden Befehl ausführt:

FSUTIL usn queryjournal X: (X: durch den LW-Buchstaben ersetzen)

Soweit ich das gerade lese ist das Journaling für Metadaten ist bei NTFS übrigens immer an. Das USN-Journal ist für die normalen Dateien. Also Metadaten bei NTFS sollten sich niemals durch normales Schreiben von Dateien unreparierbar zerstören lassen.
 
Schaut doch ins Datenrettungsforum bei Computerbase, da kommt es immer wieder vor, dass USB Platten plötzlich RAW sind und wenn nicht schwebende Sektoren die Ursache sind, dann erfährt man dort oft, dass die Leute die Platten auch einfach so abgezogen haben, statt sie sicher zu entfernen. Das passiert dabei eben zuweilen, wieso auch immer, da hilft das auf Journaling nichts.
 
Ja, das mag sein. Nichts desto trotz muss die Partionstabelle überschrieben werden. Wäre interessant die Gemeinsamkeiten von den Fällen zu suchen. Das wird ein Bug sein, die Frage ist nur ob in der Hardware (Festplatten-Chip, USB-Controller-Chip) oder in einem speziellen Treiber, oder eventuell so etwas wie ein Virenscanner welcher den MBR vor bösen Zugriffen "schützt". Irgendwo muss da der MBR/die Partionstabelle im Zugriff sein, oder der Controller ändert beim Abziehen den Schreib-Offset, und schreibt Müll an die falsche Stelle mit dem Reststrom.

Edit: Das einzige was eventuell sein könnte, ist, dass das NTFS $LogFile im Eimer ist. Das sollte man mit Ändern der Größe, durch z.B. "chkdisk D: /L:65537" (oder vielleicht besser gleich "chkdisk D: /L:131072"), wenn "chkdisk D: /L" 65536 (was der Default ist) anzeigt, beheben können. Danach dann ein normaler chkdsk /F.
 
Zuletzt bearbeitet:
Zurück
Oben Unten