Festplatten EOL?

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
Benutzeravatar
Blackbox
Beiträge: 2898
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Festplatten EOL?

Beitrag von Blackbox » 10.10.2019 08:57:22

Sollte ich mir Sorgen um meine RAID-Platten machen?
dmesg zeigt folgenes an:

NoPaste-Eintrag40881
Eigenbau PC: Debian Sid - Kernel: 5.2.6 - Xfce 4.14
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 5.2.6 - Xfce 4.14
Notebook: TUXEDO Book BU1406 - Debian Sid - Kernel: 5.2.6 - Xfce 4.14
Rootserver: Centos 7.7.1908 - Kernel: 3.10-x86_64
Alles Minimalinstallationen.

Freie Software unterstützen, Datenschutz stärken!

Benutzeravatar
smutbert
Beiträge: 6737
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Festplatten EOL?

Beitrag von smutbert » 10.10.2019 09:03:52

Die naheliegendere Ursache wäre ein kaputtes SATA-Kabel oder eine schlechte Steckverbindung. Hast du dir die SMART-Werte der Festplatte schon angesehen?

Benutzeravatar
Blackbox
Beiträge: 2898
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Festplatten EOL?

Beitrag von Blackbox » 10.10.2019 09:40:07

smutbert hat geschrieben: ↑ zum Beitrag ↑
10.10.2019 09:03:52
Die naheliegendere Ursache wäre ein kaputtes SATA-Kabel oder eine schlechte Steckverbindung. Hast du dir die SMART-Werte der Festplatten schon angesehen?
Ich habe neulich™ im Linux-Magazin gelesen, dass SMART eher an Kaffeesatzlesen erinnert und weiß jetzt nicht genau, was ich von den Werten halten soll?

Code: Alles auswählen

smartctl -a /dev/sda
NoPaste-Eintrag40882

Code: Alles auswählen

smartctl -a /dev/sdb
NoPaste-Eintrag40883
Eigenbau PC: Debian Sid - Kernel: 5.2.6 - Xfce 4.14
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 5.2.6 - Xfce 4.14
Notebook: TUXEDO Book BU1406 - Debian Sid - Kernel: 5.2.6 - Xfce 4.14
Rootserver: Centos 7.7.1908 - Kernel: 3.10-x86_64
Alles Minimalinstallationen.

Freie Software unterstützen, Datenschutz stärken!

Benutzeravatar
smutbert
Beiträge: 6737
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Festplatten EOL?

Beitrag von smutbert » 10.10.2019 10:21:43

Ich traue mir auch nicht zu besonders viel daraus abzulesen, aber ich glaube zum Beispiel, dass die UDMA_CRC_Error_Count bei einem kaputten SATA-Kabel oder einer schlechten Steckverbindung auch gerne hinauf geht. Der Wert von 0 spricht also eher gegen meine Theorie.

Dagegen wurden bei sdb bereits 51 Sektoren (Reallocated_Sector_Ct) neu zugewiesen. Speziell wenn dieser Wert steigt, ist das ein Indiz für das nahende Ende der Festplatte.
Außerdem gab es offensichtlich 20 erfolglose Versuche einen Sektor neu zuzuweisen (71 bei Reallocated_Event_Count).

Bei der anderen Platte sehe ich nichts direkt beunruhigendes, die würde ich nur wegen der Raw_Read_Error_Rate von 1 im Auge behalten (das muss aber gar nichts heißen).


Kannst du identifizieren welche der beiden Platten an "ata1.00" hängt und die Meldungen im Log verursacht hat? Vermutlich sdb?
(Normalerweise würde ich sagen schau bei den Kernelmeldungen nach welche Festplatte an welchem Port erkannt wurde, aber das hilft hier wohl nichts, weil es zwei gleiche Platten sind.)

MSfree
Beiträge: 4655
Registriert: 25.09.2007 19:59:30

Re: Festplatten EOL?

Beitrag von MSfree » 10.10.2019 10:26:22

