Festplattenfehler erkennen

[MacFlieger]

Vor kurzem ist ja bei mir schon die zweite Festplatte im iMac gestorben. War kein Problem, da ich mein System schnell über Time Machine auf die neue Platte kopieren konnte.

Allerdings bereitet mir das etwas Kopfschmerzen. Bisher starben alle Festplatten bei und in meiner Umgebung nicht abrupt und vollständig, sondern sehr schleichend. D.h. einzelne Sektoren waren plötzlich defekt und das wurde im SMART-Status auch so angezeigt. Allerdings merkt man das nicht, sobald ein Sektor defekt ist, sondern erst, wenn man auf einen defekten Sektor zugreift (schreibend oder lesend). D.h. aber auch, dass ein defekter Sektor in einer Datei erst dann bemerkt wird (auch vom SMART-Status!), wenn man die Datei liest. Bei einer Datei, die man nur selten oder nahezu nie liest, merkt man es dann eben sehr spät, dass sie kaputt ist.
Nun mache ich ja Backups per TM auf eine externe Platte, die per Firewire angebunden ist. Einen SMART-Status kann man da schon mal überhaupt nicht auslesen.
Man stelle sich folgendes Szenario vor: Ein Sektor einer Datei geht auf dem Backup kaputt. Davon bekommt man nichts mit, weil man ja nur neue Daten auf die Platte schreibt. Die Datei liegt zwar dann scheinbar (per Hardlink) in jedem Backup drin, in Wirklichkeit ist die aber nur ein einziges mal gespeichert und das dann mittlerweile in einer defekten Variante. Das die Datei im Backup nicht mehr funktioniert merkt man erst dann, wenn man sie benötigt, d.h. wenn man sie wiederherstellen will oder ein Vollbackup zurückkopiert.
Ich habe also nicht nur einen Verlust, wenn beide Platten gleichzeitig kaputt gehen (was eher unwahrscheinlich ist), sondern auch, wenn die Backup-Platte schleichend kaputt geht und dann die Hauptplatte stirbt, weil man erst dann merkt, dass das Backup defekt ist.

Tja, was tun?
Man müsste also ab und zu mal die komplette Festplatte lesen, um zu schauen, ob noch alles lesbar ist. Jetzt habe ich mal im FPDP geschaut, ob man ein Image anlegen kann, ohne es zu speichern (also einfach nur lesen als ob). Das scheint nicht zu gehen. Mit "dd" und Ausgabe noch /dev/null sollte sowas gehen, oder?

[mbs]

Nun mache ich ja Backups per TM auf eine externe Platte, die per Firewire angebunden ist. Einen SMART-Status kann man da schon mal überhaupt nicht auslesen.

Das geht nicht, weil die Gehäuse-Bridge nur einfache Schreib-/Lese-Befehle, nicht aber die SMART-Diagnosebefehle zwischen FireWire- und ATA-Norm übersetzen kann. SMART-Kommandos können hardwaremäßig nicht zur Platte übertragen werden.

Mit "dd" und Ausgabe noch /dev/null sollte sowas gehen, oder?

Ja. Hierbei dürfte die Platte erkennbar defekte Sektoren automatisch durch Reservesektoren ersetzen. Von außen "merkt" man da allerdings nichts von.

[MacFlieger]

Hierbei dürfte die Platte erkennbar defekte Sektoren automatisch durch Reservesektoren ersetzen. Von außen "merkt" man da allerdings nichts von.

Ähm, was passiert denn, wenn dd auf einen benutzten defekten Sektor trifft? Dann wird einfach einer der Reservesektoren verwendet, die betreffende Datei ist aber dann unerkannt defekt? Und was ist, wenn es keine Reservesektoren mehr gibt?
Bei meinem letzten Problem war es auch so, dass sobald lesen auf den defekten Sektor zugegriffen wurde, das Laufwerk leise klickte und der Transfer einfach stehen blieb. Das kenne ich auch von einigen anderen ähnlichen Problemen bei Festplatten. Ich hätte jetzt erwartet, dass dd dann auch stehen bleibt und nicht einfach weiter macht.

[radneuerfinder]

was tun?

