Festplatten-Ausfall vorhersagen: SMART-Monitoring mit smartd und Scrutiny

Ein Backup zu haben ist gut – eine echte Vorwarnung, bevor eine Festplatte ausfällt, ist besser. SMART (Self-Monitoring, Analysis and Reporting Technology) ist in nahezu jede moderne HDD, SSD und NVMe-Laufwerk eingebaut, aber die meisten Admins lesen die Rohwerte mit smartctl -a und wissen nicht, welche der Dutzenden Attribute tatsächlich einen bevorstehenden Ausfall ankündigen. Diese Anleitung zeigt dir drei Ebenen: schnelle Diagnose per smartctl, automatische Dauerbewachung mit dem smartd-Daemon inklusive E-Mail-Alerts, und ein historisches Trend-Dashboard mit Scrutiny per Docker – das auch mehrere Server in einer Übersicht zusammenführt.

Voraussetzungen

1. Linux-Server mit Root-Zugriff (Ubuntu 22.04/24.04, Debian 12, Rocky Linux 9 oder Proxmox empfohlen)
2. smartmontools installiert: apt install smartmontools (Debian/Ubuntu) oder dnf install smartmontools (RHEL/Rocky)
3. nvme-cli für NVMe-Laufwerke: apt install nvme-cli
4. SMART auf den Laufwerken aktiviert – prüfen mit: smartctl -i /dev/sda | grep 'SMART support'
5. Docker und Docker Compose installiert (für Scrutiny-Web-Dashboard)
6. Funktionierender MTA für E-Mail-Alerts (msmtp-Relay oder Postfix) mit SMTP-Zugang
7. Für Hub/Spoke: Netzwerkzugang zwischen Collector-Servern und Hub-Server (Port 8080)

Schritt 1: Welche SMART-Attribute wirklich zählen

Bevor du ein Monitoring einrichtest, musst du verstehen, welche der 50+ SMART-Attribute tatsächlich aussagekräftig sind. Backblaze hat über 40.000 Laufwerke analysiert und festgestellt: 76,7 % aller ausgefallenen HDDs hatten erhöhte Werte bei mindestens einem der folgenden fünf Attribute – aber nur 4,2 % der laufenden Laufwerke zeigten dasselbe.

Wichtig: Der Unterschied zwischen VALUE und RAW_VALUE ist entscheidend. VALUE ist ein normalisierter Score (1–253), den der Laufwerk-Controller selbst berechnet; THRESH ist der Hersteller-Mindestschwellwert. Wenn VALUE <= THRESH, gilt das Attribut als „gefailt". RAW_VALUE ist die tatsächlich gemessene Größe (Sektorzahl, Fehlerzähler, Temperatur) – dieser Wert ist für die Realbeurteilung wichtiger. Backblaze fokussiert auf RAW_VALUE > 0 als Warnsignal.

Verifizieren: Du kannst die kritischen Attribute sofort abfragen:

smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Command_Timeout"

Erwartetes Ergebnis bei einem gesunden Laufwerk: alle RAW_VALUE-Spalten zeigen 0. Jede andere Zahl erfordert die oben stehende Tabelle zur Einordnung.

Schritt 2: Schnelldiagnose mit smartctl

Bevor du den Daemon konfigurierst, verschaffe dir mit smartctl einen schnellen Überblick. Das folgende Vorgehen liefert in weniger als fünf Minuten eine erste Beurteilung.

# Laufwerksinformationen: Modell, Firmware, Kapazität
smartctl -i /dev/sda

# Gesamtstatus: PASSED oder FAILED
smartctl -H /dev/sda

# Alle SMART-Attribute mit normalisierten Werten und Rohwerten
smartctl -A /dev/sda

# ATA Error Log – letzte fünf aufgetretene Fehler
smartctl -l error /dev/sda

# Selftest-Historie – vergangene Tests und Ergebnisse
smartctl -l selftest /dev/sda

# Alles auf einmal (kombiniert -H -i -c -A -l error -l selftest)
smartctl -a /dev/sda

