Überarbeitet am 9. September 2026.
Bei einem Server gehören Festplatten und SSDs für mich zu den Dingen, die ich lieber kontrolliere, bevor sie sich mit einem Totalausfall melden. Dafür sind die Smartmontools unter Linux weiterhin eines der wichtigsten Werkzeuge.
Das Paket enthält vor allem smartctl für manuelle Prüfungen und smartd für die laufende Überwachung im Hintergrund. Aktuell ist Smartmontools 7.5.
Installation unter Debian und Ubuntu
sudo apt update
sudo apt install smartmontools
Version prüfen:
smartctl --version
Unter Debian Trixie ist Smartmontools 7.5 beispielsweise auch über die Backports verfügbar.
Welche Laufwerke sind vorhanden?
Für einen schnellen Überblick:
lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,MOUNTPOINTS
Typische Gerätenamen sind:
/dev/sdafür SATA/SAS-Laufwerke,/dev/nvme0beziehungsweise/dev/nvme0n1für NVMe.
Smartmontools kann unterstützte Geräte auch selbst suchen:
sudo smartctl --scan
Kompletten SMART-Bericht anzeigen
Bei einer SATA-Festplatte oder SSD:
sudo smartctl -a /dev/sda
Für ausführlichere Informationen:
sudo smartctl -x /dev/sda
Bei NVMe funktioniert entsprechend:
sudo smartctl -a /dev/nvme0
Smartmontools 7.5 unterstützt auch aktuelle NVMe-SMART-/Health-Informationen und Selbsttests.
Nicht nur auf „PASSED“ schauen
Ein globales SMART-Ergebnis wie PASSED ist hilfreich, aber kein Freifahrtschein. Ein Laufwerk kann bereits auffällige Werte zeigen, bevor der Gesamtstatus endgültig auf Fehler springt.
Bei klassischen HDDs achte ich besonders auf:
- Reallocated Sector Count – bereits ersetzte problematische Sektoren,
- Current Pending Sector – aktuell verdächtige, noch nicht stabil lesbare Sektoren,
- Offline Uncorrectable – nicht korrigierbare Sektoren,
- Fehler- und Selbsttestprotokolle.
Ein einzelner herstellerspezifischer Rohwert sollte allerdings nicht ohne Kontext interpretiert werden. SMART-Attribute unterscheiden sich zwischen Herstellern und Laufwerkstypen.
Bei SSD und NVMe zählen andere Werte
Bei SSDs interessieren zusätzlich Verschleiß und verfügbare Reserve. Smartmontools 7.5 kann in der JSON-Ausgabe unter anderem Werte wie endurance_used und spare_available für unterstützte Geräte liefern.
Für Automatisierung ist JSON praktisch:
sudo smartctl -j -a /dev/nvme0
Damit können Monitoring-Skripte Werte verarbeiten, ohne die normale Textausgabe zerlegen zu müssen.
Kurzen Selbsttest starten
sudo smartctl -t short /dev/sda
Smartctl nennt anschließend normalerweise, wie lange der Test ungefähr dauert. Danach Ergebnis anzeigen:
sudo smartctl -l selftest /dev/sda
Langen Selbsttest durchführen
sudo smartctl -t long /dev/sda
Auch hier danach:
sudo smartctl -l selftest /dev/sda
Der lange Test kann je nach Größe des Laufwerks deutlich länger dauern. Er läuft normalerweise intern im Laufwerk; trotzdem starte ich so etwas auf einem Produktivserver lieber bewusst und nicht zufällig während einer ohnehin hohen Lastphase.
NVMe-Selbsttests
Aktuelle Smartmontools-Versionen unterstützen Selbsttests auch bei passenden NVMe-Geräten:
sudo smartctl -t short /dev/nvme0
sudo smartctl -l selftest /dev/nvme0
Nicht jedes Laufwerk unterstützt jede Funktion. Wenn Smartctl einen Test ablehnt, sollte man nicht mit irgendwelchen erzwungenen Optionen herumprobieren, sondern zuerst die Fähigkeiten des Geräts prüfen.
smartd für laufende Überwachung
Statt nur gelegentlich manuell hineinzusehen, kann smartd Laufwerke regelmäßig überwachen.
Status prüfen:
systemctl status smartmontools
Je nach Distribution heißt die Unit auch smartd. Die zentrale Konfiguration liegt normalerweise unter:
/etc/smartd.conf
Bevor ich Benachrichtigungen aktiviere, kontrolliere ich dort genau, welche Geräte automatisch erkannt werden und wohin Warnungen gehen.
SMART ersetzt kein Backup
Das ist mir wichtig: SMART ist Frühwarnung, keine Versicherung. Ein Laufwerk kann auch ohne lange Vorwarnung sterben.
Deshalb kombiniere ich Laufwerksüberwachung mit echten Backups. Dazu passen meine Artikel BorgBackup unter Debian/Ubuntu und Backup richtig planen.
Bei RAID jedes physische Laufwerk prüfen
Ein Software-RAID schützt vor dem Ausfall eines einzelnen Datenträgers, macht SMART aber nicht überflüssig. Im Gegenteil: Bei einem RAID möchte ich wissen, ob ein Mitglied bereits Fehler entwickelt, bevor noch ein zweites Laufwerk Probleme bekommt.
Darum prüfe ich RAID-Status und SMART-Werte getrennt.
Fazit
Smartmontools gehört für mich auf jeden Linux-Server mit lokalen Laufwerken. Ein gelegentliches smartctl -a, regelmäßige Selbsttests und eine funktionierende Backup-Strategie geben wesentlich mehr Sicherheit als erst dann auf die Platte zu schauen, wenn das System bereits I/O-Fehler meldet.
Quellen: Debian Manpages: smartctl 7.5 und Smartmontools 7.5 Release.
Gedanken dazu 0 Kommentare
Noch ist es ruhig hier. Dein Gedanke könnte der erste sein.
Was denkst du dazu?
Dein Kommentar erscheint nach der Freigabe.