Festplattenzustand überwachen mit smartctl, nvme smart-log und geplanten smartd-Selbsttests

Ziel

Eine dauerhafte, alarmierende Überwachung des physischen Festplattenzustands auf einem Server einrichten, für SATA/SAS-Laufwerke über SMART und für NVMe-Laufwerke über deren eigene Log-Seite, statt sich darauf zu verlassen, dass das Betriebssystem den Ausfall eines Laufwerks bemerkt.

Voraussetzungen

Root-Zugriff; smartmontools für ATA/SCSI-Laufwerke installiert; nvme-cli für NVMe-Geräte installiert; Gerätepfade bekannt (lsblk).

Schritte

1. Den Gesamtzustand eines SATA/SAS-Geräts schnell prüfen: smartctl -H /dev/sda. Laut smartctl(8) gibt -H/--health den Gesundheitsstatus des Geräts aus ("prints the health status of the device"). Ein negatives Ergebnis bedeutet laut derselben Seite, dass das Gerät bereits ausgefallen ist oder innerhalb von 24 Stunden einen Ausfall erwarten lässt; dann sollten alle noch darauf vorhandenen Daten umgehend gesichert werden.
2. Für die Fehleranalyse das Gesamtbild abrufen: smartctl -a /dev/sda. Der Befehl gibt alle SMART-Informationen zur Platte aus ("prints all SMART information about the disk"), darunter die Attributtabelle, das Fehlerlog und das Selbsttest-Log.
3. Bei einem NVMe-Gerät funktioniert auch smartctl -a /dev/nvme0; alternativ lässt sich die Log-Seite direkt auslesen: nvme smart-log /dev/nvme0. Laut nvme-smart-log(1) liest der Befehl die NVMe-SMART-Log-Seite eines NVMe-Geräts aus und gibt die zurückgelieferte Struktur aus ("retrieves the NVMe SMART log page from an NVMe device and provides the returned structure"). Die Felder umfassen unter anderem ein Critical-Warning-Byte, die Temperatur, den Verschleissgrad (percentage used) und die verfügbare Reserve (available spare).
4. Auf die wichtigsten Attribute achten: Bei ATA-Laufwerken sind steigende Werte über null bei den Zählern für reallozierte bzw. ausstehende Sektoren und bei den End-to-End-Fehlerzählern frühe Ausfallsignale. Bei NVMe entsprechen dem ein Critical-Warning-Byte ungleich null oder eine verfügbare Reserve, die sich ihrem Schwellenwert nähert.
5. Wiederkehrende Selbsttests und Meldungen einplanen, statt nur bei Bedarf zu prüfen: In /etc/smartd.conf (RHEL/Fedora: /etc/smartmontools/smartd.conf) startet eine Gerätezeile wie /dev/sda -a -o on -S on -s S/../.././02 -m admin@example.org -M exec /usr/local/bin/smart-alert.sh täglich zwischen 2 und 3 Uhr einen kurzen Selbsttest; das entspricht genau dem Beispiel in smartd.conf(5) für diesen Zeitplan. Das entsprechende Beispiel der Man-Page für einen wöchentlichen langen Test lautet -s L/../../7/04 (langer Test, jeden Sonntag, 4 bis 5 Uhr). Die Option -s REGEXP führt einen Test aus, wenn die 12-stellige Zeichenfolge T/MM/DD/d/HH auf den regulären Ausdruck passt. -o/-S gelten nur für ATA-Laufwerke; -m (Mailversand) setzt einen funktionierenden lokalen Mail Transfer Agent voraus. smartd ignoriert alle Zeilen nach einer nicht auskommentierten DEVICESCAN-Zeile, die viele Distributionen standardmässig mitliefern. Diese Zeile daher auskommentieren oder die Gerätezeilen davor platzieren.
6. smartd aktivieren und starten: systemctl enable --now smartd. Prüfen, ob die Konfiguration übernommen wurde: journalctl -u smartd -n 30.

Erwartetes Ergebnis

smartctl -H meldet PASSED (oder einen konkreten Fehlergrund); nvme smart-log liefert eine Struktur mit critical_warning: 0; das Log von smartd zeigt, dass die geplanten Selbsttests zu den konfigurierten Zeiten starten, und ein fehlgeschlagener Test oder ein Attribut, das seinen Schwellenwert überschreitet, löst den konfigurierten Mail- bzw. Exec-Alarm aus.

Grenzen und Prüfbasis

Basiert auf smartctl(8), smartd.conf(5) und nvme-smart-log(1). Für rein lesende Gesundheitsprüfungen ist kein Rückgängigmachen nötig; um die geplanten Tests zu beenden, die Gerätezeile aus smartd.conf entfernen und smartd neu starten. Ein Gesamtergebnis "PASSED" garantiert nicht, dass ein Laufwerk nicht bald ausfällt; steigende Attributzähler sind daher mindestens so wichtig zu nehmen wie das zusammenfassende Urteil. Hinter Hardware-RAID-Controllern oder USB-Bridges brauchen smartctl und smartd meist einen Gerätetyp über -d (z. B. -d megaraid,N), um überhaupt auf das physische Laufwerk zuzugreifen.