Für NVMe-Laufwerke liefert nvme smart-log den Health-Log mit den relevanten Feldern:

# NVMe Health Log (nvme-cli erforderlich)
nvme smart-log /dev/nvme0

# Kritische Felder im Output:
#   critical_warning          : 0x00  (0 = alles OK)
#   available_spare           : 100%  (unter Schwelle = Warnung)
#   available_spare_threshold : 10%   (Herstellerwert)
#   percentage_used           : 5%    (> 90% = nahes Lebensende)
#   media_errors              : 0     (> 0 steigend = kritisch)

# Alternativ über smartctl (wenn nvme-cli nicht installiert):
smartctl -a /dev/nvme0

Einen manuellen Kurztest startest du so – er dauert etwa zwei Minuten:

# Kurztest starten
smartctl -t short /dev/sda

# Test läuft im Hintergrund – nach ~130 Sekunden Ergebnis prüfen
sleep 130
smartctl -l selftest /dev/sda

# Langtest (bei 4 TB ca. 6–10 Stunden):
smartctl -t long /dev/sda

Achtung: smartctl -t long blockiert nicht – der Befehl kehrt sofort zurück. Den Fortschritt prüfst du mit smartctl -a /dev/sda im Feld „Self-test execution status". Warte die angezeigte Restzeit ab, bevor du das Ergebnis bewertest.

Was tun bei erstem schwebenden Sektor (SMART 197 = 1)? Sofortmaßnahme: Backup prüfen und vollständiges Backup aller wichtigen Daten erstellen. Danach einen Langtest starten. Wenn nach dem Langtest SMART 198 > 0 ist oder SMART 197 nicht auf 0 sinkt, gilt das Laufwerk als defekt und muss ersetzt werden.

Verifizieren: smartctl -H /dev/sda muss mit SMART overall-health self-assessment test result: PASSED antworten. Ein FAILED oder eine Ausgabe mit Warnungen signalisiert unmittelbaren Handlungsbedarf.

Schritt 3: smartd konfigurieren – automatische Tests und Alerts

smartd ist der Hintergrunddienst aus dem Paket smartmontools, der Laufwerke kontinuierlich überwacht, automatische Tests nach Zeitplan ausführt und bei Schwellwertüberschreitungen E-Mails sendet. Die Konfiguration erfolgt in /etc/smartd.conf.

Öffne die Datei mit einem Editor und ersetze den Inhalt durch folgende Basis-Konfiguration:

# /etc/smartd.conf – Empfohlene Basis-Konfiguration
# Alle Laufwerke überwachen, E-Mail bei Problemen, Testzeitplan

DEFAULT -H -l error -l selftest -f -C 197 -U 198 \
  -W 2,40,50 \
  -m admin@example.com \
  -M daily

DEVICESCAN -s (S/../.././02|L/../../6/03)

# Erklärung der wichtigsten Flags:
# -H           = SMART Health Status prüfen (PASSED/FAILED)
# -l error     = ATA Error Log auf Zuwachs prüfen
# -l selftest  = fehlgeschlagene Selftests melden
# -f           = Fehlgeschlagene Usage-Attribute melden
# -C 197       = Alarm wenn Pending Sectors > 0 (SMART 197)
# -U 198       = Alarm wenn Offline Uncorrectable > 0 (SMART 198)
# -W 2,40,50   = Temperatur: 2 Grad Änderung loggen, ab 40 Grad Info,
#                ab 50 Grad kritischer Alarm
# -m           = E-Mail-Empfänger
# -M daily     = Täglich erinnern solange Problem besteht
# Zeitplan: Kurztest täglich 02–03 Uhr, Langtest samstags 03–04 Uhr

Für Produktionssysteme mit mehreren Laufwerken empfehlen sich explizite Einträge statt DEVICESCAN, damit du pro Laufwerk unterschiedliche Zeitfenster und Optionen setzen kannst. Wichtig: DEVICESCAN muss das letzte nicht-kommentierte Element der Datei sein – alle Gerätepfade danach werden stillschweigend ignoriert. Wenn du explizite Einträge nutzt, verzichte auf DEVICESCAN:

