Die kurze Antwort: Wenn das Array eine Platte auswirft, die nach einem Neustart zurückkehrt und ganz normal liest, steckt meist ein Timeout-Konflikt dahinter. Der Linux-Kernel gibt das Warten nach dreißig Sekunden auf, während eine Desktop-Platte an einem problematischen Sektor auch über zwei Minuten lang weiterliest – und das Array erklärt sie in der Zwischenzeit für tot. Deshalb haben Platten für den NAS-Einsatz die Begrenzung der Fehlerbehebung aktiviert (ERC bei Seagate, TLER bei Western Digital) und lassen sich nach sieben Sekunden unterbrechen. Bei einer Platte, die das nicht beherrscht, wird stattdessen das Timeout auf Systemseite angehoben. Bevor Sie jedoch irgendetwas einstellen, müssen Sie wissen, ob die Platte wegen des Wartens ausgefallen ist oder weil sie tatsächlich stirbt.
Was in diesem Array wirklich passiert ist
Das Wiki des Linux-RAID beschreibt den korrekten Ablauf so: Die Platte stößt auf einen Sektor, der sich nicht im ersten Anlauf lesen lässt, „bemüht sich” eine Weile stärker, gibt dann auf und meldet dem System einen Fehler. Der RAID-Code errechnet, wie die Daten hätten aussehen sollen, und schreibt sie zurück auf die Platte. Ein solcher Haken ist normaler Betrieb und löst sich, sofern die Platte nicht stirbt, von selbst – ein fehlgeschlagener Lesevorgang an einem Sektor bedeutet nämlich nicht, dass an dieselbe Stelle nicht mehr geschrieben werden kann.
Kaputt geht es in dem Moment, in dem die Platte den Fehler nicht rechtzeitig zurückmeldet. Der Kernel wartet dreißig Sekunden und gibt dann auf. Der RAID-Code errechnet die Daten und will sie zurückschreiben, doch die Platte versucht weiterhin zu lesen und antwortet nicht – also schließt das Array, dass sie tot ist, und wirft sie aus dem Verbund. Das Wiki fasst es unverblümt zusammen: So kann ein einziger Lesefehler bei solchen Platten ein ganzes Array töten.
Dabei verhält sich die Platte genau so, wie sie konstruiert wurde. Eine einzelne Platte im Rechner hat keine andere Quelle für die Daten, also ist es richtig, so lange wie möglich weiterzulesen. In einem redundanten Array ist es umgekehrt: Die Daten liegen auch anderswo, und eine Platte, die eine Anforderung zwei Minuten lang festhält, ist für das Array schlimmer als eine Platte, die den Misserfolg schnell eingesteht. Dasselbe Stück Blech ist damit im PC „in Ordnung” und im NAS „defekt”.
Woran Sie erkennen, dass es genau darum geht
Ein Timeout-Konflikt hat mehrere recht typische Merkmale:
- Die Platte ist auf einen Schlag aus dem Array verschwunden, nicht nach Wochen allmählich sinkender Leistung.
- Nach einem Neustart oder nach dem Herausziehen und erneuten Einschieben in den Schacht meldet sie sich zurück und lässt sich normal lesen.
- SMART auf der ausgeworfenen Platte sieht nicht aus wie bei einer Platte, die stirbt (wie sich das unterscheiden lässt, behandelt der Artikel wie Sie erkennen, dass eine HDD stirbt).
- Im Array stecken Desktop-Platten oder zumindest eine solche, die jemand beim Erweitern ergänzt hat.
Entscheidend ist jedoch eine einzige Frage: Kann diese Platte die Dauer der Fehlerbehebung überhaupt begrenzen? Die Antwort liefert smartctl -l scterc /dev/sda. Zeigt die Ausgabe, dass die Platte SCT Error Recovery Control nicht unterstützt, haben Sie die Ursache auf dem Tisch.
Besonders tückisch ist die Kombination mit der SMR-Technologie. Das Wiki führt an, dass SMR-Platten beim Umsortieren der Daten auch über zehn Minuten hängen, sodass keine vernünftige Timeout-Einstellung sie rettet. Ob Ihr Modell zu dieser Gruppe gehört, klärt die Übersicht zu CMR und SMR.
Welche Platten das Limit haben und welche nicht
Hier lohnt es sich, nicht auf das zu vertrauen, was „allgemein bekannt” ist, sondern auf das, was der Hersteller in der Dokumentation stehen hat.
| Plattenserie | Was der Hersteller zum Limit angibt | Quelle |
|---|---|---|
| WD Red, WD Gold, Ultrastar | TLER ist aktiviert, die Fehlerbehebung ist auf sieben Sekunden begrenzt und lässt sich nicht abschalten | WD support, TLER on RAID edition internal drives |
| WD Red Plus | Das Product Brief beschreibt die NASware-Abstimmung für RAID-NAS, das Wort TLER kommt darin aber nicht vor – beim konkreten Exemplar muss der Zustand per smartctl geprüft werden | Product brief WD Red Plus |
| WD Red Pro | Dasselbe: Das Datenblatt spricht von NASware und schweigt zu TLER – am Exemplar prüfen | Data sheet WD Red Pro |
| Seagate IronWolf | Die Parametertabelle hat direkt eine Zeile „Error Recovery Control” mit dem Wert Yes bei allen Modellen | Datasheet IronWolf |
| Seagate IronWolf Pro | Die Firmware AgileArray aktiviert laut Datenblatt Dual-Plane-Balancing und Time-Limited Error Recovery | Datasheet IronWolf Pro |
| Günstige Desktop-Serien | Die meisten modernen günstigen Desktop-Platten lassen die Einstellung der Fehlerbehebung nicht zu | Linux RAID wiki, Timeout Mismatch |
Achten Sie darauf, was die Tabelle nicht sagt. Dass eine Serie das Limit hat, bedeutet noch nicht, dass Ihr konkretes Exemplar es auf einen vernünftigen Wert gesetzt hat – das Wiki weist darauf hin, dass auch ältere Platten mit ERC-Unterstützung oft eine ungeeignete Einstellung haben. Die verlässliche Quelle der Wahrheit ist die Ausgabe der Platte, die in Ihrem Schacht steckt. Bei der Auswahl neuer Exemplare hilft der Vergleich von WD Red, IronWolf und Toshiba N300.
Was sich einstellen lässt
Auf einem Linux-Server mit mdadm gibt es im Grunde zwei Hebel, und welcher davon genutzt wird, hängt davon ab, was die Platte beherrscht.
Die Platte beherrscht ERC. Sie setzen die Dauer der Fehlerbehebung auf sieben Sekunden:
smartctl -l scterc,70,70 /dev/sda
Die Werte sind in Zehntelsekunden angegeben – das ist die häufigste Quelle von Irrtümern, denn 70 sieht nach siebzig Sekunden aus. Das smartctl-Handbuch sagt es genau: Die Argumente READTIME und WRITETIME sind in Zehntelsekunden, der Wert 0 schaltet die Funktion ab, Werte unter 65 werden vermutlich nicht unterstützt, und für RAID werden typischerweise 70,70 gesetzt. Zwanzig Sekunden wären also scterc,200,200.
Die Einstellung ist im Ausgangszustand flüchtig. Neuere smartctl-Versionen beherrschen die Option ,p, nach der die Werte auch das Aus- und Einschalten überstehen – das setzt allerdings eine Platte nach ATA ACS-4 oder neuer voraus. Bei allen übrigen Platten gilt, was das Wiki empfiehlt: die Einstellung bei jedem Start ausführen, denn günstigere Exemplare vergessen beim Abschalten des Systems alles.
Die Platte beherrscht ERC nicht. Dann wird das Timeout auf Kernel-Seite angehoben, damit es länger ist als das, was sich die Platte erlaubt:
echo 180 > /sys/block/sdX/device/timeout
Drei Minuten reichen auch für eine Desktop-Platte, die über zwei Minuten hängt. Der Wert in /sys überlebt keinen Neustart, also gehört auch das ins Startskript.
Und eine Falle, auf die das Wiki eigens hinweist: Bei Platten, die SCT überhaupt nicht unterstützen, scheitert der Versuch, ERC zu setzen, zwar – liefert aber den Rückgabewert null. Ein Skript, das sich nur nach dem Rückgabewert richtet, bewertet eine solche Platte also als in Ordnung. Lesen Sie den Wert deshalb nach jeder Einstellung wieder zurück.
Synology und QNAP: Was der Administrator in der Hand hat
Bei fertigen NAS-Boxen spielt man nicht mit Timeouts – man arbeitet mit dem, was das System des Herstellers bietet.
Bei Synology reißt eine deaktivierte Platte den gesamten Storage-Pool in den Zustand degraded. Der Pool bleibt dabei zugänglich, weil kein Datenverlust eingetreten ist. Die Reaktivierung einer deaktivierten Platte ist laut Hersteller-KB einfach: aus dem Schacht ziehen, ein paar Sekunden warten und wieder einschieben. Bevor Sie eine neue Platte bestellen, gehen Sie das offizielle Verfahren durch, mit dem sich eine defekte Platte von einem defekten Schacht unterscheiden lässt – genau in dieser Situation wird unnötig Hardware gekauft. Was die einzelnen Meldungen in DSM bedeuten, behandelt der Artikel Storage Pool Degraded oder Volume Crashed.
Bei QNAP wechselt der Zustand der RAID-Gruppe beim Trennen von Platten auf Error, und Volumes wie auch Storage-Pools fallen in den Zustand Inactive. Die QTS-Dokumentation beschreibt die Wiederherstellung über Storage & Snapshots und die Funktion Recover RAID, mit einer Bedingung, die sich nicht umgehen lässt: Jede Platte muss zurück in ihre ursprüngliche Position. Zugleich weist sie darauf hin, dass diese Wiederherstellung nur bei vorübergehend getrennten Platten hilft, nicht bei einem echten Plattenausfall. Daran schließt QNAP RAID Group Degraded oder Volume Read-Only an.
Wann es nicht mehr um ein Timeout geht, sondern um einen Defekt
Der Timeout-Konflikt ist nur eine der Erklärungen. Setzen Sie eine ausgeworfene Platte nicht blind zurück ins Array und starten Sie keinen Rebuild, solange Sie nicht wissen, warum sie ausgefallen ist. Steckt tatsächlich eine unlesbare Stelle dahinter, liest der Rebuild die gesamte Oberfläche der übrigen Platten – und genau das ist die Belastung, nach der die zweite Platte zusammenbricht. Die Mechanik dieses Versagens behandelt warum ein Rebuild RAID-Arrays tötet.
Lassen Sie das Array in Ruhe, wenn die Platte klackt, auch ohne Last aus der Liste verschwindet, wiederholt an derselben Stelle ausfällt oder wenn bereits mehrere Platten ein Problem melden. Synology hat für eine steigende Zahl fehlerhafter Sektoren ein eigenes Diagnoseverfahren, und es lohnt sich, es durchzugehen, bevor irgendetwas anläuft. Wann es sicherer ist, die Daten außerhalb des Arrays zu holen, beschreiben wie Sie Daten aus einem NAS holen und Datenrettung aus einem RAID-Array.
Häufige Fragen
Warum kehrt die Platte nach einem Neustart zurück, wenn sie doch „defekt” ist?
Weil sie nicht defekt sein muss. Das Array hat sie dafür ausgeworfen, dass sie nicht rechtzeitig geantwortet hat, nicht dafür, dass sie nicht lesen könnte. Das bedeutet aber nicht, dass alles in Ordnung ist – beim nächsten Mal wiederholt es sich.
Kann ich ERC auch auf einer Platte einstellen, die es laut Ausgabe nicht unterstützt?
Nein. Bleibt nur, das Kernel-Timeout auf 180 Sekunden anzuheben und damit zu rechnen, dass das Array bei einem Lesefehler minutenlang wartet. Die dauerhafte Lösung ist der Tausch gegen ein Exemplar, das das Limit ab Werk hat.
Gilt das auch für SMR-Platten?
Bei SMR reicht das nicht. Laut Wiki hängen SMR-Platten auch über zehn Minuten, und ein Skript zur Änderung des Timeouts richtet dagegen nichts aus.
Wie finde ich heraus, ob das Problem in der Platte oder im Schacht steckt?
Die Platte in eine andere Position umstecken und beobachten, ob der Fehler mit der Platte mitwandert oder im Schacht bleibt. Synology hat dafür eine eigene Anleitung, und es ist vernünftig, sie durchzugehen, bevor Sie Ersatz bestellen.
Kann ich ERC auf einem fertigen NAS manuell einstellen?
Die genannten Befehle setzen einen Shell-Zugang auf einem Linux-Server voraus. Bei einer fertigen NAS-Box ist es praktischer, Platten mit ab Werk aktiviertem Limit zu wählen und sich an die Diagnostik des Herstellers zu halten.
Quellen
- Linux RAID wiki, Timeout Mismatch (archivierte Seite, letzte Änderung 19. 5. 2022) — https://archive.kernel.org/oldwiki/raid.wiki.kernel.org/index.php/Timeout_Mismatch.html
- smartctl(8), Option
-l scterc— https://manpages.debian.org/bookworm/smartmontools/smartctl.8.en.html - Western Digital, TLER on RAID edition internal drives cannot be disabled — https://support-en.wd.com/app/answers/detailweb/a_id/3562/~/tler-on-raid-edition-internal-drives-cannot-be-disabled
- Seagate, Datenblatt IronWolf — https://www.seagate.com/www-content/datasheets/pdfs/ironwolf-18tb-DS1904-20-2111US-en_US.pdf
- Seagate, Datenblatt IronWolf Pro — https://www.seagate.com/files/www-content/datasheets/pdfs/ironwolf-pro-20tb-DS1914-19-2112US-en_US.pdf
- Western Digital, Product Brief WD Red Plus — https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-red-plus-hdd/product-brief-western-digital-wd-red-plus-hdd.pdf
- Western Digital, Data Sheet WD Red Pro — https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-red-pro-hdd/data-sheet-wd-red-pro-hdd.pdf
- Synology, Verwaltung von Laufwerken im Storage Manager — https://kb.synology.com/en-ro/DSM/help/DSM/StorageManager/disk
- Synology, Reparatur eines Storage-Pools — https://kb.synology.com/en-us/DSM/help/DSM/StorageManager/storage_pool_repair?version=7
- Synology, wie man ein NAS-Problem von einem Platten-Problem unterscheidet — https://kb.synology.com/en-us/DSM/tutorial/How_do_I_know_whether_the_problem_is_with_my_Synology_NAS_or_drive_when_drive_errors_occur
- Synology, Warnungen zu fehlerhaften Sektoren — https://kb.synology.com/en-global/DSM/tutorial/How_to_diagnose_drives_health_status_when_receiving_bad_sector_warning
- QNAP, Recovering a RAID group with an Error status (QTS 5.2.x) — https://docs.qnap.com/operating-system/qts/5.2.x/en-us/recovering-a-raid-group-with-an-error-status-7E19C750.html
Fällt Ihnen eine Platte aus dem Array und Sie wissen nicht, ob sie defekt oder nur langsam ist? Wir gehen mit Ihnen Logs und SMART-Ausgaben durch, bevor ein Rebuild anläuft – im Rahmen der IT-Betreuung für Unternehmen ebenso wie einmalig als IT-Audit. Ist das Array bereits ausgefallen, schließt die Datenrettung aus RAID und NAS an. Melden Sie sich über den Kontakt, telefonisch unter +420 775 556 063 oder per E-Mail an info@ithope.cz. Ziehen Sie die Platten vorerst nicht aus den Schächten und vertauschen Sie sie vor allem nicht – die Reihenfolge ist bei der Wiederherstellung entscheidend.
Wo Sie uns finden
ITHOPE ist eine Firma aus Brno, Tschechien: wir machen Datenrettung von Festplatten, RAID und NAS, PC- und Notebook-Service und IT für Unternehmen, alles im eigenen Labor in der Viniční 3587/216, 615 00 Brno.
Telefon +420 775 556 063 (rund um die Uhr). Das Gerät können Sie persönlich bringen oder per Kurier schicken (Zásilkovna, PPL).