SMART-Werte richtig lesen: Festplattenausfälle vorhersagen, bevor das Backup fällig wird

September 2021, Rechenzentrum eines Kunden. Zwei von zwölf Platten in einem RAID-6-Array werfen am selben Tag SMART-Warnungen. Reallocated Sector Count bei Platte 4 springt von 0 auf 48. Platte 9 meldet 3 Pending Sectors. Der Kunde ruft an, Stimme zwischen Panik und „hab ich doch gesagt, wir hätten das letzte Jahr schon tauschen sollen".

Zwei Stunden später war das Array wieder gesund, weil jemand wusste, welche Werte wirklich zählen und welche nur Lärm sind. Genau darum geht es hier.

Was SMART eigentlich macht

SMART (Self-Monitoring, Analysis and Reporting Technology) ist in jeder Festplatte und SSD der letzten 20 Jahre eingebaut. Das Laufwerk führt Buch über seinen eigenen Zustand: Wie oft hat der Lesekopf nachjustieren müssen? Wie viele Sektoren sind defekt und wurden durch Reservesektoren ersetzt? Wie warm wurde die Platte in den letzten 24 Stunden?

Die Platte schreibt diese Werte in einen internen Speicher, der stromlos erhalten bleibt. Du kannst sie mit smartctl auslesen, dem Schweizer Taschenmesser aus dem smartmontools-Paket. Jeder Wert trägt eine ID, einen Rohwert (Raw Value) und bei vielen auch einen Schwellwert (Threshold). Unterschreitet der normalisierte Wert den Threshold, gilt die Platte als „FAILING_NOW".

Das klingt erstmal nach einem gelösten Problem. Ist es aber nicht, und zwar aus zwei Gründen: Erstens sagen die Hersteller-Thresholds oft nichts Brauchbares aus. Eine Platte kann wochenlang vor sich hin sterben, ohne dass SMART auf FAILING_NOW springt. Zweitens unterscheiden die wenigsten Admins zwischen Attributen, die echte physikalische Degradation anzeigen, und solchen, die auf ein lockeres Kabel hindeuten.

Genau diese Unterscheidung ist der Kern des Themas. Wer sie nicht macht, tauscht Platten ohne Grund oder lässt sterbende Platten zu lange im Array.

Die Platte ansprechen: smartctl in 30 Sekunden

Bevor wir in die Werte eintauchen, die Basics. So fragst du alle SMART-Daten einer Platte ab:

smartctl -a /dev/sda

Das -a steht für „all" und liefert: Geräteidentität, SMART-Feature-Status, die Attributtabelle, Fehlerlogs und Ergebnisse der Selbsttests. Für das schnelle Monitoring reicht die Attributtabelle:

smartctl -A /dev/sda

Die Ausgabe ist eine klassische Tabelle mit Spalten: ID, Attributname, Flag, Value, Worst, Threshold, Type, Updated, When_Failed, Raw_Value. Die drei wichtigsten Spalten sind Value (aktueller normalisierter Wert, startet meist bei 100 oder 200 und fällt bei Problemen), Threshold (der Hersteller-Grenzwert) und Raw_Value (die tatsächliche Zählung im Klartext).

Ein kurzer Check, ob überhaupt SMART aktiv ist:

smartctl -i /dev/sda | grep "SMART support"

Wenn da „SMART support is: Enabled" steht, bist du startklar. Bei „Available - device has SMART capability" ohne „Enabled" musst du es erst einschalten: smartctl -s on /dev/sda.

Für SSDs gibt es noch -x statt -a. Das zeigt zusätzlich NVMe-spezifische Logs wie Media Errors und Percentage Used. Aber das ist Stoff für einen eigenen Artikel.

Die Werte, die wirklich zählen

Nicht alle SMART-Attribute sind gleich. Manche sind Frühwarnzeichen für mechanischen Verschleiß, andere sind Nebelkerzen, die dich auf die falsche Fährte locken. Ich sortiere sie in drei Kategorien.

Kategorie 1: Rauch am Horizont: diese Werte sind echte Warnsignale

