Ext4-formatierte Festplatte auf fehlerhafte Blöcke hin untersuchen

[Atalanttore]

Hallo

die Datensicherung auf eine externe Festplatte wurde von meinem NAS (QNAP TS-431P) abgebrochen, weil es dabei zu Fehlern gekommen ist.

In der Fehlermeldung wird mir ein bad block scan des Laufwerks empfohlen.

Die Festplatte ist 8 TB groß, das Dateisystem ist Ext4 und vollständig verschlüsselt.

Das Linux-Kommandozeilenprogramm badblocks, was mir im QNAP Club Forum immer wieder empfohlen wurde, funktioniert einfach nicht. Seitdem ich das dort klargestellt habe, ist bei der dortigen Diskussion Totenstille eingekehrt. Das Problem mit der externen Festplatte besteht aber weiterhin.

Gibt es ein Windows-Programm, was eine mit Ext4 formatierte Festplatte auf fehlerhafte Blöcke hin untersuchen kann?

Gruß
Atalanttore

 

[KompiFreak]

Hmm, hast du schon smart ausgelesen? Sonst kannst du vorab mit "fsck" unter Linux dein Filesystem untersuchen - ist ähnlich wie "chkdsk" unter Windows.

Andere Frage - was hindert dich generell daran die Platte komplett zu lsöchen und danach neu vollständig (kein quickformat) zu formatieren?

 

[audianer]

Ein Screenshot von CrystalDiskInfo wäre super...

 

[Atalanttore]

Danke für eure Tipps.

Gestern Abend gleich nach dem Erstellen dieses Threads habe ich einen weiteren Versuch mit der Datensicherung gestartet. Seitdem hängt die Platte am NAS. Bisher ohne Fehlermeldung vom NAS. Bei ~5 TB an zu sichernden Daten dauert das schon seine Zeit.

Sobald eine Fehlermeldung kommt und der Backupvorgang dadurch abbricht, werde ich eure Vorschläge umsetzen.

 

[Atalanttore]

Heute Nacht ist das Backup nach ca. 1,5 Tagen Laufzeit wieder mit Fehlern abgebrochen. Vor den Festplattenfehlern lief ein wöchentliches Backup in deutlich weniger als einem Tag erfolgreich durch.

Wie gewünscht nun die SMART Werte bzw. ein Screenshot von CrystalDiskInfo.

 

[Holt]

Die Werte sind in Ordnung, aber die Platte hat SMR, kann es sein dass das Backupprogramm damit nicht umgehen kann? Denn bei HDDs mit SMR können die Schreibvorgänge ggf. sehr lange dauert, viel länger als bei HDDs ohne SMR und manche Systeme unterstellen dann einen Defekt der Platte weil sie so lange nicht antwortet. Die mag beim ersten Beschreiben einer HDD mit SMR noch nicht aufgetreten sein, da war sie ja leer und wenn dann vor allem sequentiell geschrieben wird, dann kann man auch auf diese sehr schnell schreiben, aber wenn sie voller wird und das Filesystem fragmentiert, dann steigt die Wahrscheinlichkeit das auch mal Schreibvorgänge lange dauern.

 

[Atalanttore]

Als Backupprogramm dient Hybrid Backup Sync von QNAP.

Die Festplatte ist seit ~5 Jahren als Backupplatte im Einsatz. Bis dato gab es keine solchen Fehler.

Könnte ein Defragmentieren der Backupplatte helfen?

 

[Holt]

Also ich habe kein QNAP und kann daher auch nichts zu deren Backuptool sagen, aber die Platte ist in Ordnung, an der liegt es nicht. Außer es ist eben weil die SMR hat. Ob eine Defragmentierung helfen könnte, musst Du einfach mal ausprobieren.

 

[Atalanttore]

Consumer NAS-Systeme von QNAP würde ich mittlerweile nicht mehr kaufen. Die QNAP Hardware ist gut, aber die QNAP Software hat mehrere Macken, die dem QNAP Kundendienst zwar bekannt sind, aber nicht behoben werden.