Blackbox hat geschrieben: ↑ zum Beitrag ↑
10.10.2019 09:40:07
Ich habe neulich™ im Linux-Magazin gelesen, dass SMART eher an Kaffeesatzlesen erinnert
SMART dient in erster Linie den Herstellern, die dem Endanwender so vorgaukeln können, ihre Platte wäre nahe eines Ausfalls, was den Anwender dazu motivieren soll, die Platte vorzeitig zu tauschen.

Mit einer vernünftigen Backupstrategie ist ein Plattenschaden aber ziemlich harmlos. Wenn die Arbeitsplatte ausfällt, kauft man eine neue und spielt das Backup ein. Das ist maximale Ausnutzung der Lebensdauer einer Platte.

So habe ich schon Platte 7-8 Jahre ohne Defekt weitergenutzt, obwohl sie laut SMART schon tot waren. Andererseits haben sich bei mir Platten verabschiedet, die laut SMART brandneu waren.

Mein Fazit ist, vergiß Smart und mach Backups.

Benutzeravatar
cirrussc
Beiträge: 6572
Registriert: 26.04.2007 19:47:06
Lizenz eigener Beiträge: MIT Lizenz

Re: Festplatten EOL?

Beitrag von cirrussc » 10.10.2019 23:30:02

Gar nichts Kaffeesatzleserei. Dass es ausgelagerte Sektoren und die Events dazu gibt, ist doch klar ersichtlich. Und das ist meistens auch schon das Schlimmste, was da drin stehen kann.
Man müsste die Daten nun sichern und die Platte gründlich mit badblocks -vws durchspülen, dabei sollten eventuell noch schwebende Sektoren ausgelagert werden und die Platte wieder nutzbar werden.
Erfahrungsgemäß sind Platten mit ausgelagerten Sektoren dann chronisch davon betroffen und weitere werden folgen. Ich hatte allerdings auch gegenteilige Fälle, einmal ausgelagert und dann noch 70.000h weiter gelaufen. Das sind jedoch Ausnahmen.
Wenn ich mich nicht täusche, müsste unser Wiki Artikel darüber noch aktuell sein.
https://wiki.debianforum.de/Festplatten ... berwachung
Zuletzt geändert von cirrussc am 11.10.2019 13:39:27, insgesamt 2-mal geändert.
Gruß cirrussc
--------------------
„Der Mensch steigert zur Zeit die Nutzung dessen, was seiner Willkür unterliegt - und kommt sich sehr klug dabei vor.“ H. Gruhl

Benutzeravatar
niemand
Beiträge: 13176
Registriert: 18.07.2004 16:43:29

Re: Festplatten EOL?

Beitrag von niemand » 11.10.2019 07:48:16

MSfree hat geschrieben: ↑ zum Beitrag ↑
10.10.2019 10:26:22
Mit einer vernünftigen Backupstrategie ist ein Plattenschaden aber ziemlich harmlos. Wenn die Arbeitsplatte ausfällt, kauft man eine neue und spielt das Backup ein.
, und wundert sich dann bitte auch nicht über kaputte Files, die auch im Backup kaputt sind.

Mit den Infos von SMART kann man schon gut arbeiten, wenn man sie zu interpretieren, sowie um ihre systembedingten Grenzen weiß.

Die hier verlinkten smartctl-Ausgaben sind okay, die kritischen Werte (interpretiert, nicht raw – auch so ’ne Sache, die viele übersehen) liegen alle oberhalb der „kaputt“-Indikatoren. Die Selbsttests würde ich mal noch anschubsen und gucken, was da rausfällt. Wenn auch das okay ist, könnte man mal z.B. die komplette Platte mit dd nach /dev/null kopieren und das Log beobachten, auch könnte man badblocks (im nichtdestruktiven Modus, wenn die Daten überleben sollen) drüberschicken (Vorsicht: das kann dauern).

Die letzten beiden Sachen würde ich allerdings auch erst nach dem Prüfen des Kabels durchführen – der Fehler ist in der Tat eher typisch für fehlerhafte Verbindungen, wie smutbert schon schrieb.
ENOKEKS

Antworten