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

Diese Anleitung behandelt Schnelldiagnose per smartctl, Dauerüberwachung mit smartd inklusive E-Mail-Alerts und ein Trend-Dashboard mit Scrutiny per Docker, auch für mehrere Server.

Voraussetzungen

1. Linux-Server mit Root-Zugriff (Ubuntu 22.04/24.04, Debian 12, Rocky Linux 9 oder Proxmox)
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 aktiviert: smartctl -i /dev/sda | grep 'SMART support'
5. Docker und Docker Compose (für Scrutiny)
6. Mailversand: mail (z. B. bsd-mailx) plus MTA oder msmtp-Relay
7. Für Hub/Spoke: TCP 8080 von den Collectors zum Hub, nur im LAN oder per VPN

Schritt 1: Welche SMART-Attribute wirklich zählen

Backblaze hat 2016 knapp 68.000 Laufwerke ausgewertet: 76,7 % der ausgefallenen HDDs hatten bei mindestens einem der fünf folgenden Attribute RAW > 0, laufende nur zu 4,2 %. 23,3 % der Ausfälle kamen ohne Warnung.

Wichtig: VALUE ist ein vom Controller normalisierter Score (1–253), THRESH der Hersteller-Mindestwert; bei VALUE <= THRESH gilt das Attribut als ausgefallen (FAILING_NOW). Aussagekräftiger ist RAW_VALUE, die gemessene Größe (Sektoren, Fehler, Temperatur).

Verifizieren: Fragen Sie die kritischen Attribute ab:

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

Gesundes Laufwerk: alle RAW_VALUE-Spalten 0. Andere Werte ordnen Sie mit der Tabelle ein.

Schritt 2: Schnelldiagnose mit smartctl

Überblick mit smartctl:

# 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

NVMe-Health-Log per nvme smart-log:

# 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