Danke für deinen Hinweis, dass die Platte in Ordnung ist. Das spart mir ~200 Euro, wenn das mit der Defragmentierung funktioniert. Es wäre auch das erste Mal für mich, dass mir eine Platte von Seagate kaputtgeht.

 

[Holt]

Naja, wenn sie 5 Jahre alt ist, dann ist die vom Hersteller für HDDs vorgesehen Nutzungsdauer (service life) damit auch abgelaufen. Klar halten die HDDs meist länger, aber man weiß eben nicht wie lange sie noch halten und ihre Pflicht haben sie dann schon erledigt. Und es sind Kalenderjahre, nichts mit die Betriebsstunden zählen und durch 8760 teilen! Wenn es nicht das einzige Backup ist, dann kann man sie aber noch in Ruhe weiter nutzen, bis sie wirklich anfängt auszufallen.

 

[Atalanttore]

Nach ca. 3 Tagen Laufzeit ist die Defragmentierung jetzt abgeschlossen. Folgendes Ergebnis kam dabei heraus:

    Success:            [ 128920/135090 ]
    Failure:            [ 6170/135090 ]

 

[Holt]

Das entscheidende Ergebnis der Defragmentierung wäre ja eigentlich, ob das Backup danach problemlos durchläuft.

 

[Atalanttore]

Im Laufe des Wochenendes habe ich mehrere Backups auf die defragmentierte externe Festplatte durchführen lassen. Das hat so weit immer funktioniert. Auf dem NAS gemachte Änderungen an Dateien wurden beim Backup immer auf die externe Festplatte übertragen. Das habe ich im Dateimanager nachkontrolliert. Das Backup läuft wieder durch. Danke für den Tipp mit dem fragmentierten Dateisystem.

Gestern habe ich das NAS neu gestartet, um zu sehen, ob das Backup danach immer noch funktioniert. Das Backup hat weiter funktioniert, aber das NAS hat nach dem Neustart für eine der internen 6 TB NAS-Festplatten (Baujahr 2015) folgende Fehlermeldung angezeigt und diese aus dem RAID6 aussortiert.

Medium error. Run a bad block scan on the drive. Replace the drive if the error persists.

Die Fehlermeldung ist die gleiche wie vorher für die externe Festplatte.

CrystalDiskInfo bezeichnet den Gesamtzustand der NAS-Festplatte mit Vorsicht.

Ist das ein komischer Zufall und die NAS-Festplatte hat jetzt wirklich einen Schaden oder steckt vielleicht mehr hinter den Problemen mit fehlerhaften Blöcken?

 

[Holt]

Die Platte hat einen schwebenden Sektor, dies kann unterschiedliche Ursachen haben. Es kann der Anfang vom Ende sein, die ist ja auch schon über 7 Jahre alt und hat von daher ihre 5 Jahre "Service life" eben auch schon deutlich überstiegen, aber es kann auch harmlose Gründe haben. Schwebende Sektoren sind Sektoren deren Daten nicht zur ECC passen die hinter jedem Sektor steht und mit deren Hilfe auch nicht mehr korrigiert werden können. Da die korrekten Daten nicht mehr feststellbar sind, gibt die Platte statt falscher Daten einen Lesefehler als Antwort wenn man versucht diese zu lesen. Das kann auch anderen Gründe als defekte Oberflächen haben, z.B. einen Stromausfall während eines Schreibvorgang der dazu führt, dass eben nicht die ganze Daten plus der neuen ECC geschrieben wurden oder wegen eines Stoßes oder Vibrationen ist der Kopf beim Schreiben aus der Spur gekommen und hat Daten auf der Nachbarspur überschrieben. Auch arbeiten HDDs nicht 100%ig und die Hersteller geben die Fehlerhäufigkeit auch in Form der UBER an, wobei eine UBER von 1:10^14 bedeutet, dass je 10^14 gelesener Bits was etwa 12TB gelesener Daten entspricht, ein Lesefehler und damit schwebender Sektor im Rahmen der Erwartungen liegt.