# /etc/smartd.conf – Explizite Laufwerks-Einträge (Alternative zu DEVICESCAN)

DEFAULT -H -l error -l selftest -f -C 197 -U 198 \
  -W 2,40,50 \
  -m admin@example.com \
  -M daily

/dev/sda -a -s S/../.././02
/dev/sdb -a -s L/../../6/03
# NVMe: kein -C 197 / -U 198 (HDD-spezifisch), -H überwacht critical_warning
/dev/nvme0 -a -s S/../.././02

Anschließend den Dienst aktivieren und starten:

# Dienst aktivieren und sofort starten
systemctl enable --now smartd

# Konfiguration prüfen (ohne Daemon-Start – zeigt geplante Tests):
smartd -c /etc/smartd.conf -q showtests

# Optionale Test-Mail senden (prüft, ob der MTA funktioniert):
smartd -c /etc/smartd.conf -M test

E-Mail-Alerts ohne vollständigen MTA: Wenn kein Postfix oder Exim installiert ist, nutze msmtp als leichtgewichtigen SMTP-Relay: apt install msmtp msmtp-mta und konfiguriere /etc/msmtprc mit deinen SMTP-Zugangsdaten. Alternativ bietet die Option -M exec /pfad/zum/skript die Möglichkeit, statt einer E-Mail ein Shell-Skript mit curl-Aufruf an ntfy, Gotify oder einen Webhook auszuführen.

Verifizieren:

systemctl status smartd

Erwartetes Ergebnis: Active: active (running). Im Journal (journalctl -u smartd -n 30) solltest du Einträge wie Device: /dev/sda, opened und die geplanten Testzeiten sehen. Bei fehlerhafter Konfiguration bricht smartd mit einer Fehlermeldung ab, ohne sich zu starten.

Schritt 4: Scrutiny als Docker-Dashboard einrichten (All-in-one)

Scrutiny v0.9.2 ist ein Go-basiertes Web-Dashboard, das SMART-Daten historisch in InfluxDB speichert, Trendkurven visualisiert und Backblaze-basierte Schwellwerte als Bewertungsgrundlage nutzt. Die einfachste Variante ist das Omnibus-Image, das Web-UI und Datenbankbackend in einem Container zusammenfasst.

Lege eine Compose-Datei an:

# /opt/scrutiny/docker-compose.yml – All-in-one (Omnibus)
services:
  scrutiny:
    image: ghcr.io/analogj/scrutiny:latest-omnibus
    container_name: scrutiny
    restart: unless-stopped
    cap_add:
      - SYS_RAWIO
      - SYS_ADMIN    # Zusätzlich für NVMe-Laufwerke
    volumes:
      - /run/udev:/run/udev:ro
      - /opt/scrutiny/config:/opt/scrutiny/config
      - /opt/scrutiny/influxdb:/opt/scrutiny/influxdb
    ports:
      - 8080:8080
      - 8086:8086
    devices:
      - /dev/sda
      - /dev/sdb
      - /dev/nvme0

Verzeichnisse anlegen und Container starten:

mkdir -p /opt/scrutiny/config /opt/scrutiny/influxdb
docker compose -f /opt/scrutiny/docker-compose.yml up -d

Das Dashboard ist danach unter http://localhost:8080 (oder Server-IP) erreichbar. Scrutiny erkennt die Laufwerke automatisch über das /run/udev-Volume. Ohne dieses Volume erscheint im Log eine leere Geräterliste – dann entweder das Volume hinzufügen oder Geräte manuell in /opt/scrutiny/config/collector.yaml eintragen.

Verifizieren:

docker compose -f /opt/scrutiny/docker-compose.yml ps
docker logs scrutiny --tail 20

Erwartetes Ergebnis: Container-Status Up, im Log Einträge wie Scanning device: /dev/sda. Im Browser unter Port 8080 sollte das Scrutiny-Dashboard mit deinen Laufwerken erscheinen.

Schritt 5: Scrutiny Hub-and-Spoke für mehrere Server