Reallocated Sectors Count (ID 5). Das ist der Klassiker. Ein Sektor auf der Plattenoberfläche ist physikalisch beschädigt oder kann nicht mehr zuverlässig gelesen werden. Die Firmware der Platte markiert ihn als defekt und zieht einen Sektor aus dem Reservepool. Der Raw_Value zeigt die absolute Anzahl umgelegter Sektoren.

Eine Handvoll (sagen wir 5 bis 20 bei einer Platte mit 100.000 Betriebsstunden) ist normal. Platten altern, Oberflächenfehler passieren. Was alarmierend ist: ein sprunghafter Anstieg innerhalb kurzer Zeit. Wenn der Wert von 8 auf 80 springt und nächste Woche auf 200, ist die Oberfläche am Zerfallen. Tausch die Platte, und zwar bald.

Ich hatte mal eine 4-TB-Seagate in einem Backup-Server, die über zwei Jahre bei 12 Reallocated Sectors stabil lief. Kein weiterer Anstieg, kein Leistungsverlust. Habe sie trotzdem im Auge behalten und nach 18 Monaten präventiv getauscht, aber es gab keinen Grund zur Eile.

Current Pending Sector Count (ID 197). Das sind Sektoren, die die Platte beim Lesen als problematisch eingestuft hat, aber noch nicht endgültig aufgegeben hat. Sie warten quasi auf eine Entscheidung: Entweder der Sektor wird beim nächsten Schreibzugriff überschrieben und funktioniert dann wieder, oder er wird endgültig als defekt markiert und ein Reallocated Sector ersetzt ihn.

Pending Sectors sind gefährlicher als bereits umgelegte, weil sie Instabilität signalisieren. Ein laufendes System mit Pending Sectors kann jederzeit Lesefehler produzieren. In einem RAID-Verbund heißt das: Der Controller muss den Sektor aus der Parität rekonstruieren, was den Rebuild im Fehlerfall erschwert.

Faustregel: Pending Sectors, die nach einer Woche nicht verschwunden oder umgelegt sind, bedeuten Ärger. Bei mehr als 5 Pending Sectors gleichzeitig würde ich die Platte sofort aus dem Produktivbetrieb nehmen.

Offline Uncorrectable Sector Count (ID 198). Sektoren, die beim Lesen endgültig nicht mehr gelesen werden konnten. Das ist die harte Variante von Pending. Jeder dieser Sektoren ist ein Datenverlust auf Plattenebene. Im RAID-Verbund kann die Parität oder Spiegelung das abfangen, aber das ist kein Zustand, den man ignorieren sollte.

Spin Retry Count (ID 10). Der Motor versucht, die Platte hochzudrehen, scheitert und versucht es erneut. Jeder Retry ist ein mechanisches Problem: Der Motor kommt nicht auf Nenndrehzahl, die Lager sind schwergängig, oder die Spannungsversorgung ist instabil. Schon ein einziger Spin Retry bei einer gesunden Platte ist Grund für einen genaueren Blick. Ab 10 Retries würde ich die Platte als ausfallgefährdet einstufen.

Ich erinnere mich an einen Server, bei dem der Spin Retry Count innerhalb von drei Tagen von 0 auf 47 stieg. Die Platte lief noch, SMART-Status war immer noch „PASSED". Zwei Tage später war sie im BIOS nicht mehr sichtbar. Der Motor hatte endgültig aufgegeben.

Kategorie 2: Wichtige Kontextwerte: die zweiten Indikatoren

Reported Uncorrectable Errors (ID 187). Fehler, die von der Plattenelektronik nicht korrigiert werden konnten und an das Betriebssystem weitergereicht wurden. Anders als ID 198 zählt dieser Wert alle unkorrigierbaren Fehler, nicht nur die während Offline-Scans. Ein einzelner Eintrag kann ein kosmischer Strahlungstreffer sein. Mehrere Einträge sind ein Muster.

Temperature (ID 194 oder 231). Temperatur tötet Platten. Google hat 2007 in einer vielzitierten Studie gezeigt, dass Festplatten unter 25 °C und über 45 °C häufiger ausfallen. Der Sweetspot liegt zwischen 30 und 40 °C. Was viele nicht wissen: Temperaturschwankungen sind schlimmer als konstant hohe Temperaturen. Eine Platte, die im Tagesverlauf zwischen 28 und 48 °C pendelt, altert schneller als eine, die konstant bei 44 °C läuft.