Die "reine" Backup Lehre sieht ja mindestens zwei von einander unabhängige Sicherungskopien zu.

Ich mache neben den Sicherungskopien mit TimeMachine auch noch ab und an (z.b. vor dem Update auf 10.5.4) einen kompletten Klon mit Super Duper oder dem FPDP. So habe ich ein mit anderer Software, auf anderer Hardware (Firewire Festplatte) erstelltes Zweitbackup. Das ich sogar noch räumlich getrennt (Schublade) aufbewahre. Außerdem ist dieses Backup bootbar und ich kann bei Problemen sofort mit meinem, oder einem anderen Mac weiterarbeiten, oder Datenrettungssoftware installieren. Leider hat man so wieder ein manuelles Backup an der Backe.

Oder Du wechselst ab und an zwischen mehreren TimeMachine Platten.

Oder Du nimmst für TimeMchine ein RAID, z.B:
http://www.cyberport.de/item/2/0/0/109261/western-digital-my-book-studio-edition-ii-fw800fw400usb20esata-extern-10tb-.html


An einer Software, die bei Lese- oder Kopierproblemen vernünftige Fehlermeldungen ausgibt, wäre ich aber auch interessiert - der Finder ist's jedenfalls nicht.

[MacFlieger]

Die "reine" Backup Lehre sieht ja mindestens zwei von einander unabhängige Sicherungskopien zu.

Ja, sicher, aber auch bei allen Deinen Vorschlägen, merkt man einen defekten Sektor doch zu spät. Auch bei einem RAID wird man doch erst gewarnt, wenn die Festplatte selber einen Fehler bemerkt. Solange man aber auf eine alte Datei gar nicht mehr zugreift, kann diese schleichend kaputt gegangen sein. das merkt man dann erst, wenn die zweite Platte kaputt geht und man hat nix mehr.

Man muss also irgendwie feststellen können, ob die gespeicherten Daten noch in Ordnung sind.

An einer Software, die bei Lese- oder Kopierproblemen vernünftige Fehlermeldungen ausgibt, wäre ich aber auch interessiert - der Finder ist's jedenfalls nicht.

Das stimmt.
Wobei es mir eigentlich schon ausreicht, wenn ich feststelle, dass es nicht lesbar also defekt ist. Warum, ist mir dann völlig egal.

[radneuerfinder]

Mit zwei Backups hat man ja drei Kopien einer Datei auf drei Festplatten. Daß alle drei Dateien nicht mehr lesbar sind, ist einfach sehr, sehr unwahrscheinlich. Wenn Dir die Wahrscheinlichkeit noch zu hoch ist, könntest Du periodisch eine Platte im RAID austauschen und die entnommene als 3. Backup wegschließen.

[mbs]

Ähm, was passiert denn, wenn dd auf einen benutzten defekten Sektor trifft? Dann wird einfach einer der Reservesektoren verwendet, die betreffende Datei ist aber dann unerkannt defekt?

Defekter Sektor heißt nicht, dass die Datei auch defekt ist. Ein defekter Sektor macht sich dadurch bemerkbar, dass es Prüfsummenfehler beim Auslesen der Daten gibt. Durch mehrmaliges Wiederholen des Lesevorgangs können die richtigen Daten üblicherweise wieder gelesen werden und die Festplatte rettet die Daten des Sektors so schnell wie möglich in den Reservebereich.

Und was ist, wenn es keine Reservesektoren mehr gibt?

Das kommt nur bei sehr alten, wirklich stark "abgenutzten" Platten vor und dann gibt es Fehlermeldungen und - sofern die Schnittstelle es zulässt - SMART-Warnungen.

Bei meinem letzten Problem war es auch so, dass sobald lesen auf den defekten Sektor zugegriffen wurde, das Laufwerk leise klickte und der Transfer einfach stehen blieb.

Das ist dann kein "normaler" defekter Sektor mehr, sondern schon etwas mehr, z.B. Positionierungsprobleme oder wirklich eine komplett zerstörte Spur.

Ich hätte jetzt erwartet, dass dd dann auch stehen bleibt und nicht einfach weiter macht.