Wenn du mehrere Server überwachen möchtest, nutzt du das Hub-and-Spoke-Modell: Ein zentraler Hub-Server betreibt Web-UI und InfluxDB-Datenbank, jeder Remote-Server läuft einen Collector-Container, der Daten an die Hub-API sendet.

Hub-Server (/opt/scrutiny/docker-compose.hub.yml):

services:
  influxdb:
    image: influxdb:2.8
    container_name: scrutiny-influxdb
    restart: unless-stopped
    ports:
      - 8086:8086
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=admin
      - DOCKER_INFLUXDB_INIT_PASSWORD=AdminPasswort123
      - DOCKER_INFLUXDB_INIT_ORG=homelab
      - DOCKER_INFLUXDB_INIT_BUCKET=scrutiny
      - DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=DEIN-GEHEIMER-TOKEN
    volumes:
      - scrutiny-influxdb:/var/lib/influxdb2

  scrutiny-web:
    image: ghcr.io/analogj/scrutiny:latest-web
    container_name: scrutiny-web
    restart: unless-stopped
    ports:
      - 8080:8080
    environment:
      - SCRUTINY_WEB_INFLUXDB_HOST=influxdb
      - SCRUTINY_WEB_INFLUXDB_PORT=8086
      - SCRUTINY_WEB_INFLUXDB_TOKEN=DEIN-GEHEIMER-TOKEN
      - SCRUTINY_WEB_INFLUXDB_ORG=homelab
      - SCRUTINY_WEB_INFLUXDB_BUCKET=scrutiny
    depends_on:
      - influxdb
    volumes:
      - /opt/scrutiny/config:/opt/scrutiny/config

volumes:
  scrutiny-influxdb:

Spoke/Collector auf jedem Remote-Server (/opt/scrutiny/docker-compose.spoke.yml):

services:
  scrutiny-collector:
    image: ghcr.io/analogj/scrutiny:latest-collector
    container_name: scrutiny-collector
    restart: unless-stopped
    cap_add:
      - SYS_RAWIO
      - SYS_ADMIN    # Für NVMe-Laufwerke
    volumes:
      - /run/udev:/run/udev:ro
    environment:
      - COLLECTOR_API_ENDPOINT=http://HUB-IP-ODER-HOSTNAME:8080
      - COLLECTOR_CRON_SCHEDULE=0 */6 * * *   # alle 6 Stunden
    devices:
      - /dev/sda
      - /dev/sdb
      - /dev/nvme0

Ersetze DEIN-GEHEIMER-TOKEN durch einen sicheren, zufällig generierten String (z. B. openssl rand -hex 32) und HUB-IP-ODER-HOSTNAME durch die tatsächliche IP oder den Hostnamen des Hub-Servers. Den Token musst du in Hub und Spoke identisch setzen.

Verifizieren:

# Auf dem Hub-Server:
docker compose -f /opt/scrutiny/docker-compose.hub.yml ps

# Auf dem Spoke-Server:
docker logs scrutiny-collector --tail 20

Im Collector-Log sollten Einträge wie Sending data to hub: http://HUB-IP:8080 erscheinen. Im Hub-Dashboard unter http://HUB-IP:8080 sollten nach dem ersten Collector-Lauf alle Remote-Server und ihre Laufwerke sichtbar sein.

Troubleshooting / Typische Fehler