Der Raw_Value bei Temperatur-Attributen ist oft kodiert. Bei manchen Herstellern steht die Temperatur in den oberen 16 Bit, bei anderen in den unteren. smartctl parst das normalerweise und zeigt die Temperatur in der rechten Spalte in °C an.

Load Cycle Count (ID 193). Zählt, wie oft der Lesekopf in die Parkposition gefahren ist. Bei 2,5-Zoll-Platten in Laptops ist dieser Wert oft absurd hoch, weil aggressive Power-Management-Einstellungen den Kopf alle paar Sekunden parken. Western-Digital-Green-Platten waren berüchtigt dafür: Load Cycle Counts von 300.000 nach einem Jahr waren keine Seltenheit. Das Problem ist nicht der Wert selbst, sondern dass häufiges Parken mechanischen Verschleiß bedeutet.

Für Server-Platten, die 24/7 laufen, sollte der Load Cycle Count niedrig bleiben. Ein Anstieg ohne ersichtlichen Grund (etwa weil jemand hdparm -B auf einem Server aktiviert hat) gehört untersucht.

Kategorie 3: Nebelkerzen: Werte, die selten die Platte meinen

UDMA CRC Error Count (ID 199). Der absolute Klassiker unter den Fehlalarmen. Dieser Wert zählt Übertragungsfehler zwischen Platte und Host-Controller, also Fehler auf dem SATA- oder SAS-Kabel. Jedes Mal, wenn ein Datenpaket mit falscher Prüfsumme ankommt, wird der Zähler erhöht.

Wenn ID 199 steigt, tausch das Kabel, nicht die Platte. Ich habe in 15 Jahren keine einzige Platte gesehen, bei der UDMA CRC Errors tatsächlich von der Platte selbst verursacht wurden. Es ist fast immer ein billiges China-SATA-Kabel, ein halb eingesteckter Stecker oder ein überlasteter SAS-Expander.

Raw Read Error Rate (ID 1) und Seek Error Rate (ID 7). Diese Werte sind herstellerspezifisch kodiert und ohne Entschlüsselungstabelle der Firmware praktisch nutzlos. Seagate, WD und Toshiba verwenden alle unterschiedliche Kodierungen. Der normalisierte Value-Wert kann dir einen groben Trend zeigen (fällt er unter 60, stimmt was nicht), aber auf den Raw_Value kannst du nichts geben. Verschwende keine Zeit damit, diese Zahlen zu interpretieren.

Hardware ECC Recovered (ID 195). Zählt Fehler, die vom internen ECC der Platte korrigiert wurden. Das ist Normalbetrieb. Jede moderne Festplatte hat eine Fehlerrate, die ohne ECC-Korrektur katastrophal wäre. Ein hoher Wert ist also per se kein Problem. Erst ein sprunghafter Anstieg in Kombination mit anderen Attributen ist relevant.

Wie Backblaze mit SMART Ausfälle vorhersagt

Backblaze betreibt über 250.000 Festplatten und veröffentlicht seit 2013 vierteljährliche Ausfallstatistiken. Deren Daten sind die beste öffentlich verfügbare Quelle, um zu verstehen, welche SMART-Werte wirklich mit Ausfällen korrelieren.

Die fünf Attribute mit der stärksten Korrelation zu Plattenausfällen sind laut Backblaze: SMART 5 (Reallocated Sectors), SMART 187 (Reported Uncorrectable), SMART 188 (Command Timeout), SMART 197 (Current Pending Sector) und SMART 198 (Offline Uncorrectable). Wenn eine Platte einen oder mehrere dieser Werte über Null hat, ist ihre Ausfallwahrscheinlichkeit in den nächsten 60 Tagen signifikant erhöht.

Backblaze hat außerdem festgestellt, dass Platten mit SMART 5 > 0 eine 8-mal höhere Ausfallwahrscheinlichkeit haben als Platten mit SMART 5 = 0. Bei SMART 197 > 0 ist die Rate sogar 14-mal höher. Das sind keine theoretischen Zahlen, das sind 250.000 Platten über zehn Jahre.