Die Controller merken sich die schwebenden Sektoren und prüfen die Daten nach dem erneuten Schreiben auf diese Sektoren, dann verschwinden diese einfach oder werden eben durch Reservesektoren ersetzt. Da hier der Rohwert vom Attribut 05 in dem die Anzahl der verwendeten Reservesektoren noch 0 ist, kann man also nicht sagen ob sie wirklich ein Problem der Oberfläche hat oder ob es eben ein harmloser Fehler wie die oben beschriebenen ist, es gab ja immerhin auch 16 unerwartete Spannungsabfälle (Attribut C0) und wer weiß wann der letzte passiert ist und ob da nicht gerade geschrieben wurde. Aufgrund des Alters würde ich aber sowieso eher zu einem Austausch raten.

 

[n3cron]

Was auch manchmal funktioniert, wenn es für dich möglich wäre... die Platte zu formatieren ggf. vorher wichtige Backups woanders sichern/kopieren und nach der Formatierung zurück sichern.

 

[Holt]

n3cron, damit erzwingt man ja auch nur das Überschreiben des schwebenden Sektors und dann verschwindet er wie gesagt eben und wird ggf. durch einen Reservesektor ersetzt.

 

[Atalanttore]

@n3cron Die Platte, wo das NAS jetzt fehlerhafte Blöcke meldet, ist eine interne Festplatte aus dem RAID-Verbund des NAS. Mit meinen Backups hat diese interne Festplatte eigentlich nichts zu tun.

 

[Holt]

Doch möglicherweise schon, denn wenn die Fehler beim Backup einfach nur wegen eines Timeouts passiert ist, dann kann der ja ggf. auch aufgetreten sein, weil die interne Platte lange gebraucht hat die Daten zu lesen und damit zu liefern und Backupplatte daher zu wenig Zeit vor dem Timeout blieb diese Daten dann noch zu schreiben. Irgendwas ist da sowieso komisch, keine Ahnung wieso das RAID 6 eine Platte aus dem RAID wirft, nur weil ein Sektor nicht mehr gelesen werden kann, zumal wenn es eine WD Red ist. Also eine NAS Platte mit TLER bei der man den Timeout, wie lange sie versucht solche Sektoren durch wiederholte Versuche doch noch erfolgreich zu lesen, einstellen kann. Dieser Timeout sollte kürzer sein als der Timeout der RAID Lösung auf eine Antwort zu warten und nur wenn HDDs nicht innerhalb dieser Zeit antwortet, dann fliegt sie aus dem RAID, wenn sie aber mit einem Lesefehler antwortet, dann rekonstruiert das RAID die Daten aus der Redundanz und überschreibt den betroffenen Sektor auf der Platte, womit er eben dann verschwindet.

Deshalb haben Platten in echten RAIDs mit Redundanz normalerweise nie schwebende Sektoren, eben weil diese immer sofort wieder überschrieben werden und wenn doch, dann meistens weil jemand dafür nicht geeignete Desktop HDDs wie z.B. eine WD Blue ohne TLER an einem Hardware RAID Controller betreibt. Hardware RAID Controller warten normalerweise nämlich 8s auf eine Antwort und der Timeout der Blue ist 14s und nicht einstellbar, der der WD Red mit TLER ist per Default 7s und eben einstellbar, also schon per Default kürzer als der Timeout der Hardware RAID Controller und sollte ein RAID Controller oder eine RAID SW einen kürzeren Timeout haben, muss sie den Timeout der Platten entsprechend noch kürzer einstellen. Software RAID haben aber meist noch längere Timeouts als die Hardware RAID Controller.

Aber wie schon gesagt, bei dem Alter wäre ein Austausch angebracht, die Platte hat ihre Pflicht mehr als erfüllt. Und beachte das die aktuellen WD Red nun SMR haben, die ohne SMR nennen sich jetzt Red Plus. Die Red Pro und die Seagate IronWolf haben ebenfalls kein SMR.

 

[n3cron]

Ich würde für ein RAID auch kein SMR empfehlen.
CMR ist hier nach wie vor sicherer.

