drive-alert

Überwacht alle Festplatten und SSDs eines Servers und schickt eine Gotify-Nachricht, sobald eine Platte Probleme macht — bevor Daten verloren gehen. Ein Befehl installiert und konfiguriert alles, danach läuft es unbeaufsichtigt.

Technisch ist es ein Aufsatz auf smartd aus den smartmontools: der prüft die SMART-Werte, bei einem Fund ruft er drive-alert auf, das daraus eine verständliche Nachricht baut und sie an Gotify schickt. Solange das Problem besteht, erinnert es alle 8 Stunden daran.

Installation

curl -fsSL https://git.pablo1732.de/server/drive-alert/raw/branch/main/install.sh | sh

Gefragt wird nur nach Gotify-URL und App-Token. Der Installer richtet alles ein, schickt eine Testnachricht und prüft zum Schluss die komplette Installation durch.

Ohne Rückfragen, z. B. für mehrere Server:

curl -fsSL https://git.pablo1732.de/server/drive-alert/raw/branch/main/install.sh \
  | sh -s -- --url https://gotify.example.de --token DEIN_TOKEN --yes

Aktualisieren: denselben Befehl noch einmal ausführen. Eine vorhandene Installation wird erkannt, Gotify-Zugang und Einstellungen werden übernommen, Altes wird ersetzt. Das gilt auch für die Vorgängerversion gotify-drive-alert — deren Dateien werden erst entfernt, wenn die neue Installation steht und die Testnachricht angekommen ist.

Voraussetzungen

• Linux mit systemd oder OpenRC; Paketverwaltung apt, dnf, yum, pacman, zypper oder apk
• root-Rechte, curl
• Direkter Zugriff auf die Platten. In einem LXC- oder Docker-Container gibt es keine SMART-Werte — drive-alert gehört auf den Host (bei Proxmox also auf den Proxmox-Host).
• Ein erreichbarer Gotify-Server und ein App-Token daraus (Gotify → Apps → Create Application)

Befehle

Befehl	Zweck
drive-alert status	Alarmlage und Zustand aller Platten inkl. Temperatur
drive-alert test	Testnachricht an Gotify schicken
drive-alert test --e2e	Vollständiger Test: smartd löst über die echte Konfiguration aus
drive-alert selfcheck	Installation prüfen, Exit-Code 1 bei Fehlern
drive-alert ack	Laufenden Alarm quittieren, Erinnerungen beenden
drive-alert diag	Diagnose-Block für die Fehlersuche (enthält kein Token)
drive-alert uninstall	Entfernen; --purge löscht auch Konfiguration und Verlauf

Wie ein Alarm abläuft

1. smartd findet ein Problem und ruft drive-alert auf.
2. Sofort eine Gotify-Nachricht mit hoher Priorität: welche Platte, was los ist, wie man quittiert.
3. Alle 8 Stunden eine Erinnerung, solange das Problem besteht.
4. Ende des Alarms — auf zwei Wegen:
   • drive-alert ack quittiert von Hand. Bei echtem Plattenschaden wird vorher nachgefragt.
   • Von selbst, aber nur bei harmlosen Ursachen (Temperatur, Testmeldung) und nur wenn alle Platten wieder in Ordnung sind. Dann kommt eine Entwarnung mit niedriger Priorität.

Alarme, die auf sterbende Hardware hindeuten (defekte Sektoren, fehlgeschlagene Gesundheitsprüfung, Selbsttestfehler), lösen sich nie von selbst auf — auch dann nicht, wenn smartctl -H wieder PASSED meldet. Genau das ist bei wachsenden Pending Sectors nämlich der Fall, und eine automatische Entwarnung wäre dort eine Lüge.

Mehrfach derselbe Fehler auf derselben Platte (etwa weil smartd nach einem Reboot neu startet) erzeugt keine neue Sofortnachricht — dafür ist die Erinnerung da.

Konfiguration

/etc/drive-alert/config, nur für root lesbar (enthält das Token). Nach Änderungen: systemctl restart smartd bzw. smartmontools.

GOTIFY_URL="https://gotify.example.de"
GOTIFY_TOKEN="…"

# Optionale Zeile vor jeder Warnung. Leer = aus.
GOTIFY_NOTE=""

