Samsung S1 Mini 200GB unklarer Fehler

[flipsns]

Ist hier von @madmax2010 gut beschrieben -> https://www.computerbase.de/forum/threads/defekte-festplatte.2125833/#post-27779579


Cu
redjack

Ich hab endlich die Zeit gefunden und geh gerade streng nach obiger Anleitung vor.

Habe einen ausrangierten Laptop gleich mal dazu gebraucht (Ubuntu vom USB-Stick gestartet) und bin gerade beim klonen mittels ddrescue von der "defekten" S1 Mini auf /dev/sda des Laptops.

Dauer noch ca. 2 Stunden.

Nun wäre ich gern schon vorbereitet, was mich dann erwartet.

Hab ich dann ggfs. gleich direkten Zugriff auf die Daten auf /dev/sda (sofern unbeschädigt) oder ist der nächste Schritt in der Anleitung (Testdisk) auf jeden Fall obligat, um überhaupt lesbare Daten zu erhalten?

Ergänzung (18. August 2025)

Hmm, war anfangs noch recht zuversichtlich, aber dann hat er doch bei 33,5%, wie am Screenshot, abgebrochen.

Noch Ideen oder kann ich es fix abschreiben?

 

[Evil E-Lex]

Du hast ddrescue falsch benutzt. Du willst den kompletten Datenträger /dev/sdc, nicht die Partition /dev/sdc1, klonen. Wenn du nur die Partition klonst, fehlt dir auf dem Zieldatenträger die Partitionstabelle und deswegen wird dort nichts angezeigt.
Du musst von Datenträger auf Datenträger klonen, ansonsten ist das Ergebnis unbrauchbar. Der Zieldatenträger muss dazu genauso groß oder größer als der Quelldatenträger sein, das scheint bei dir aber der Fall zu sein.

Ein korrekter Befehl sähe so aus:
sudo ddrescue -d -f -n /dev/sdc /dev/sda clone.logfile
-n sorgt dafür, dass die letzte Phase, das zeitraubende Zusammenkratzen (Scraping) der letzten nicht gesicherten Sektoren, überspringen wird. -r3 kannst du weglassen, das sorgt dafür, dass alle nicht lesbaren Sektoren dreimal probiert werden. Das dauert ewig.

Deine Fehlermeldung am Ende deutet übrigens darauf hin, dass dein Quelldatenträger plötzlich nicht mehr verfügbar war. Simple Lösung: Den Quelldatenträger vom Strom trennen und neu verbinden. ddrescue dann mit obigen Befehl weiterlaufen lassen, bis alles gesichert ist. Bei Bedarf mehrfach wiederholen.

 

[flipsns]

@Evil E-Lex Vielen herzlichen Dank. Auch für mich als Laien super verständlich erklärt. Top!

Werde es bei Gelegenheit testen. Nur ist das seltsame, mir bis dato, unerklärliche Phänomen, dass es zu diesen spontanen Verbindungsabbrüchen nach ca. 30-45 Minuten kommt.

Aus- und wieder anstecken bringt dann aber nix (Platte wird vom System schlicht nicht erkannt).

Interessanterweise funktioniert es erst wieder, wenn die Platte einen Tag einfach liegen gelassen wird (vielleicht reichen auch Stunden, hab es aber meistens erst am nächsten Tag wieder versucht).

Bis zum erneuten Verbindungsabbruch nach ca. 30 - 45 Minuten.

Würde die Ursache da auch einfach nur aus Interesse gern verstehen.

Die Daten sind mir de facto eher wurscht. Seh' es aktuell mehr als Challenge und learning by doing.

 

[JumpingCat]

Würde die Ursache da auch einfach nur aus Interesse gern verstehen.

Wurden ja schon angerissen und es gibt Workarounds.

Interessanterweise funktioniert es erst wieder, wenn die Platte einen Tag einfach liegen gelassen wird

Du meinst wahrscheinlich wenn das Ubuntu neu gebootet wurde.

Aus- und wieder anstecken bringt dann aber nix (Platte wird vom System schlicht nicht erkannt).

Doppelte ID/UUID.

Bis zum erneuten Verbindungsabbruch nach ca. 30 - 45 Minuten

Weil du wahrscheinlich immer wieder bei Null anfängst und über den gleichen Fehler stolperst.
Wahrscheinlich hast du kein persistentes Logfile. Dazu kommt das fehlende oder nicht gesetzte TLER.

 

[Evil E-Lex]

Werde es bei Gelegenheit testen. Nur ist das seltsame, mir bis dato, unerklärliche Phänomen, dass es zu diesen spontanen Verbindungsabbrüchen nach ca. 30-45 Minuten kommt.

Nun, der Datenträger ist defekt. Das passiert sowas.

Aus- und wieder anstecken bringt dann aber nix (Platte wird vom System schlicht nicht erkannt).