Manueller Kurztest (ca. 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

# Empfohlene Dauer des Langtests anzeigen ("Extended self-test routine recommended polling time")
smartctl -c /dev/sda | grep -A1 Extended

# Langtest starten
smartctl -t long /dev/sda

Achtung: smartctl -t long kehrt sofort zurück. Den Fortschritt zeigt smartctl -a /dev/sda unter „Self-test execution status“; bewerten Sie erst nach Ablauf der Restzeit.

Erster schwebender Sektor (SMART 197 = 1)? Vollständiges Backup erstellen und prüfen, dann Langtest. Ist danach SMART 198 > 0 oder bleibt 197 über 0, Laufwerk tauschen.

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 aus smartmontools überwacht Laufwerke dauerhaft, plant Tests und mailt bei Schwellwertüberschreitungen. Konfiguration: /etc/smartd.conf.

Original sichern (cp /etc/smartd.conf /etc/smartd.conf.orig) und durch diese Basis ersetzen:

# /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

Bei mehreren Laufwerken sind explizite Einträge besser. Wichtig: smartd ignoriert alle Zeilen nach DEVICESCAN; bei expliziten Einträgen DEVICESCAN weglassen:

# /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

Konfiguration prüfen und Dienst neu starten. Unter Debian/Ubuntu heißt er smartmontools (smartd ist nur Alias, systemctl enable smartd schlägt fehl), unter RHEL/Rocky smartd:

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

# Debian/Ubuntu
systemctl enable smartmontools && systemctl restart smartmontools
# RHEL/Rocky
systemctl enable --now smartd && systemctl restart smartd

Test-Mail: in der DEFAULT-Zeile vorübergehend -M test statt -M daily (Konfigurationsdirektive, keine Kommandozeilenoption), dann smartd -q onecheck, danach -M daily wiederherstellen.

E-Mail ohne vollständigen MTA: apt install bsd-mailx msmtp msmtp-mta und SMTP-Zugang in /etc/msmtprc (chmod 600). Alternativ führt -M exec /pfad/zum/skript ein Skript aus, etwa mit curl an ntfy, Gotify oder einen Webhook.

Verifizieren:

systemctl status smartmontools   # RHEL/Rocky: smartd

Erwartet: Active: active (running); journalctl -u smartmontools -n 30 (RHEL: -u smartd) zeigt Device: /dev/sda, opened und die geplanten Tests.

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

Scrutiny (aktuell v0.9.4) speichert SMART-Daten in InfluxDB, zeigt Trends und nutzt Backblaze-basierte Schwellwerte. Das Omnibus-Image bündelt Web-UI, Collector und Datenbank; ohne Anmeldung: Port 8080 nur im LAN oder per VPN.

Legen Sie 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
    devices:
      - /dev/sda
      - /dev/sdb
      - /dev/nvme0

devices an Ihre Laufwerke anpassen (lsblk -d). InfluxDB (Port 8086) wird bewusst nicht veröffentlicht.

Verzeichnisse anlegen, starten:

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

# Collector einmal sofort ausführen (sonst erst täglich um Mitternacht)
docker exec scrutiny /opt/scrutiny/bin/scrutiny-collector-metrics run

Dashboard: http://localhost:8080 (oder Server-IP). Laufwerke erkennt Scrutiny über das /run/udev-Volume; fehlt es, bleibt die Liste leer (dann Geräte 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, der manuelle Collector-Lauf endet ohne Fehler, und das Dashboard unter http://SERVER-IP:8080 zeigt Ihre Laufwerke.

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

Ein Hub betreibt Web-UI und InfluxDB; Collectors auf den übrigen Servern senden an die Hub-API.

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

services:
  influxdb:
    image: influxdb:2.8
    container_name: scrutiny-influxdb
    restart: unless-stopped
    # kein ports-Eintrag: InfluxDB ist nur im Compose-Netz erreichbar
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=admin
      - DOCKER_INFLUXDB_INIT_PASSWORD=SICHERES-PASSWORT
      - 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
      - COLLECTOR_RUN_STARTUP=true           # erster Lauf direkt beim Start
    devices:
      - /dev/sda
      - /dev/sdb
      - /dev/nvme0

Setzen Sie für DEIN-GEHEIMER-TOKEN und SICHERES-PASSWORT Zufallswerte ein (z. B. openssl rand -hex 32), für HUB-IP-ODER-HOSTNAME den Hub. Der Token muss in beiden Diensten der Hub-Datei gleich sein; der Collector braucht keinen. Start: docker compose -f /opt/scrutiny/docker-compose.hub.yml up -d, Spoke entsprechend.

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

Das Collector-Log zeigt keine Verbindungsfehler zur COLLECTOR_API_ENDPOINT-Adresse, und im Hub-Dashboard unter http://HUB-IP:8080 erscheinen nach dem ersten Lauf die Laufwerke des Remote-Servers. Ein connection refused deutet auf eine Firewall oder falsche Hub-Adresse.

Troubleshooting / Typische Fehler

1. smartd sendet keine E-Mails: mail oder MTA fehlt (Schritt 3).
2. DEVICESCAN findet keine Laufwerke hinter RAID-Controllern (LSI MegaRAID, HP Smart Array): smartctl -d megaraid,0 /dev/sda oder -d 3ware,0; die Typen explizit in smartd.conf eintragen.
3. Scrutiny-Dashboard leer: Collector läuft standardmäßig nur um Mitternacht, oder /run/udev/devices fehlt; manuell starten (Schritt 4).
4. NVMe im Container „permission denied“: zusätzlich zu SYS_RAWIO cap_add: [SYS_ADMIN]. privileged: true geht auch, gibt aber vollen Hostzugriff.
5. SMART 197 sinkt nach Langtest nicht: Lesen findet schwebende Sektoren nur, neu zugeordnet werden sie erst beim Schreiben; Laufwerk nach Backup tauschen.
6. Scrutiny bricht mit unauthorized ab: InfluxDB-Verzeichnis war nicht persistent. Volume für /opt/scrutiny/influxdb (Omnibus) bzw. /var/lib/influxdb2 (Hub) prüfen, web.influxdb.token in /opt/scrutiny/config/scrutiny.yaml löschen und neu starten; die Historie ist dabei meist verloren.
7. smartd ignoriert Gerätepfade: Sie stehen nach DEVICESCAN (Schritt 3).
8. Wear Leveling Count (SMART 177) falsch gelesen: maßgeblich ist VALUE gegenüber THRESH (Tabelle).

Häufige Fragen

Ab wann muss ich ein Laufwerk sofort ersetzen?

Bei SMART 198 > 0, steigendem 187, nach Langtest erhöhtem 197 oder steigendem SMART 5 (siehe Tabelle): Backup prüfen, Ersatz bestellen, Daten migrieren.

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

Siehe Schritt 1: VALUE ist normalisiert (Ausfall bei VALUE <= THRESH), RAW_VALUE die Messgröße.

Kann Scrutiny HDD, SSD und NVMe gleichzeitig überwachen?

Ja; NVMe braucht zusätzlich SYS_ADMIN (Troubleshooting).

DEVICESCAN oder explizite Einträge – was ist besser?

DEVICESCAN genügt für Einzelsysteme; explizite Einträge (Schritt 3) erlauben Ausschlüsse (-d ignore), neue Laufwerke tragen Sie dann selbst ein.

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

smartctl -c zeigt die Dauer („Extended self-test routine recommended polling time“): bei HDDs grob 1 bis 2 Stunden pro TB, bei SSDs meist unter 30 Minuten. Der Server bleibt nutzbar; planen Sie Langtests in ruhige Zeiten (z. B. -s L/../../6/03).

Wie unterscheidet sich Scrutiny von einem reinen smartd-Setup?

Scrutiny ergänzt Trends, Backblaze-Bewertung, Benachrichtigungen per SCRUTINY_NOTIFY_URLS und Multi-Server-Übersicht. Für einen Einzelserver reicht smartd.

Fazit

SMART-Monitoring verschafft in drei von vier Fällen Zeit für einen geplanten Tausch, ersetzt aber kein Backup. Ergänzen Sie es durch eine 3-2-1-Backup-Strategie und Wiederherstellungstests; für neue Hardware eignet sich der Hardware-Stresstest mit stress-ng.

Weiterführende Anleitungen und Quellen

1. 3-2-1-Backup-Strategie praktisch umsetzen
2. Restic Backup automatisieren mit Cron
3. Hardware-Stresstest mit Linux, stress-ng und smartctl
4. NAS dimensionieren und RAID-Level wählen

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.