@n3cron Die Platte, wo das NAS jetzt fehlerhafte Blöcke meldet, ist eine interne Festplatte aus dem RAID-Verbund des NAS. Mit meinen Backups hat diese interne Festplatte eigentlich nichts zu tun.

Manchmal hilft es auch sich den Port anzuschauen. Dieser kann auch verschmutzt sein oder ähnliches und Fehler in der Kommunikation verursachen. Hatte ich auch schon mit einer NAS. Alles unauffällig, selbst ein anschließen der Platte an einem PC etc.

 

[Holt]

Dieser kann auch verschmutzt sein oder ähnliches und Fehler in der Kommunikation verursachen.

Die sind dann aber im Rohwert vom Attribut C7 zu finden und der ist bei beide Platten 0, es gab also niemals Fehler in der Kommunikation mit dem Host Controller. Dies kann man sicher sagen, da es ein Lebenszeitzähler ist und deshalb nie wieder auf 0 fällt, wenn man das Problem behoben hat, sondern dann eben nicht weiter ansteigt. Meist ist das SATA Datenkabel das Problem, entweder sitzt ein Stecker nicht richtig steckt, vielleicht weil er sich gelöst hat, es haben ja nicht alle einen Sicherungsclip oder es hat einen Schaden einen mit dem Auge nicht sehen kann. Diese passieren gerne mal, wenn man am Kabel statt am Stecker zieht, was manchmal gar nicht einfach zu vermeiden ist und auch oft gut geht, aber eben nicht immer. Dann kann natürlich auch Schmutz in der Buchse und alles was sons ggf. im Signalweg liegt, wie z.B. gerade bei den NAS, auch die Backplane und deren Stecker / Buchsen für Kommunikationsprobleme sorgen.

Aber diese Kommunikationsfehler mit dem Host können niemals zu schwebenden Sektoren führen, da diese intern in der HDD auftreten während diese liest und daher nichts mit der Kommunikation zu tun haben. Sie können aber eben zu Verzögerungen führen, komischerweise sogar bei der Kommunikation mit anderen Laufwerken die selbst gar kein Problem haben, denn fehlerhafte Kommunikationen müssen wiederholt werden und irgendwas scheint im Host Controller oder in Windows scheint dies nicht perfekt parallel zu handhaben und dann auch Verzögerungen bei anderen Laufwerken zu verursachen.

 

[Atalanttore]

Deshalb haben Platten in echten RAIDs mit Redundanz normalerweise nie schwebende Sektoren, eben weil diese immer sofort wieder überschrieben werden und wenn doch, dann meistens weil jemand dafür nicht geeignete Desktop HDDs wie z.B. eine WD Blue ohne TLER an einem Hardware RAID Controller betreibt.

Was genau meinst du mit einem »echten RAID«?

Aber wie schon gesagt, bei dem Alter wäre ein Austausch angebracht, die Platte hat ihre Pflicht mehr als erfüllt. Und beachte das die aktuellen WD Red nun SMR haben, die ohne SMR nennen sich jetzt Red Plus. Die Red Pro und die Seagate IronWolf haben ebenfalls kein SMR.

Da die Backup-Festplatte nun ja doch keinen Schaden hat, steht mein Ausfallzähler für Festplatten von Seagate wieder bei 0. Deshalb habe ich mich für eine 6 TB Seagate IronWolf als Ersatzfestplatte für das NAS entschieden.

 

[Holt]

Was genau meinst du mit einem »echten RAID«?

Wie geschrieben, ein RAID (Redundant Array of Independent Disks) mit Redundanz. Es gibt ja auch RAID 0 und dies müsste eigentlich AID 0 heißen, da das R in RAID für Redundanz steht.

Da die Backup-Festplatte nun ja doch keinen Schaden hat, steht mein Ausfallzähler für Festplatten von Seagate wieder bei 0.

Wenn eine HDD mehr als 5 Jahre durchgehalten hat, kann man ihr einen Ausfall nicht ankreiden, denn dann hat sie ihre Pflicht erfüllt.