Bei von der Platte selbsttätig korrigierbaren Fehlern ("recoverable") bekommt weder das Betriebssystem noch dd etwas von dem Problem mit. Die Hardware meldet überhaupt keinen Fehler.
Erst wenn der Zustand wirklich sehr ernst ist ("unrecoverable"), werden Meldungen weitergeleitet.

An einer Software, die bei Lese- oder Kopierproblemen vernünftige Fehlermeldungen ausgibt, wäre ich aber auch interessiert

Das ist in heutigen Systemen nicht mehr wirklich vorgesehen und oft auch gar nicht mehr machbar, da die Platten als eigenständige Subsysteme aufgebaut sind und kein echter Durchgriff auf die Hardware mehr besteht. Also ein Schwarz-Weiß-Bauteil, das entweder geht oder nicht geht und dann weggeworfen werden sollte. Dass da in der Praxis eine ärgerliche Grauzone bleibt (defekte Anschlusskabel, instabiles Netzteil, inkompatible Firmware), die von einem tatsächlichen Plattenfehler kaum zu unterscheiden ist, ist allerdings auch klar.

[MacFlieger]

Mit zwei Backups hat man ja drei Kopien einer Datei auf drei Festplatten. Daß alle drei Dateien nicht mehr lesbar sind, ist einfach sehr, sehr unwahrscheinlich.

Ja, da hast Du Recht. Trotzdem wäre es schön, einen Fehler zeitnah zu erkennen und nicht erst, wenn man auf das Backup zugreifen muss.

Defekter Sektor heißt nicht, dass die Datei auch defekt ist. Ein defekter Sektor macht sich dadurch bemerkbar, dass es Prüfsummenfehler beim Auslesen der Daten gibt. Durch mehrmaliges Wiederholen des Lesevorgangs können die richtigen Daten üblicherweise wieder gelesen werden und die Festplatte rettet die Daten des Sektors so schnell wie möglich in den Reservebereich.

Ja, ok, bei so einem Fehler kriegt das System nichts mit, weil die Platte alleine alles in Ordnung bringt. Um derartige Fehler ging es mir im Ursprungposting auch nicht. Für mich interessant sind die fehler, die die Platte selber nicht mehr korrigieren kann, d.h. also Daten tatsächlich weg/kaputt sind.

Das kommt nur bei sehr alten, wirklich stark "abgenutzten" Platten vor und dann gibt es Fehlermeldungen und - sofern die Schnittstelle es zulässt - SMART-Warnungen.

Naja, das hatte ich bei meinem iMac jetzt bereits zwei mal. Nach knapp über einem Jahr mit der Originalplatte und nach gut 1,5 Jahren mit einer Samsung (siehe hier). Die SMART-Warnung ("Pending Bad Sectors", FPDP behauptete aber alles wäre in Ordnung) kam erst, nachdem ich die Datei auch mal lesen wollte. D.h. der Fehler selber entstand zwischen dem Zeitpunkt des Schreibens und des späteren Lesens. Gerade bei alten Dokumenten, die man nur sehr selten braucht, könnte da dann zwischen einem Fehler und dem Bemerken Monate oder länger liegen. Schlimmer noch. Wenn es die Backup-Platte ist, dann merkt man es erst, wenn man das Backup benutzen möchte.
Und ähnliche Plattenausfälle kenne ich im Bekanntenkreis noch mehr. Ehrlich gesagt, kenne ich nur derartige Ausfälle. Richtige Plattencrashs, d.h. Knall und nix geht mehr, habe ich noch nicht erlebt.

Das ist dann kein "normaler" defekter Sektor mehr, sondern schon etwas mehr, z.B. Positionierungsprobleme oder wirklich eine komplett zerstörte Spur.

Kann sein. Auf jeden Fall war die Datei unwiederbringlich kaputt. War bei dieser nicht schlimm, aber s.o.

Bei von der Platte selbsttätig korrigierbaren Fehlern ("recoverable") bekommt weder das Betriebssystem noch dd etwas von dem Problem mit. Die Hardware meldet überhaupt keinen Fehler.
Erst wenn der Zustand wirklich sehr ernst ist ("unrecoverable"), werden Meldungen weitergeleitet.