PRIORITY=8          # Gotify-Priorität für Warnungen
INFO_PRIORITY=3     # für Entwarnungen und Tests
REPEAT_HOURS=8      # Abstand der Erinnerungen
TEMP_CRIT=70        # Warnung ab dieser Plattentemperatur (°C)
HOST_LABEL=""       # Name in den Nachrichten, leer = Hostname

Prüfplan von smartd (in /etc/smartd.conf, im Block >>> drive-alert >>>):

• Kurztest sonntags 02:00, Langtest am 1. des Monats 03:00
• schlafende Platten werden nicht geweckt (nach 10 übersprungenen Durchläufen doch geprüft)
• Warnung ab TEMP_CRIT Grad

Eigene Gerätezeilen gehören außerhalb dieses Blocks — er wird bei jeder Neuinstallation ersetzt.

Dateien

Pfad	Inhalt
/usr/local/bin/drive-alert	das Programm
/etc/drive-alert/config	Konfiguration mit Token (Rechte 600)
/etc/smartd.conf bzw. /etc/smartmontools/smartd.conf	Prüfplan, Block >>> drive-alert >>>
/var/lib/drive-alert/alarm_active	läuft gerade ein Alarm? Enthält den Verlauf
/var/lib/drive-alert/quittiert-*.log	archivierte Alarme

Fehlersuche

Erste Anlaufstelle: drive-alert selfcheck. Wenn das nicht reicht, liefert drive-alert diag einen Block mit allem Nötigen (System, smartd-Konfiguration, Dienstzustand, Logauszug) — ohne das Token. Den kann man so wie er ist weitergeben.

„keine Platten erkannt" — häufigster Fall bei Hardware-RAID-Controllern, die die einzelnen Platten verstecken. smartctl --scan zeigt, ob überhaupt etwas gefunden wird. Falls nicht, die Platten von Hand in smartd.conf eintragen, z. B.:

/dev/bus/0 -d megaraid,0 -a -m <nomailer> -M exec /usr/local/lib/drive-alert/smartd-hook

Ohne erkannte Platten startet smartd grundsätzlich nicht — das ist kein Fehler von drive-alert, sondern Verhalten der smartmontools.

Keine Nachricht bekommen? drive-alert test prüft den Weg zu Gotify, drive-alert test --e2e die ganze Kette inklusive smartd.

Was test --e2e abdeckt

Der Test läuft gegen eine Kopie der echten smartd.conf — nur der Hook ist durch den Test-Hook ersetzt und -M test ergänzt. Geprüft wird damit: smartd erkennt die Platten, die installierte Konfigurationszeile löst den Hook aus, die Variablen kommen an, und die Nachricht landet in Gotify. Der laufende Dienst wird dabei nicht angefasst.

Nicht abgedeckt, weil nicht erzwingbar:

• Ausgelöst wird eine Testmeldung, kein echter Sektorfehler — die Klartext-Übersetzung der echten Fehlertypen ist über die Testsuite abgedeckt, nicht über diesen Lauf.
• Der Prüfplan (Kurztest sonntags, Langtest monatlich) wird auf Syntax geprüft, nicht abgewartet.
• Erinnerung nach REPEAT_HOURS und das automatische Auflösen laufen über den Timer.
• Ob der Dienst nach einem Reboot hochkommt: selfcheck prüft, dass er dafür eingerichtet ist.

Löst die echte Konfiguration nicht aus, macht der Test eine Gegenprobe mit einer minimalen Zeile und sagt dann, ob es an der Konfiguration oder am Hook liegt. Häufigster harmloser Grund: die Platten schlafen gerade (-n standby).

Grenzen

• Überwacht wird, was smartctl --scan findet. Platten hinter RAID-Controllern brauchen einen Eintrag von Hand.
• Die Erinnerungen laufen über einen systemd-Timer bzw. cron alle 15 Minuten; gesendet wird frühestens nach REPEAT_HOURS.
• Kommt ein Push nicht durch, bleibt der Alarm gespeichert und wird beim nächsten Lauf erneut versucht — der Fehler geht also nicht verloren.

Tests

tests/run-tests.sh prüft die Alarmlogik gegen einen simulierten Gotify-Server und ein simuliertes smartctl — ohne echte Platten und ohne echten Gotify-Server. tests/docker-matrix.sh führt den Installer in Containern verschiedener Distributionen aus.