Bist du sicher? Öffne zur Prüfung ein zweites Terminalfenster und gib dort sudo journalctl -kf ein, dann sieht du, ob der Datenträger nach dem Anstecken erkannt wird. Ob der in der GUI auftaucht, ist völlig egal, Hauptsache, der Kernel erkennt den Datenträger.

Interessanterweise funktioniert es erst wieder, wenn die Platte einen Tag einfach liegen gelassen wird (vielleicht reichen auch Stunden, hab es aber meistens erst am nächsten Tag wieder versucht).

Sollte das so sein, solltest du das Logfile clone.logfile auf einem USB-Stick, oder anderem externen Datenträger speichern, falls du ein Live-Linux nutzt und das System nicht die ganze Zeit eingeschaltet lassen willst.

 

[flipsns]

Du meinst wahrscheinlich wenn das Ubuntu neu gebootet wurde.

Müsste ich ausprobieren.

Es ist so, dass die Status-LED der Platte nicht mehr blinkt, sondern eben durchgehend leuchtet, wenn die Platte plötzlich vom System nicht mehr erkannt wird. Und nach dem Aus- und wieder anstecken läuft sie zwar an, aber die LED leuchtet durchgehend und System erkennt sie nicht wieder. Aber könnte jetzt nicht beschwören, ob ein Neustart dazwischen stattgefunden hatte.

Doppelte ID/UUID

Musste ich mal googlen. Aber was wäre die Lösung? Jedesmal System-Neustart?

Dazu kommt das fehlende oder nicht gesetzte TLER.

Wie setzt man das?

 

[Evil E-Lex]

Doppelte ID/UUID.

Das möchte ich bezweifeln. Ich habe unzählige Datenträger während der Datensicherung vom Strom getrennt und neu verbunden. Die UUIDs waren dabei nie ein Problem. Mag vielleicht für die Desktopumgebung ein Problem sein, dem Kernel ist das egal.

 

[flipsns]

Sollte das so sein, solltest du das Logfile clone.logfile auf einem USB-Stick, oder anderem externen Datenträger speichern, falls du ein Live-Linux nutzt und das System nicht die ganze Zeit eingeschaltet lassen willst.

Achja, geht auch eine eigene Partition? Hab eine kleine Partition am Laptop für das Logfile jetzt eingerichtet.

Aber wenn ich will, dass ddrescue dann da weitermacht, wo der Abbruch kam, muss ich die Syntax des Befehls eigentlich ändern oder einfach exakt genauso wieder im Terminal eingeben?

 

[Evil E-Lex]

Aber könnte jetzt nicht beschwören, ob ein Neustart dazwischen stattgefunden hatte.

Das solltest du allerdings wissen. Schließlich sitzt du vor dem System, nicht wir.

Ergänzung (20. August 2025)

Aber wenn ich will, dass ddrescue dann da weitermacht, wo der Abbruch kam, muss ich die Syntax des Befehls eigentlich ändern oder einfach exakt genauso wieder im Terminal eingeben?

Du musst dann den Pfad zum Logfile anpassen. So wie oben im Screenshot landet das Logfile im Homeverzeichnis des Nutzers vom Livesystem. Das ist nach einem Reboot natürlich nicht mehr vorhanden, da es nur im RAM existiert.

Ergänzung (20. August 2025)

Achja, geht auch eine eigene Partition? Hab eine kleine Partition am Laptop für das Logfile jetzt eingerichtet.

Und das geht natürlich nicht, wenn du von Datenträger auf Datenträger klonen willst. Es sei denn, dein Laptop hätte zwei Datenträger.

 

[flipsns]

Das solltest du allerdings wissen. Schließlich sitzt du vor dem System, nicht wir.

Ja, teste ich gleich wenn ich wieder daheim bin.

Tut mir leid, aber hatte darauf nicht explizit geachtet, weil ich sehr sicher war, dass ausschließlich die Platte selbst, unabhängig von System-Neustarts, das Problem ist.

Dann probier ich es auch mit deinem Befehl, ob die Platte eventuell doch vom Kernel erkannt wurde. Hatte bisher "lsblk" genutzt, da erschien sie jedenfalls nicht.

Ergänzung (20. August 2025)

Und das geht natürlich nicht, wenn du von Datenträger auf Datenträger klonen willst. Es sei denn, dein Laptop hätte zwei Datenträger.

Ah ok. Versteh langsam. Ok, dann muss ich mir was überlegen. Hab nur 2 USB Anschlüsse (an einem Ubuntu, am anderen defekte Platte, ist ein recht alter Laptop). Aber gibt noch einen SD-Karten Slot. Dann nehm ich den ggfs. für das Logfile.

 

[Evil E-Lex]

lsblk passt grundsätzlich. Mein Befehl gibt das fortlaufend aktualisierte Kernellog aus. Damit siehst du, ob überhaupt etwas passiert, wenn du den Datenträger neu verbindest.

 

[flipsns]

sudo journalctl -kf

Hat mal die Infos im Anhang ausgeworfen.