1. smartd sendet keine E-Mails: smartd nutzt ausschließlich einen lokalen MTA. Ohne installierten Postfix, Exim oder msmtp-Relay kommen keine Mails an. Lösung: apt install msmtp msmtp-mta und /etc/msmtprc konfigurieren, oder -M exec /pfad/zum/skript mit curl für Webhook-Benachrichtigung (ntfy, Gotify) nutzen. Test mit smartd -c /etc/smartd.conf -M test.
2. DEVICESCAN erkennt keine Laufwerke hinter RAID-Controllern: Hinter Hardware-RAID (LSI MegaRAID, HP Smart Array) sind Laufwerke nicht direkt als /dev/sdX ansprechbar. Lösung: smartctl -d megaraid,0 /dev/sda oder -d 3ware,0. Die Typen müssen explizit in smartd.conf eingetragen werden, DEVICESCAN reicht nicht.
3. Scrutiny Collector sieht keine Laufwerke: Ohne das Volume /run/udev:/run/udev:ro kann der Collector die Laufwerksliste nicht automatisch ermitteln. Fehler erscheint im Log als leere Geräteliste. Lösung: Volume hinzufügen oder Geräte manuell in /opt/scrutiny/config/collector.yaml eintragen.
4. NVMe-Zugriff im Container scheitert mit „permission denied": SYS_RAWIO allein reicht für NVMe nicht aus. NVMe benötigt zusätzlich cap_add: [SYS_ADMIN]. Alternativ kann privileged: true genutzt werden, ist aber aus Security-Gründen nicht für Produktionsumgebungen empfohlen.
5. SMART 197 sinkt nicht auf 0 nach Langtest: Pending Sectors verschwinden nicht automatisch. Der betroffene Sektor muss vom Betriebssystem gelesen werden, damit das Laufwerk einen Neuzuordnungsversuch startet. Ein Langtest oder badblocks-Scan kann den Prozess auslösen. Bleibt SMART 197 nach dem Langtest erhöht, Laufwerk als defekt betrachten.
6. Scrutiny zeigt „unauthorized" nach Neuinstallation: InfluxDB 2.x setzt den Admin-Token bei Neuinstallation zurück. Lösung: Token in der InfluxDB-UI (/orgs → API Tokens) neu generieren und in der Scrutiny-Web-Umgebungsvariable SCRUTINY_WEB_INFLUXDB_TOKEN aktualisieren.
7. smartd ignoriert Gerätepfade nach DEVICESCAN: DEVICESCAN muss das letzte nicht-kommentierte Element der Datei sein. Alle Gerätepfade darunter werden stillschweigend ignoriert. Lösung: Explizite Einträge vor DEVICESCAN platzieren oder ganz auf explizite Einträge ohne DEVICESCAN setzen.
8. Falsche Interpretation von Wear Leveling Count (SMART 177): Ein hoher RAW_VALUE (z. B. 2000) bei SMART 177 ist gut, nicht schlecht – er bedeutet, dass der Wear-Leveling-Algorithmus oft und erfolgreich ausgeführt wurde. Gefährlich ist ein sinkender normalisierter VALUE unter den THRESH-Wert.

Häufige Fragen

Ab wann muss ich ein Laufwerk sofort ersetzen?

Sofortiger Ersatz ist nötig, wenn: SMART 198 (Offline Uncorrectable) > 0 ist, oder SMART 187 (Reported Uncorrectable Errors) > 0 steigt, oder SMART 197 (Pending Sectors) nach einem Langtest nicht auf 0 sinkt. SMART 5 (Reallocated Sectors) mit einem stabilen Wert unter 5 kann noch beobachtet werden, aber ein Aufwärtstrend ist das Austauschsignal. Niemals auf den vollständigen Ausfall warten: Bei erstem ernstem Anzeichen das Backup prüfen, Ersatzlaufwerk bestellen und Daten migrieren.

Was ist der Unterschied zwischen VALUE und RAW_VALUE in smartctl -A?

VALUE ist ein normalisierter Score von 1–253, den der Laufwerk-Controller selbst berechnet. THRESH ist der vom Hersteller festgelegte Mindestschwellwert – wenn VALUE <= THRESH gilt das Attribut als offiziell „gefailt". RAW_VALUE ist die tatsächlich gemessene Größe (Sektorzahl, Fehlerzähler, Temperatur in Celsius) und für die Realbeurteilung wichtiger. Backblaze fokussiert explizit auf RAW_VALUE > 0 als Warnsignal, unabhängig von VALUE und THRESH.

Kann Scrutiny HDD, SSD und NVMe gleichzeitig überwachen?

