Leider hat es (mal wieder) eine WD Green erwischt bei mir. Backup ist zwar vorhanden aber schon einige Wochen alt und daher würde ich gerne an die zwischenzeitlich geänderten / erstellten Dateien kommen. Die NTFS-Platte hat einige defekte Sektoren und kann unter Windows nicht mehr eingebunden werden. Unter Linux schlägt das mounten (auch als ro!) ebenfalls fehl. Ich habe mich an dieser Anleitung für ddrescue orientiert: http://www.cgsecurity.org/wiki/Besch%C3%A4digte_Festplatte#Die_beste_Methode:_Antonio_Diaz.27s_.27ddrescue.27 Den Umweg über ein Image habe ich mir gespart und als Quelle die nichtlesbare Partition sdb2 angegeben und als Ziel eine externe 4TB Platte (sde1). Also: sudo ddrescue -B -n /dev/sdb2 /dev/sde1 rescued.log Beim Auslesen traten auch nur insgesamt 4 Fehler auf und die fehlerhafte Datenmenge betrug auch nur wenige kB. Als am ddrescue beendet war wollte ich die externe Platte mounten und.... nichts. Die Platte ist leer! Was mache ich hier falsch?
Könntest du die rescued.log und die Ausgabe von folgenden Kommandos posten?
1 | |
2 | |
Ich habe den Vorgang nochmal angestoßen, da ich dachte vorher sei irgendwas schiefgelaufen. Hier der derzeitige Stand:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
141 | |
142 | |
143 | |
144 | |
145 | |
146 | |
147 | |
148 | |
149 | |
150 | |
151 | |
152 | |
153 | |
154 | |
155 | |
156 | |
157 | |
158 | |
159 | |
160 | |
161 | |
162 | |
163 | |
164 | |
165 | |
166 | |
167 | |
168 | |
169 | |
170 | |
171 | |
172 | |
173 | |
174 | |
175 | |
176 | |
177 | |
178 | |
179 | |
180 | |
181 | |
182 | |
183 | |
184 | |
185 | |
186 | |
187 | |
188 | |
189 | |
190 | |
191 | |
192 | |
193 | |
194 | |
195 | |
196 | |
197 | |
198 | |
199 | |
200 | |
201 | |
202 | |
203 | |
204 | |
205 | |
206 | |
207 | |
208 | |
209 | |
210 | |
211 | |
212 | |
213 | |
214 | |
215 | |
216 | |
217 | |
218 | |
219 | |
220 | |
221 | |
Das sieht eigentlich gut aus...
Hi, deine Festplatte hat ein sogenanntes Slow-Response problem. Solche Festplatten haben wir hier relativ oft im Labor. Es ist relativ unwahrscheinlich, dass du mit Haushaltsmitteln da machen kannst, da es ein Problem der Firmware ist. Hast du noch sehr wichtige Daten auf der Platte?
Hi Dimitri, in der Tat hat die defekte Platte den Rechner sehr langsam gemacht =) Wobei das kopieren der Platte mit ddrescue flott geht (~130 MB/s). In der Ereignisanzeige war auch auch ein entsprechender Eintrag, dass immer wieder versucht wurde von der Platte zu lesen. Hier wird auch etwas in diese Richtung diskutiert: https://forum.hddguru.com/viewtopic.php?f=1&t=32175&; Meinst du dieses Problem? Die Daten sind größtenteils verzichtbar, da Backup vorhanden. Aber es wäre schon gut den nicht gesicherten Teil zurück zu bekommen. Mehr als den Preis für die externe 4TB HDD die ich jetzt gekauft habe wollte ich nicht ausgeben. Aber vielleicht ist ja doch was zu machen?! Was macht dich so sicher, dass es daran (Firmware) liegt? Unter dem Link werden ja auch einige möglich Lösungen genannt (WD Marvel, mod32patch, hddsupertool). Wenn es wirklich an der Firmware liegt, dann kann ich mir ja Images und Kopien sparen, richtig? Da ist dann nur was an der Originalplatte zu machen...
Sebastian R. schrieb: > Unter dem Link werden ja auch einige möglich Lösungen genannt (WD > Marvel, mod32patch, hddsupertool). Ich kenne diese Tools jetzt leider nicht. Aber alle, die ich kenne (und wir auch), die Datenrettung anbieten, nehmen PC-3000 dafür. Das ist eine Hardware-Software Kombination, mit der man auf die sogenannte Service Area der Festplatte zugreifen kann. Sebastian R. schrieb: > Wenn es wirklich an der Firmware liegt, dann kann ich mir ja Images und > Kopien sparen, richtig? Da ist dann nur was an der Originalplatte zu > machen... Einmal ganz grob zum Problem: Deine Festplatte ist kein dummes Speichermedium sondern selbst ein eigener Computer, auf dem Software läuft. Diese Software befindet sich auf der Festplatte in der sogenannten SA (Service Area). Wenn deine Festplatte mal einen defekten Sektor findet, dann wird dieser in die G-List eingetragen. Diese Liste wächst mit der Zeit, bis sie irgendwann voll ist bzw. überläuft. Dann tritt dieser Fehler auf, dass die Festplatte nur sehr langsam reagiert. Das ganze lässt sich mit entsprechenden Tools sehr einfach reparieren, vorausgesetzt ist allerdings, dass ein Nutzer nicht zu viel Schaden angerichtet hat. Wieviele Daten in GB sind es denn die du brauchst? Und wo kommst du her?
Gast
#4699360
Sebastian R. schrieb: > Als am ddrescue beendet war wollte ich die externe Platte mounten > und.... nichts. Die Platte ist leer! Wenn sich das original nicht einbinden laesst gibt es keinen Grund anzunehen das eine Kopie davon es auf einmal taete. Geschickter waere es wohl in ein Image also eine Datei zu kopieren, wenn auf der Platte aber sonst nichts drauf ist geht das nat auch so. Jetzt musst du eben probieren ein Programm in Stellung bringen das NTFS reparieren und z.B. die partitionstabelle wieder zusammenflicken kann, testdisk, gibts ja auch zum unter linux ausfuehren, sollte das koennen. http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step files from NTFS partition since version 6.11. http://www.cgsecurity.org/wiki/Undelete_files_from_NTFS_with_TestDisk
Es sieht für mich erstmal nicht so aus, als ob beim etwas schief gelaufen wäre. Das dürfte ziemlich aufwendig werden. Ich würde den Kopiervorgang nicht noch mehrmals wiederholen, das Resultat könnte sich verschlechtern. Wenn das ddresque durchgelaufen ist, poste das rescued.log nochmal. Was für Daten brauchst du denn von der Festplatte? Falls du nur einige Bestimmte Dateien brauchst, könnte man eventuell gezielt nach diesen suchen. Ansonsten wüsste man vermutlich das Dateisystem wiederherstellen, und dafür halte ich mit nur eine Kopie für ziemlich riskant. Ich denke die Daten in eine .img Datei zu kopieren wäre sinvoller gewesen, diese sind einfacher Weiterzugverwenden und je nach Dateisystem weniger Fehleranfällig. Wenn ich eine Kopie davon hätte, könnte ich versuchen die Daten selbst wiederherzustellen.
Dimitri R. schrieb: > Ich kenne diese Tools jetzt leider nicht. Aber alle, die ich kenne (und > wir auch), die Datenrettung anbieten, nehmen PC-3000 dafür. Das ist eine > Hardware-Software Kombination, mit der man auf die sogenannte Service > Area der Festplatte zugreifen kann. Das setzt leider, wie du schon sagst, spezielle H/W voraus. Dimitri R. schrieb: > Wenn deine Festplatte mal einen defekten Sektor findet, dann wird dieser > in die G-List eingetragen. Diese Liste wächst mit der Zeit, bis sie > irgendwann voll ist bzw. überläuft. Dann tritt dieser Fehler auf, dass > die Festplatte nur sehr langsam reagiert. Das entspricht auch in etwa dem verlinkten Thread bzw. einer Aussage darin: "If the drive is extremely slow to respond on all sectors (not just the bad ones) it could be a firmware glitch related to the bad sector re-allocation which makes the drive slow down until it eventually stops responding completely. The firmware fix is relatively easy if you have access to any firmware tools like PC-3000, MRT Tools, DFL Tools, or DeepSpar Disk Imager. Might also be possible with certain software I'm told, though I've never tried it since I've never had to do it that way. I would try ddrescue and just see what sort of result you're getting. Here's a tutorial I've written that might help: https://www.data-medics.com/forum/how-t ... -t133.html See what sort of read speeds you get. If it's just bad sectors you should see some times where it's able to read at a pretty good speed (like 30+ Mb/s). If it's consistently reading at 1Mb/s or less, probably needs the slow responding FW fix. " Da ich aber mit ddrescue keine Geschwindigkeitsprobleme feststellen konnte und auch die SMART-Werte keine astronomisch hohe Anzahl an defekten Sektoren zeigen, frage ich mich ob das wirklich der slow-response Problematik entspricht. Da scheint ja das Hauptmerkmal eine durchgehend niedrige Geschwindigkeit zu sein.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
Dimitri R. schrieb: > Wieviele Daten in GB sind es denn die du brauchst? Und wo kommst du her? Gute Frage, da müsste ich dann beide Partitionen (defekte & Backup) mit einander vergleichen. Dürfte aber ein hoher zweistelliger Bereich sein. Die Platte war fast randvoll. Ich komme aus Hessen. Daniel A. schrieb: > Ich denke die Daten in eine .img Datei zu kopieren wäre sinvoller > gewesen, diese sind einfacher Weiterzugverwenden und je nach Dateisystem > weniger Fehleranfällig. Das kann ich ja noch tun (von der externen Platte). Daniel A. schrieb: > Ansonsten wüsste man vermutlich das Dateisystem > wiederherstellen, und dafür halte ich mit nur eine Kopie für ziemlich > riskant. 3TB-Images sind leider nicht so handlich. Aber wie wolltest du das denn anstellen? Mit Testdisk? R-Studio? Daniel A. schrieb: > Wenn das ddresque durchgelaufen ist, poste das > rescued.log nochmal. Mache ich.
Sebastian R. schrieb: > 3TB-Images sind leider nicht so handlich. Aber wie wolltest du das denn > anstellen? Mit Testdisk? R-Studio? Weder noch. Ich mach sowas gerne manuell. Wenn ich genug Informationen zu einer Datei habe kann ich manuell danach suchen. Wenn ich z.B. einen Ausschnitt einer Textdatei kenne, kann ich danach im Image suchen. Wenn ich Sektoren kenne, die nicht kopiert werden konnten, kann ich versuchen herauszufinden wozu diese gehören. Ich kann versuchen die Daten manuell zu Interpretieren, und Zusammenhänge herstellen, die eine Software nicht könnte. Die Schwierigkeit dabei ist natürlich herauszufinden, welche Daten relevant sind, dafür brauche ich dann wieder diverse eigene Tools, denn ich kann nur sehr wenige Daten selbst Interpretieren.
Sebastian R. schrieb: > nichtlesbare Partition sdb2 angegeben und als Ziel eine externe 4TB > Platte (sde1). Also: sudo ddrescue -B -n /dev/sdb2 /dev/sde1 rescued.log Nach meinem Linux-Verständnis hast Du auf Partition 1 der externen Platte geschrieben, nicht auf die Platte. Das ist ein wichtiger Unterschied... In Deiner Fehlermeldung sehe ich gar keinen "read-only"-Parameter. Dimitri R. schrieb: > Hi, > > deine Festplatte hat ein sogenanntes Slow-Response problem. Solche Dimitri R. hat ein ein sogenanntes low-Portemonnaie-Problem. Das tritt immer dann auch, wenn die Scheinqueue fast leer ist. :) Ganz im Ernst: Seine Diagnose bei Deiner gezeigten Datenlage halte ich für ganz groben Unsinn! > Festplatten haben wir hier relativ oft im Labor. Es ist relativ > unwahrscheinlich, dass du mit Haushaltsmitteln da machen kannst, da es > ein Problem der Firmware ist. Also muss die Platte in sein Labor. :) > > Hast du noch sehr wichtige Daten auf der Platte? Hier prüft er eigentlich nur vorab, ob Du auch ein low-Portemonnaie-Problem hast. Mit dem Hinweis, dass Du nicht mehr ausgeben willst, als die Platte gekostet hat, hast Du Dich als Kunden schon einmal disqualifiziert, gute Antwort! Dimitri R. schrieb: > Ich kenne diese Tools jetzt leider nicht. Aber alle, die ich kenne (und > wir auch), die Datenrettung anbieten, nehmen PC-3000 dafür. Das ist eine > Hardware-Software Kombination, mit der man auf die sogenannte Service > Area der Festplatte zugreifen kann. Für Dich ist diese Software vermutlich unbezahlbar, deswegen brauchst Du Dimitri! :) Dimitri R. schrieb: > Wenn deine Festplatte mal einen defekten Sektor findet, dann wird dieser > in die G-List eingetragen. Diese Liste wächst mit der Zeit, bis sie > irgendwann voll ist bzw. überläuft. Dann tritt dieser Fehler auf, dass > die Festplatte nur sehr langsam reagiert. Ja, und nach nur 17 Fehlern soll Deine Platte überfordert sein. :) Also ich hatte schon zwei Zehnerpotenzen mehr an Fehlern. In keinem Fall hatte ich ein "low-Dingsbums"-Problem. Hanebüchen! Wie groß ist denn Deine Zielpartition im Vergleich zur Quellpartition? Dein zweiter Rettungsversuch war übrigens sträflich. Du hast dabei das Statusfile Deiner ersten Rettung und Deine erste Rettung überschrieben. Die 17 hängenden Sektoren zeigen, dass die Platte geschädigt ist. So eine Platte hängt man eigentlich nur genau einmal zum Retten an den Rechner. Ich hätte übrigens die ganze Platte kopiert, Deine Zielplatte ist ja offensichtlich größer als die Quellplatte. Was ich Dir jetzt nicht sagen kann, ist wie sich Partitionskopierversuche auf GPT-Datenträgern auswirken, hatte bisher selbst noch nicht das Vergnügen. Deine großen Platten haben ja vermutlich keine herkömmliche Partitionstabelle mehr. Jetzt solltest Du die Kopie ein zweites Mal kopieren. Auf der 2. Kopie kannst Du dann spielen. Nehmen wir an, die Partitionsstrukturen sind in Ordnung, dann könntest Du mit testdisk durchnavigieren und gucken, ob der Bootsektor Deiner NTFS-Partition defekt ist und notfalls versuchen, diesen wiederherzustellen. Wenn es trotz Wiederherstellung nicht klappt, sind vermutlich ein paar Metastrukturen der NTFS-Partition betroffen. Dann könntest Du die Zweitkopie an Deinen Windowsrechner hängen und chkdsk probieren. Du hast zwar keinen Laufwerkbuchstaben, kannst aber vielleicht der Partition die "Volume GUID" entlocken, damit kann man CHKDSK auch starten - habe ich bisher aber noch nicht brauchen müssen, habe also damit keine Erfahrung. Wenn das Ergebnis nicht brauchbar ist, hast Du immer noch die Möglichkeit deine Zweitkopie aus der Erstkopie wieder herzustellen. Dann geht's an Eingemachte: Du musst die Metastrukturen selber durchnavigieren, dafür musst da aber ein bischen Ahnung von NTFS haben. Wenn das scheitert, und Du keinen kennst, der Dir das für ein "Vergelt's Gott!" macht, verbleibt immer noch die dumme Holzhammermethode mit photorec oder irgendwie sonst suchen à la Daniel Albrecht. Übrigens, viele kommerzielle Datenretter sind einfach nur Reseller der bekannten Labore, die sich noch eine Scheibe von Deinem Unglück abschneiden wollen. c't-Artikel lesen!!! Mir ist auch nach Lesen des Handbuchs nicht klar, was der -n-Parameter bei ddrescue bringt, bin bisher komplett ohne den ausgekommen, hatte aber wohl immer mit älteren Versionen von ddrescue zu tun. Nein, ich bitte keine kostenpflichtige Dienste an.
Peter M. schrieb: > Nach meinem Linux-Verständnis hast Du auf Partition 1 der externen > Platte geschrieben, nicht auf die Platte. Das ist ein wichtiger > Unterschied... Sorry, das hatte ich vergessen zu erwähnen, dass ich zuvor sdb -> sde und erst dann im zweiten Anlauf sdb2 -> sde1. Aber beides mit dem gleichen Ergebnis. Peter M. schrieb: > In Deiner Fehlermeldung sehe ich gar keinen "read-only"-Parameter. Das hatte ich von der Kommandozeile aus versucht und nicht nochmal extra einen Screenshot davon angefertigt. Peter M. schrieb: > Dimitri R. hat ein ein sogenanntes low-Portemonnaie-Problem. > Das tritt immer dann auch, wenn die Scheinqueue fast leer ist. :) > > Ganz im Ernst: > Seine Diagnose bei Deiner gezeigten Datenlage halte ich für ganz groben > Unsinn! Kam mir auch gleich in den Sinn - so ein Schnellschuss ohne weitere Infos / Nachfragen. Peter M. schrieb: > Also muss die Platte in sein Labor. :) Wie gesagt, ich werde da nichtsmehr investieren, außer Zeit. Peter M. schrieb: > Hier prüft er eigentlich nur vorab, ob Du auch ein > low-Portemonnaie-Problem hast. Mit dem Hinweis, dass Du nicht mehr > ausgeben willst, als die Platte gekostet hat, hast Du Dich als Kunden > schon einmal disqualifiziert, gute Antwort! Hehe, ich meinte eigentlich die externe 4TB die ich für die Wiederherstllungsversuche gekauft habe. Aber Message ist angekommen :) Peter M. schrieb: > Wie groß ist denn Deine Zielpartition im Vergleich zur Quellpartition? Siehe Screenshot im 1. Post. Die "Rettungs-Platte" hat nur eine Partition. Peter M. schrieb: > Was ich Dir jetzt nicht sagen kann, ist wie sich > Partitionskopierversuche auf GPT-Datenträgern auswirken, hatte bisher > selbst noch nicht das Vergnügen. > Deine großen Platten haben ja vermutlich keine herkömmliche > Partitionstabelle mehr. Richtig --> GPT. Erfahrungen damit fehlen mir ebenfalls. Peter M. schrieb: > Nehmen wir an, die Partitionsstrukturen sind in Ordnung, Ich habe eben mal zwischendurch mit testdisk einen Blick auf die Zielplatte geworfen und konnte meine Verzeichnisstruktur und Dateien ausmachen. Auch stimmen zumindest die Dateigrößen. Wenn die Kopierorgien beendet sind werde ich mal testdisk drauf loslassen. Ich bin guter Dinge, dass die Daten bis auf einen kleinen Teil den ddrescue schon meldet ( < 1MB) intakt sind.
Peter M. schrieb: > Nach meinem Linux-Verständnis hast Du auf Partition 1 der externen > Platte geschrieben, nicht auf die Platte. Das ist ein wichtiger > Unterschied... Da er ja auch von einer Partition kopiert hat ist das nicht falsch. Peter M. schrieb: > Was ich Dir jetzt nicht sagen kann, ist wie sich > Partitionskopierversuche auf GPT-Datenträgern auswirken, hatte bisher > selbst noch nicht das Vergnügen. Wenn man eine Partition auf eine andere Kopiert ist die Partitionstabelle beider Platten egal. Die Partitionstabelle legt nur fest, wo die Daten liegen, und liegt ausserhalb der Partition. Deshalb hat das Kopieren der Daten auf eine Partition auch keinen Einfluss auf die Partitionstabelle.
Sebastian R. schrieb: > Sorry, das hatte ich vergessen zu erwähnen, dass ich zuvor sdb -> sde Aber dabei müsste doch auch die Partitionstabelle kopiert worden sein? Dann wäre sde1 doch genauso klein wie sdb1, und sde1 wäre damit zu klein für sdb2, oder?
Daniel A. schrieb: > Aber dabei müsste doch auch die Partitionstabelle kopiert worden sein? > Dann wäre sde1 doch genauso klein wie sdb1, und sde1 wäre damit zu klein > für sdb2, oder? Ja, stimmt. Das ist mir gar nicht aufgefallen. Er muss zwischendurch die Platte neu partitioniert haben, sonst hätte ddrescue sicher eine Fehlermeldung ausgeworfen. Ich hatte ihn deswegen weiter oben nach der Größe der Partition gefragt, weil ich dachte, dass er eventuell auf eine zu kleine Partition umkopiert hat.
sde1 ist eine 4TB NTFS Partition (also die komplette Zielplatte). Auf sde1 wird nun sdb2 mittels ddrescue kopiert und dann davon nochmal ein Image erstellt. Schade, dass die Garantie der WD Platte schon abgelaufen ist :(
So, ich bin fertig mit der Kopierorgie und nun mal wieder zu Windows gewechselt. Unter Testdisk wird mir die Partition auf der "Rettungsplatte" auch angezeigt. Leider ist sie aber noch immer nicht lesbar und Windows zeigt sie in der Datenträgerverwaltung als RAW an :-(
Angehängte Dateien:
-
testdisk.jpg
(110 KB)
Und was zeigt Dir "list files"?
Die Dateistruktur konnte ich mit R-Studio und auch mit testdisk sehen. Ich habe dann einfach mit der Kopierfunktion von Testdisk die Daten von der Platte runterkopiert. Fazit: alle Daten wieder da, dank Freeware ddrescue und testdisk. Das weiter oben vermeintlich diagnostizierte "slow response problem" war wohl in der Tat Humbug in diesem Fall.
Sebastian R. schrieb: > Die Dateistruktur konnte ich mit R-Studio und auch mit testdisk > sehen. > Ich habe dann einfach mit der Kopierfunktion von Testdisk die Daten von > der Platte runterkopiert. > Fazit: alle Daten wieder da, dank Freeware ddrescue und testdisk. Das > weiter oben vermeintlich diagnostizierte "slow response problem" war > wohl in der Tat Humbug in diesem Fall. Wunderbar. Schön, dass es geklappt hat! Wenn Du noch Lust hast, meine Neugier zu befriedigen, könntest Du mit testdisk gucken, ob der Bootsektor Deiner kopierten defekten NTFS-Partition in Ordnung ist, eventuell wiederherstellen, Platte trennen, wieder neu anschließen und gucken, ob Windows den Partitionsinhalt zeigt. Falls das auch nicht klappt, testen, wie oben beschrieben: Dann könntest Du die Zweitkopie an Deinen Windowsrechner hängen und chkdsk probieren. Du hast zwar keinen Laufwerkbuchstaben, kannst aber vielleicht der Partition die "Volume GUID" entlocken, damit kann man CHKDSK auch starten - habe ich bisher aber noch nicht brauchen müssen, habe also damit keine Erfahrung.
Der Bootsektor war defekt. Testdisk konnte ihn aber aus dem Backup-Bootsektor wiederherstellen. Ich habe Testdisk dann die Platte analysieren lassen. Dabei wurde auch die gefundene Partition in die PArtitionstabelle geschrieben. Ergebnis: Sofort nach dem Anschließen der Platte wird Windows quaälend langsam und die Ereignisanzeige füllt sich mit Event 153. Unter linux kommt beim mounten die o.g. Fehlermeldung. ntfsfix konnte auch keinen Fehler finden bzw. etwas beheben. Nun habe ich mehrere Durchgänge badblocks über die Platte laufen lassen, in ein USB-Gehäuse verfrachtet und dort einen Partition erstellt. Das klappt ohne Probleme. Die wird jetzt für das Backup vom Backup genutzt.
Gast
#4703518
Sebastian R. schrieb: > badblocks Es gab Platten, die hatten kaputte Sektoren über Jahre und andere bekamen minütlich mehr Fehler. Eigentlich sollte man diese zweifelhaft kranken Fälle wegwerfen um sich viel Zeit zu sparen (oder notfalls zur Diagnose mindestens frisch und grüüüüündlich formatieren).
Wobei es ja nicht immer die Platten sind sondern auch mal das Kabel der die Stromversorgung ist. Lockere Verbindungen haben da schon so einiges gemacht was aussah als ob der Fehler an der Platte lag. Gibt ja viele Ursachen immer dafür Aber Laut Angaben ist die Platte ja 18479 Stunden Aktiv was so 769,95 Tage sind. Wobei die ja nicht wirklich Lange in Betrieb ist. Hab hier ne eine Platte die ist etwas Länger in Betrieb und sieht besser aus 2610 Tage (> 7 Jahre Laufzeit) Model Family: Western Digital Caviar SE family Device Model: WDC WD1600AAJB-00J3A0 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 7 3 Spin_Up_Time 0x0027 132 130 021 Pre-fail Always - 4400 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 51 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 015 015 000 Old_age Always - 62652 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 49 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 36 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 51 194 Temperature_Celsius 0x0022 100 095 000 Old_age Always - 43 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 1
Ich lasse ddrescue lange laufen und breche dann nach x Stunden/Tagen mit Ctrl-c ab: ddrescue -v -O -A -r -1 /dev/sdc image_c.bin logfile_c.txt Dabei zeigte sich das über onboard-Adapter meist mehr lesbar ist als über USB-Adapter, zumindest bei IDE und SCSI.
Sebastian R. schrieb: > Der Bootsektor war defekt. Testdisk konnte ihn aber aus dem > Backup-Bootsektor wiederherstellen. Ich habe Testdisk dann die Platte > analysieren lassen. Dabei wurde auch die gefundene Partition in die > PArtitionstabelle geschrieben. > Ergebnis: Sofort nach dem Anschließen der Platte wird Windows quaälend > langsam und die Ereignisanzeige füllt sich mit Event 153. Ich nehme an, dass Du das auf der Defektplatte gemacht hast. Die defekten 17 Sektoren umfassen eben nicht nur den Bootsektor. Ein Checkdsk, umegeleitet in eine Datei, wäre nicht schlecht. Sinnvoller wäre es allerdings, nachdem Du Deine Daten gerettet hast, die Bootsektorreparatur auf der Erstkopie durchzuführen, denn die befindet sich auf einer Festplatte ohne defekte Sektoren. Es wäre interessant zu sehen, ob diese Kopie nach chkdsk [laufwerksbuchstabe:] /f /x wieder arbeitsfähig ist. > Unter linux kommt beim mounten die o.g. Fehlermeldung. > ntfsfix konnte auch keinen Fehler finden bzw. etwas beheben. > Nun habe ich mehrere Durchgänge badblocks über die Platte laufen lassen, > in ein USB-Gehäuse verfrachtet und dort einen Partition erstellt. Das > klappt ohne Probleme. Die wird jetzt für das Backup vom Backup genutzt. Danke, dass Du Dir die Mühe gemacht hast! Rolf F. schrieb: > Ich lasse ddrescue lange laufen und breche dann nach x Stunden/Tagen mit > Ctrl-c ab: > > ddrescue -v -O -A -r -1 /dev/sdc image_c.bin logfile_c.txt > > Dabei zeigte sich das über onboard-Adapter meist mehr lesbar ist als > über USB-Adapter, zumindest bei IDE und SCSI. Mit Onboard-Adaptern gab es bei mir immer die wenigsten Kontaktprobleme. DDrescue nutze ich am liebsten auf dem Laptop mit esata-Adapter im Expresscard-Slot, das war treibertechnisch immer unproblematisch und smartmontools lief immer. Bei anderen Adaptern helfen manchmal die Schnittstellen-Spezialparameter der smartmontools nicht weiter.
Kai A. schrieb: > Wobei es ja nicht immer die Platten sind sondern auch mal das Kabel der > die Stromversorgung ist. > Lockere Verbindungen haben da schon so einiges gemacht was aussah als ob > der Fehler an der Platte lag. > Gibt ja viele Ursachen immer dafür Seltsam, nachdem ich die "defekte" Platte jetzt mehrfach komplett vollgeschrieben und zurückgelesen habe sind die "offline_uncorrectable" Sektoren wieder auf 0 gesunken! Ich dachte nur die pending sectors kann man so dazu bewegen sich zu entscheiden ob sie doch noch gut oder endglültig schlecht (offline_uncorrectable) sind?! Zusaätzlich habe ich die Kontakte auf der Platine für Motor und Schreib-/Leseköpfe mit einem Glasfaserpinsel gereinigt. Die waren ziemlich oxidiert. Ob es das war? PS: die current pending sectors sind ebenfalls auf 0 zurück gegangen und die raw read error rate ist nicht weiter gestiegen.
Wenn du in einen Sektor schreibst, der als Current_Pending_Sector gekennzeichnet wurde, versucht die Festplatte tatsächlich in diesen Sektor zu schreiben. Funktioniert dies, dann wird der Count runtergesetzt. Funktioniert es nicht, dann wird ein Remapping ausgeführt. Sektoren die Offline_Uncorrectable sind werden bei einem SMART Selbsttest getestet. Wenn die Sektoren (wieder) funktionieren, dann werden die wieder aktiviert und der Count sinkt.
Bei HDDs und auch Floppies hat man eine Magnetisierung, die im Lauf der Jahre schwindet. Durch neu beschreiben wird die Magnetisierung aufgefrischt und dadurch können Fehler verschwinden. Neuere HDDs kümmern sich darum indem die ältesten Bereiche gelesen und neu geschrieben werden, wenn wenig Aktivität ist (Background Media Scan). Ähnlich zeigt sich auch die Alterung bei anderen Datenträgern. Bei SSDs macht man das Auffrischen über Wear Leveling.
Sebastian R. schrieb: > Seltsam, nachdem ich die "defekte" Platte jetzt mehrfach komplett > vollgeschrieben und zurückgelesen habe sind die "offline_uncorrectable" > Sektoren wieder auf 0 gesunken! Ich dachte nur die pending sectors kann > man so dazu bewegen sich zu entscheiden ob sie doch noch gut oder > endglültig schlecht (offline_uncorrectable) sind?! Dieses Verhalten hätte ich ähnlich auch erwartet. Ich erwarte "pending" beim Scheitern des Lesens. Bei einem Schreibversuch hätte ich erwartet, dass der Pending-Zähler um Eins fällt, wenn der alte Sektor erfolgreich geschrieben worden wäre. Beim einem gescheiterten Schreibversuch hätte ich eine Sektorumleitung erwartet und ein Ansteigen des "Reallocated"-Zähler um Eins, falls noch Ersatzsektoren zur Verfügung stünden. Ich habe folgende interessante Erklärung gefunden: https://debianforum.de/forum/viewtopic.php?f=13&t=138505 [... Kurz gesagt ist ein Offline uncorrectable ein Sektor, der beim Offline Scan auffällig wurde. Ob dieser ein wirklich defekter Sektor ist, stellt sich erst beim nächsten Schreibvorgang heraus. Erst dann wird er, wenn defekt, ausgelagert und erhöht den Reallocated sector count um eins. ...]
Nur die reallocated sectors können nicht wieder abnehmen?!
Sebastian R. schrieb: > Nur die reallocated sectors können nicht wieder abnehmen?! Logisch: Diese Sektoren sind als defekt markiert und deren Daten in Reserve-Sektoren verlegt. Die haben keine Selbstheilung und spätestens wenn alle Reserve-Sektoren belegt sind beginnt der Datenverlust (Data Rod).
Sebastian R. schrieb: > Nur die reallocated sectors können nicht wieder abnehmen?! Ich habe bei mir noch nie gesehen, dass die Zahl der "reallocated sectors" gefallen wäre - klingt logisch! Rolf F. schrieb: > Logisch: Diese Sektoren sind als defekt markiert und deren Daten in > Reserve-Sektoren verlegt. > Die haben keine Selbstheilung und spätestens wenn alle Reserve-Sektoren > belegt sind beginnt der Datenverlust (Data Rod). Nein, nein, der Datenverlust beginnt typischerweise vorher. Der Normalfall ist doch, dass der hängende Sektor unter Inkaufnahme von Datenverlust überschrieben wird. Die Reservesektoren der Festplatten stellen lediglich sicher, dass die Speicherkapazität der Festplatte nicht fällt.
> Der Normalfall ist doch, dass der hängende Sektor unter Inkaufnahme von > Datenverlust überschrieben wird. Das ist nicht normal ;) Von alleine produziert die Platte keinen Datenverlust. Erst wenn von aussen der Sektor überschrieben werden soll, passiert das. Wobei es da natürlich drauf ankommt, ob das Überschreiben erzwungen wird oder das FS das zufälligerweise selbst macht, weil sich die Daten wirklich geändert haben. Letzteres wäre natürlich auch kein Datenverlust.
Georg A. schrieb: >> Der Normalfall ist doch, dass der hängende Sektor unter Inkaufnahme von >> Datenverlust überschrieben wird. > > Das ist nicht normal ;) Von alleine produziert die Platte keinen > Datenverlust. Erst wenn von aussen der Sektor überschrieben werden soll, > passiert das. Also Datenverlust nach meiner unmaßgeblichen Definition besteht schon dann, wenn ein Sektor nicht mehr lesbar ist und die Festplatte 2 Minuten lang erfolglos versucht, den Sektor zu lesen.
Gast
#4712342
Peter M. schrieb: > Also Datenverlust nach meiner unmaßgeblichen Definition besteht schon > dann, wenn ein Sektor nicht mehr lesbar ist und die Festplatte 2 Minuten > lang erfolglos versucht, den Sektor zu lesen. Je nach Anwendung kann in dieser Zeit schon viel passiert sein. Eine große DB hätte nach 2 Minuten schon ein Problem. Wenn ein MP3 mal fehlt, wäre es IMHO nicht so tragisch. Im Zweifel Platte wegwerfen statt lange fummeln!
oszi40 schrieb: > Im Zweifel Platte wegwerfen statt lange > fummeln! Ja, der materielle "Schaden" ist vernachlässigbar. Der Schaden besteht für mich im Zeitaufwand für Datenrettung bzw. dem Verlust von unwiderbringlichen Daten.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.