Ich mach dann im Laufe des Abends den Klonversuch mit deiner Syntax.

 

[flipsns]

Ok, also diesmal war nach 47 min. der spontane disconnect:

und

sudo journalctl -kf

hat dann das ausgeworfen, egal ob abhängen oder anschließen der Platte. Werde es jetzt mit Neustart des Ubuntu und Fortsetzen an der Stelle des Abbruchs versuchen.

Ergänzung (20. August 2025)

Ok, Ubuntu Neustart bringt's und die Platte wurde in der Tat wieder erkannt!

Hab dann natürlich gleich die Fortsetzung versucht, hat auch für 2 min 41 sek. funktioniert 😆, dann kam leider gleich wieder der Fatal Error.

Werd's noch ein paar Mal versuchen mit dem Ubuntu-Neustart. Aber dann lass ich's wohl bleiben.

Schade, fand die Challenge und den Erfahrungsgewinn mit ddrescue recht interessant und spannend.

Danke für alle Bemühungen, insbesondere Evil E-Lex

 

[flipsns]

Ok, zu meiner Überraschung hat es mit einigen Neustarts doch noch ganz gut funktioniert.

Bin bei 99,98% aber gegen Ende tut sich jetzt irgendwie nix mehr.

Muss ich die 100% überhaupt "schaffen" oder ist das Klonen quasi sozusagen "inkrementell" und dann fehlen mir halt 0,02%, aber eventuell sind die restlichen Daten erfolgreich geklont oder bringt das ganze Prozedere nix, wenn man nicht 100% schafft?

 

[JumpingCat]

Es hat wegen der Persistenz so gut funktioniert.

Ob du die letzten Prozente brauchst, können wir hier nicht sagen. Vielleicht liegen da Daten drin oder auch nicht. Was passiert denn wenn du die Daten rauskopierst? Gibt es da Fehler bei den Löchern bzw. fehlerhafte Daten?

Wenn du dich an die letzten Prozente machen willst, dann beobachte die smart Werte. Es kann sein das die stark steigen, dann. Das wäre dann der Fall wo man, wenn die Daten wichtig wären, das einem professionellem Datenretter übergibt.

 

[flipsns]

Es hat wegen der Persistenz so gut funktioniert.

Ob du die letzten Prozente brauchst, können wir hier nicht sagen. Vielleicht liegen da Daten drin oder auch nicht. Was passiert denn wenn du die Daten rauskopierst? Gibt es da Fehler bei den Löchern bzw. fehlerhafte Daten?

Soweit bin ich noch nicht. Ich warte noch bis ddrescue abbricht oder die Platte sich wieder disconnected.

Aber wollte eh auf den nächsten Schritt eingehen. Wenn ich jetzt dann fertig bin mit ddrescue mounte ich sda und sollte dann schon zumindest Ordnerstrukturen sehen oder stell ich mir das zu easy vor und da müssen noch weitere (zwischen-) Schritte folgen?

 

[JumpingCat]

Der richtige Weg wäre ein Snapshot oder Kopie von der sda Datei zu machen und diesen dann zu mounten. Weil wenn du was versuchst zu reparieren, etc, dann hast du sonst kein rückgängig.

Du kommst jetzt weiter mit mount, testdisk/photorec.

 

[flipsns]

@JumpingCat Aber eine image-Datei sollte doch gar keine auf sda liegen weil ich den Befehl ja zum direkten klonen, unter Umgehung eines image-files, gesetzt habe. Meine laienhafte Vorstellung wäre gewesen, dass ich, wenn ich sda jetzt mounte, daher eine 1:1 Kopie des defekten Datenträgers habe, unabhängig davon, ob die Daten darin dann grundsätzlich defekt sind oder nicht. Oder?

 

[redjack1000]

@JumpingCat

Da eine DisktoDisk Kopie erstellt wurde, ist ein Klon von /dev/sda sinnvoll.

Wenn der TE volles Risiko gehen möchte, einfach /dev/sda mounten und schauen was passiert.

CU
redjack

 

[JumpingCat]

Moment, du hast jetzt die ganze Festplatte mit Partitionen geclont und zwar auf eine andere Festplatte. Sehr schlechte Idee. Du hast jetzt erstmal ein kaputtes Disk Layout weil das Ziel hardwaretechnisch eine andere Größe hat. Recovery an einer Kopie des Klons kannst du jetzt vergessen. Du kannst kein. Snapshot machen. Außerdem verbrauchst du so extrem viel Speicherplatz. Ebenso ein erneutes Klonen weil die aktuelle Zielfestplatte sicherlich auch Daten hatte und die jetzt nach dem aktuellen Clone kommen, d.h. testdisk und photorec könnte auch "spaßig" bis "herausfordernd" werden. Herausforderend weil Backups von der Partitionierung am Ende der Platte als Backup liegen, aber das jetzt technisch einen anderen Platte ist und da falsche Informationen stehen. photorec würde auch über die ganze Platte recovern.