Für Admins mit kleineren Installationen heißt das: Vertrau den fünf kritischen Werten und ignorier den Rest, solange der Gesamtzustand stabil bleibt.

Monitoring-Strategie: SMART in den Alltag einbauen

SMART-Daten einmal auszulesen bringt nichts. Der Wert liegt im Trend. Eine Platte, die innerhalb einer Woche von 0 auf 15 Reallocated Sectors springt, ist ein ganz anderes Kaliber als eine, die seit zwei Jahren bei 15 steht.

Ich setze auf drei Ebenen:

Ebene 1: smartd. Der Dämon aus dem smartmontools-Paket überwacht alle Platten im Hintergrund und schreibt bei Änderungen ins Syslog oder verschickt Mails. Konfiguration in /etc/smartd.conf:

/dev/sda -a -o on -S on -s (S/../.././02|L/../../7/03) -m admin@example.com
/dev/sdb -a -o on -S on -s (S/../.././02|L/../../7/03) -m admin@example.com

Das aktiviert automatische Offline-Tests, SMART-Attribut-Überwachung, einen kurzen Selbsttest täglich um 2 Uhr nachts und einen langen Test sonntags um 3 Uhr. Bei Änderungen geht eine Mail raus.

Ebene 2: Kurzer Check im Daily-Grind. Ein Einzeiler für die tägliche Kontrolle:

for d in /dev/sd?; do echo "=== $d ==="; smartctl -A "$d" | grep -E 'Reallocated|Pending|Offline_Uncorrectable|Spin_Retry|UDMA_CRC'; done

Das filtert die fünf Attribute, die dich wirklich interessieren. Dauert drei Sekunden und gibt dir ein Gefühl für den Zustand deiner Platten.

Ebene 3: Prometheus + node_exporter mit textfile collector. Wenn du Prometheus im Einsatz hast, kannst du SMART-Daten per Cronjob in ein Textfile schreiben und vom node_exporter einsammeln lassen. Das gibt dir Grafana-Dashboards mit historischen Trends: Reallocated Sectors über Zeit, Temperaturverläufe, alles. Dazu ein Cronjob wie:

#!/bin/bash
# /etc/cron.daily/smart-prom
OUT=/var/lib/node_exporter/smart.prom
echo "# HELP smart_reallocated_sectors Reallocated sector count" > "$OUT"
echo "# TYPE smart_reallocated_sectors gauge" >> "$OUT"
for d in /dev/sd?; do
  DISK=$(basename "$d")
  VAL=$(smartctl -A "$d" | grep "Reallocated_Sector_Ct" | awk '{print $NF}')
  echo "smart_reallocated_sectors{disk=\"$DISK\"} $VAL" >> "$OUT"
done

Der RAID-Rechner kommt ins Spiel: Planung für nach dem Ausfall

Wenn SMART dir sagt, dass eine Platte stirbt, musst du zwei Dinge tun: die Platte tauschen und sicherstellen, dass das Array den Rebuild überlebt. Das ist der Moment, in dem der bitcalc RAID-Rechner relevant wird.

Zwei Szenarien aus der Praxis:

Szenario 1: RAID 5 mit 4 × 18 TB. Platte 2 meldet 24 Reallocated Sectors mit steigender Tendenz. Du hast eine Hot-Spare und startest den Rebuild. Die Frage, die sich jetzt stellt: Überlebt das Array den Rebuild? RAID 5 hat keine Redundanz während des Rebounds. Wenn eine zweite Platte während des 40-Stunden-Rebuilds einen einzigen nicht lesbaren Sektor hat, verlierst du Daten. Bei 18-TB-Platten mit einer URE-Rate von 1 in 10^14 Bit ist die Wahrscheinlichkeit dafür nicht trivial.

Der RAID-Rechner zeigt dir genau diese Perspektive: verfügbare Kapazität nach RAID-Level, aber auch die Redundanzsituation während und nach dem Rebuild. In diesem Szenario würdest du sehen, dass RAID 5 bei dieser Plattengröße ein Risiko darstellt und dass ein Upgrade auf RAID 6 (4+2) die Rebuild-Sicherheit massiv erhöht.