Ja, und genau an denen wäre ich ja interessiert. D.h. meine Idee mit dd und /dev/null ist vielleicht doch nicht so doof? Oder gäbe es etwas raffinierteres?

[mbs]

D.h. meine Idee mit dd und /dev/null ist vielleicht doch nicht so doof?

Nö, im Gegenteil. Hat ja niemand behauptet.

Die SMART-Warnung ("Pending Bad Sectors", FPDP behauptete aber alles wäre in Ordnung)

"Pending Bad Sectors" ist ein SMART-Attribut, dessen Wert alleine noch keinen Rückschluss auf den SMART-Status ("Überprüft") erlaubt.

Das ist einfach die Anzahl der Sektoren, die die Platte im Moment als "vielleicht durch Reserve zu ersetzen" vorgemerkt hat. Die Lesefehlerrate ist noch nicht so kritisch, dass die Platte den Sektor als wirklich defekt ansieht, sondern auch ein zufälliger Messfehler vorgelegen haben könnte.

Wenn der betroffene Sektor in Zukunft mehrere Lesevorgänge fehlerfrei übersteht, dann wird er wieder aus dem "pending bad sector"-Status entfernt und als "OK" behandelt. Wenn allerdings nochmal ein Lesefehler auftritt, dann wird ein Reservesektor zugewiesen. Auch in diesem Fall wird der Sektor aus der "pending bad sector"-Liste entfernt, aber dann dem Attribut "reallocated sector count" zugeschlagen.

[MacFlieger]

Ich habe  ja mehrfach (mind. 4mal) versucht, die Daten zu lesen. Die Platte blieb jedesmal(!) reproduzierbar bei den gleichen Daten stehen und klickte leise vor sich hin. D.h. da hätte nach Deiner Beschreibung spätestens beim zweiten mal ein Reservesektor zugewiesen werden sollen. Wurde aber nicht.
Die "Selbstheilung" der Festplatte hat meiner Meinung nach in diesem Fall versagt. Evtl. war auch kein Reservesektor mehr übrig?  Kann ich aber erst nachschauen, wenn ich die Platte wieder in den iMac einbaue. Dann schaue ich auch mal bei "reallocated sector count" nach.

Wie auch immer, das ist mir jetzt mehrfach passiert und ich habe ein wenig Angst, dass ich das bei meiner Backup-Platte erst merke, wenn ich es brauche.

[MacFlieger]

Noch eine Nachfrage zu dd:

Ich würde  folgenden Befehl verwenden wollen:

Code: [Auswählen]

dd if=/dev/disk0s3 >/dev/nullDas würde meine interne Platte (1 Volume) lesen.
Mit disk2s12 wäre meine Backuplatte gemeint (2. Volume auf externer FW-Platte).
Ist das in Ordnung?

Diese Zuordnungen habe ich im FPDP ausgelesen. Kann man das auch direkt herausbekommen oder ändern sich die Bezeichnungen ohne Hardwareumbau nicht.
Und warum gibt es disk2s1 bis disk2s12 auf meiner externen Platte mit 2 Volumes?

[mbs]

dd if=/dev/disk0s3 >/dev/null
Das würde meine interne Platte (1 Volume) lesen.

Nicht die ganze Platte, nur das Volume. Deshalb würde ich eher empfehlen:

Code: [Auswählen]

sudo dd if=/dev/disk0 of=/dev/null

Kann man das auch direkt herausbekommen

Ja, mit "diskutil list".

ändern sich die Bezeichnungen ohne Hardwareumbau nicht

Da darf man sich nicht drauf verlassen. Rein theoretisch könnte sich die Plattennummerierung bei jedem Booten ändern. Um langlebige Bezüge auf Volumes zu speichern, verwendet Mac OS X daher intern nur UUIDs.

Und warum gibt es disk2s1 bis disk2s12 auf meiner externen Platte mit 2 Volumes?

Dann sind in Wirklichkeit offenbar 12 Partitionen vorhanden. Das FPDP versteckt das. Bei PPC-Rechnern sind das oft die berühmten "Mac OS-Treiber" und ähnliche Verwaltungsdinge für das klassische Mac OS. Auch "Sektorverschnitt" zwischen zwei Partitionen oder am Plattenende kann als eigene Partition gezählt werden.