Ja. Scrutiny v0.9.2 unterstützt alle drei Typen. NVMe benötigt die Docker-Capability SYS_ADMIN zusätzlich zu SYS_RAWIO. Scrutiny nutzt intern smartctl und nvme-cli und zeigt laufwerkstypspezifische Attribute im Dashboard an. Die integrierte Attribut-Datenbank löst auch herstellerspezifische SSD-Attribute auf, die smartctl als „Unknown_SSD_Attribute" ausgibt.

DEVICESCAN oder explizite Einträge – was ist besser?

DEVICESCAN ist praktisch für Heim- und Testumgebungen. Für Produktionssysteme sind explizite Einträge besser: Du kannst pro Laufwerk unterschiedliche Testzeitpläne setzen (z. B. verschiedene Zeitfenster für Laufwerke unter Last), bestimmte Laufwerke gezielt ignorieren (-d ignore), und es gibt keine Überraschungen, wenn neue Laufwerke hinzugefügt werden.

Wie lange dauert ein SMART-Langtest und kann ich den Server dabei normal nutzen?

Die Testdauer hängt von der Laufwerkskapazität ab: etwa eine Stunde pro TB bei HDDs (4 TB = ca. 4–8 Stunden, je nach Hersteller). SSDs und NVMe sind meist in unter 30 Minuten fertig. Der Test läuft mit niedriger Priorität in der Laufwerk-Firmware; normale I/O-Operationen sind möglich, können den Test aber verlangsamen oder selten unterbrechen. Empfehlung: Langtests auf Zeiten mit geringer Last legen (z. B. Samstagnacht 03:00 Uhr via -s L/../../6/03).

Wie unterscheidet sich Scrutiny von einem reinen smartd-Setup?

smartd kann E-Mail-Alerts senden und Tests planen, speichert aber keine Historie und bietet keine Visualisierung. Scrutiny ergänzt das um historische Trendkurven, ein Web-Dashboard, normalisierte Bewertung anhand Backblaze-Echtdaten, Webhook-Alerts an Slack/Discord/Teams, und Multi-Server-Übersicht per Hub-and-Spoke. Für einfache Einzelserver-Setups reicht smartd, für mehrere Server oder Langzeittrend-Analyse ist Scrutiny die bessere Wahl.

Fazit

SMART-Monitoring ist keine Garantie gegen Datenverlust – aber es ist der Unterschied zwischen kontrolliertem Laufwerkstausch mit Zeit für ein Backup und unerwarteter Downtime. Die Backblaze-Forschung zeigt klar, welche fünf Attribute wirklich zählen. Mit smartd hast du einen schlanken, systemintegrierten Daemon, der automatische Tests plant und sofort alarmiert. Scrutiny schichtet darüber ein historisches Dashboard mit Trendanzeige – besonders wertvoll, wenn du mehrere Server mit dem Hub-and-Spoke-Modell zusammenführst. Ergänze dieses Monitoring durch eine solide Backup-Strategie (z. B. nach dem 3-2-1-Prinzip) und automatisierte Wiederherstellungstests – denn SMART warnt vor Ausfall, ersetzt aber kein Backup. Wer zudem physische Ausfälle durch Hardwarestress ergänzend testen möchte, findet im Artikel zum Hardware-Stresstest mit stress-ng eine sinnvolle Ergänzung.

Weiterführende Anleitungen und Quellen

1. 3-2-1-Backup-Strategie praktisch umsetzen – Backup-Konzept, das Festplattenmonitoring sinnvoll ergänzt
2. Restic Backup automatisieren mit Cron – Automatische Datensicherung unter Linux und Windows
3. Hardware-Stresstest mit Linux, stress-ng und smartctl – Ergänzende Belastungstests für CPU, RAM und Laufwerke
4. NAS dimensionieren und RAID-Level wählen – Planung von Speichersystemen mit RAID-Redundanz

Quellen: Backblaze: What SMART Stats Tell Us About Hard Drives (Originalstudie); Backblaze SMART Stats and Failure Rates Documentation; smartd.conf(5) Man-Page; Scrutiny GitHub Repository (INSTALL_HUB_SPOKE.md); ArchWiki: S.M.A.R.T.