Szenario 2: Du planst ein neues NAS. SMART-Daten deiner alten Platten zeigen dir, welche Modelle bei dir unter welchen Bedingungen lange halten. Mit dem RAID-Rechner spielst du verschiedene Konfigurationen durch: Was kostet RAID 10 mit 8 Platten vs. RAID 6 mit 6 Platten? Wie viel nutzbare Kapazität bleibt? Wie viele IOPS kannst du erwarten? Das sind Entscheidungen, die du vor dem Kauf triffst, nicht während das Array degradiert ist und du unter Zeitdruck stehst.

Ich habe mir angewöhnt, bei jeder neuen Storage-Anschaffung erst den RAID-Rechner zu bemühen und dann die Platten zu bestellen. Spart Geld und verhindert die klassische „hätte ich mal lieber"-Situation drei Jahre später.

SMART-Selbsttests: Kurz, lang und was die Ergebnisse bedeuten

Neben den Attributwerten bietet SMART zwei eingebaute Testmodi, die jeder Admin regelmäßig nutzen sollte. Der kurze Test (smartctl -t short /dev/sda) dauert etwa zwei Minuten und prüft die Elektronik, den Motor und einen kleinen Teil der Oberfläche. Der lange Test (smartctl -t long /dev/sda) liest die gesamte Plattenoberfläche Sektor für Sektor und kann je nach Plattengröße mehrere Stunden dauern. Bei 18 TB sind 24 Stunden realistisch.

Den Status eines laufenden Tests fragst du mit smartctl -l selftest /dev/sda ab. Die Ausgabe zeigt dir alle bisherigen Testergebnisse mit Zeitstempel. Ein „Completed without error" ist, was du sehen willst. „Completed: read failure" bei LBA 1234567890 heißt: exakt dieser Sektor ist defekt. Merk dir die LBA-Adresse und beobachte, ob die Platte den Sektor beim nächsten Schreibzugriff umlegt oder ob der Fehler bestehen bleibt.

Ein konkreter Fall: Auf einem Kunden-Server hatte ich einen Long Self-Test, der bei 90 % mit einem Lesefehler abbrach. Drei Tage später derselbe Test, Fehler bei 90 %, andere LBA. Eine Woche später Fehler bei 30 %, 60 % und 90 %. Die Oberfläche zerfiel. Wir haben die Platte noch am selben Tag getauscht, und der Rebuild lief sauber durch. Hätten wir nur auf die SMART-Attribute geschaut (die zu dem Zeitpunkt alle im grünen Bereich waren), wäre die Platte vermutlich noch zwei Wochen im Array geblieben, bis sie endgültig ausgefallen wäre.

Fazit: Fünf Dinge, die du morgen anders machen solltest

SMART ist ein Frühwarnsystem, kein Orakel. Die Daten sind da, sie sind kostenlos, und sie werden von den meisten Admins ignoriert, bis es zu spät ist. Dabei reichen drei Minuten pro Woche, um den Zustand deiner Platten zu kennen.

Meine fünf Takeaways aus 15 Jahren Plattenwartung:

1. Reallocated und Pending Sectors sind die einzigen SMART-Werte, die dich nachts wachhalten sollten. Alles andere ist Kontext oder Lärm.

2. UDMA CRC Errors sind fast nie die Platte. Tausch das Kabel, bevor du die Platte ausbaust. Spart dir peinliche RMA-Rückläufer.

3. Trend ist alles. Ein Wert, der seit zwei Jahren stabil ist, ist irrelevant. Ein Wert, der innerhalb einer Woche eskaliert, ist ein Notfall.

4. SMART sagt nicht alles. 20 bis 30 Prozent aller Platten sterben ohne Vorwarnung. SMART ist eine Versicherung, keine Garantie.

5. Nutze den RAID-Rechner, bevor du in Panik gerätst. Wenn eine Platte SMART-Warnungen wirft, willst du wissen, wie dein Array den Rebuild übersteht und ob deine Redundanz für die aktuelle Plattengröße überhaupt noch ausreicht.

Die ruhigsten Nächte hatte ich immer dann, wenn ich morgens wusste, welche Platte als nächstes fällig ist, und nicht um drei Uhr nachts von einem degradierten Array geweckt wurde.