Bei Intel-Rechnern gibt es in der Regel eine versteckte EFI-Boot-Partition, in der sich EFI-Treiber, das Boot-Menü und oft sogar eine Kopie des Apple Hardware Tests befinden.

[MacFlieger]

Code: [Auswählen]

sudo dd if=/dev/disk0 of=/dev/null

Ah ja, einleuchtend. Danke.
Da geht die Prozessorbelastung gleich an den Anschlag und die Prozessortemperatur auf 79°. OK, muss er abkönnen. Ich habe mal die Laufzeit überschlagen, wenn der Rechner nix anderes macht. Gut 7h für die Backup-Platte und gut 12h für die interne. Wahnsinn...

Ich habe auch schon überlegt, ob evtl. eine hohe Temperatur der Grund für die Ausfälle sein kann. Spezifiziert ist die Samsung-Platte bis 60°. Im Betrieb liegt die per SMART ausgelesene Temperatur meist gut 2° höher als der Temperatursensor intern. Bei wenig Belastung erreicht die Festplatte 52°, bei Belastung geht sie auf max. 58°. Ist schon hart an der Grenze...

Ja, mit "diskutil list".

Danke.

Dann sind in Wirklichkeit offenbar 12 Partitionen vorhanden. Das FPDP versteckt das. Bei PPC-Rechnern sind das oft die berühmten "Mac OS-Treiber" und ähnliche Verwaltungsdinge für das klassische Mac OS. Auch "Sektorverschnitt" zwischen zwei Partitionen oder am Plattenende kann als eigene Partition gezählt werden.

Ja, ich habe ja bisher nur PPC-Macs (von 601 bis G5). Meinen ersten Nicht-PPC-Mac habe ich am Montag geordert, wird aber nicht geliefert.

Das mit den Mac OS-Treiber wusste ich, aber auf 10(!) Partitionen wäre ich nicht gekommen. Hier der Ausschnitt von "diskutil list":

Code: [Auswählen]

/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     Apple_partition_scheme                        *232.9 Gi   disk2
   1:        Apple_partition_map                         31.5 Ki    disk2s1
   2:             Apple_Driver43                         28.0 Ki    disk2s2
   3:             Apple_Driver43                         28.0 Ki    disk2s3
   4:           Apple_Driver_ATA                         28.0 Ki    disk2s4
   5:           Apple_Driver_ATA                         28.0 Ki    disk2s5
   6:             Apple_FWDriver                         256.0 Ki   disk2s6
   7:         Apple_Driver_IOKit                         256.0 Ki   disk2s7
   8:              Apple_Patches                         256.0 Ki   disk2s8
   9:                  Apple_HFS Tiger                   14.9 Gi    disk2s10
  10:                  Apple_HFS Backup                  217.7 Gi   disk2s12
disk2s9 und disk2s11 gibt es komischerweise nicht. Naja, egal, hauptsache läuft.

[MacFlieger]

Ich hol den Thread mal nach oben.

Ich habe hier eine Platte im USB-Gehäuse, die einen definitiv defekten Sektor hat. Das zeigt SMART an (als die noch intern eingebaut war), eine Datei, die diese Sektoren verwendet, kann nicht mehr gelesen werden (IO-Fehler) und auch ein Sektorcheck mit "DiskMonitor" unter Windows zeigt den Fehler.

Also eine gute Gelegenheit, den in diesem Thread postulierten Festplattencheck mit dd zu überprüfen. Ich habe also den folgenden Befehl im Terminal verwendet und der hat gut 2 Tage gearbeitet:

Code: [Auswählen]

sudo dd if=/dev/disk2 of=/dev/nullDanach bekam ich die Zusammenfassung, wieviel kopiert wurde und fertig. Keinerlei Hinweis auf einen Lesefehler. D.h. die Methode mit "dd" scheint doch nicht geeignet zu sein.

Irgendwelche Ideen?

[mbs]

Ist der Fehler denn noch da? Wie oben schon erwähnt, kann man von außen kaum feststellen, ob und wie die Platte den Fehler behoben hat. Und über eine USB-Bridge hinweg wird es noch schwieriger.