ZFS-Scrubs und SMART-Tests planen – und alarmiert werden, wenn sie fehlschlagen

Mein NAS war gesund, solange ich es besitze. Das weiß ich, weil ich noch keinen Fehler gesehen habe. Das ist aber nicht dasselbe, wie dass der Pool geprüft wurde. Lange war mein Monitoring-Plan für ZFS „Ich merke es schon“, und ich habe nur dann etwas bemerkt, wenn ich zufällig aus einem anderen Grund zpool status ausgeführt habe.

Dieser Beitrag behandelt die drei Ebenen, die ich gerade aufsetze: geplante Scrubs, geplante SMART-Tests und einen Alarmweg, der nicht davon abhängt, dass ich daran denke, nachzusehen. Ich betreibe das Ganze noch kein volles Jahr, also versteht es als funktionierendes Setup. Wo ich mir unsicher bin, weise ich darauf hin.

Was jede Prüfung tatsächlich erkennt

Sie überschneiden sich, sind aber nicht dasselbe.

• Ein Scrub liest jeden Block im Pool und verifiziert ihn anhand seiner Prüfsumme. Bei Redundanz (Mirror, RAIDZ) repariert ZFS, was es kann, aus der intakten Kopie. Er findet stille Datenkorruption in Daten, die seit Monaten niemand gelesen hat.
• Ein SMART-Test weist die Platte an, sich selbst zu untersuchen. Ein kurzer Test ist eine schnelle Prüfung der Grundlagen. Ein langer Test liest die gesamte Oberfläche. SMART kann vor einer ausfallenden Platte warnen, noch bevor ZFS einen einzigen Prüfsummenfehler sieht. Es kann aber auch bis zum Tod der Platte nichts melden, deshalb betrachte ich es als Hinweis, nicht als Garantie.
• ZED, der ZFS Event Daemon, reagiert auf Ereignisse, sobald sie auftreten: ein Device geht offline, ein Prüfsummenfehler, ein Scrub endet. Er ist die Komponente, die dir eine Nachricht schicken kann.

Wenn ich nur eines hätte, würde ich Scrubs wählen. Aber ein Scrub, der läuft und Fehler findet, nützt nichts, wenn niemand davon erfährt.

Scrubs: Prüfe, was du schon hast

Auf Debian-basierten Systemen (Proxmox eingeschlossen) bringen die ZFS-Pakete normalerweise einen Cron-Eintrag mit, der Pools monatlich scrubbt. Ich würde das auf der eigenen Kiste prüfen, statt es einfach anzunehmen:

cat /etc/cron.d/zfsutils-linux
zpool status tank | grep -A2 scan:

Die scan:-Zeile verrät dir, wann der letzte Scrub abgeschlossen wurde und ob er etwas repariert hat. Steht dort none requested, ist noch nie einer gelaufen. Auf einer Synology- oder TrueNAS-Kiste liegt die Planung stattdessen in der Oberfläche, schau also dort nach.

Wenn du einen eigenen Zeitplan brauchst, genügt eine einfache Cron-Zeile:

# /etc/cron.d/zfs-scrub-custom
0 2 1 * * root /usr/sbin/zpool scrub tank

Monatlich ist ein gängiger Ausgangspunkt. Ob wöchentlich oder monatlich für einen Home-Pool mit 20 bis 40 TB besser ist, dazu habe ich keine feste Meinung. Ein Scrub liest den gesamten Pool, erzeugt also I/O-Last und etwas Wärme, und ich möchte keinen laufen lassen, während Immich gerade einen großen Import abarbeitet. Ich lege ihn mitten in die Nacht und lasse ihn dort.

Wenn du einen Pool zum Experimentieren haben willst, bevor du den echten anfasst, zeigt dieses Lab, wie man bei einer Proxmox-Installation einen ZFS-Mirror aufbaut:

Du übst dabei, im Rahmen der Installation von Proxmox VE zwei SSDs mit ZFS zu spiegeln. So hast du einen Pool, gegen den du zpool status ausführen kannst.

SMART-Tests mit smartd

Das Paket smartmontools enthält smartd, der geplante Selbsttests ausführt und Attribute überwacht. Die Konfiguration liegt in /etc/smartd.conf. Ein gekürzter Eintrag für eine Platte sieht so aus:

/dev/sda -a -o on -S on -s (S/../.././02|L/../01/./03) -m [email protected]

Grob gesagt: alle Attribute überwachen, täglich um 2 Uhr einen kurzen Test ausführen, am Ersten des Monats um 3 Uhr einen langen Test ausführen und bei Problemen eine Mail senden. Den Regex für den Zeitplan muss ich jedes Mal in man smartd.conf nachlesen. Prüf ihn also gegen deine Version, statt meinem Gedächtnis zu vertrauen.

Zwei Stolpersteine, auf die ich gestoßen bin oder von denen ich gelesen habe:

• HBAs und RAID-Controller. Hinter manchen Controllern brauchst du -d sat oder einen controllerspezifischen Gerätetyp, um an die SMART-Daten der Platte zu kommen. Teste zuerst mit smartctl -a /dev/sdX und trage das Gerät erst danach in smartd.conf ein.
• Keine Überschneidung mit dem Scrub. Lange SMART-Tests auf allen Platten gleichzeitig, während ein Scrub läuft, bedeuten sehr viele parallele Lesezugriffe. Ich staffle sie um einen Tag oder mehr.

ZED: Lass den Pool es dir sagen

Die ZED-Konfiguration liegt auf Debian-artigen Systemen in /etc/zfs/zed.d/zed.rc. Die Einstellungen, die mir wichtig sind:

ZED_EMAIL_ADDR="[email protected]"
ZED_NOTIFY_VERBOSE=1

Mit aktivierten ausführlichen Benachrichtigungen bekommst du eine Nachricht, wenn ein Scrub abgeschlossen ist, nicht nur, wenn etwas kaputtgeht. Das ist wichtiger, als es klingt. Wenn die monatliche Mail „Scrub abgeschlossen, keine Fehler“ ausbleibt, ist genau dieses Schweigen ein Signal.

Der Haken: ZED-Mails brauchen einen funktionierenden Mailweg vom Host aus. Ein Homelab hat meist keinen Mailserver, das heißt, du musst ein Relay konfigurieren (msmtp, Postfix mit Smarthost, was auch immer du schon nutzt). Ich habe genug Geschichten gehört, in denen E-Mail stillschweigend nie funktioniert hat, dass ich mir inzwischen eine Testnachricht schicke, bevor ich dem Ganzen traue:

echo "zed test" | mail -s "nas test" [email protected]

Kommt die nicht an, kommt auch nichts anderes aus diesem Beitrag an.

Ein Heartbeat, weil E-Mail leise versagt

Alarme helfen nur, wenn der Alarmweg funktioniert. Der Fehlerfall, der mir Sorgen macht, ist kein lauter: Das NAS ist offline, der Cron-Job wurde deaktiviert oder das Mail-Relay ist kaputt, und alles bleibt ruhig.

Deshalb baue ich einen Heartbeat ein. Uptime Kuma hat einen Push-Monitor-Typ: Du bekommst eine URL, und wenn sie nicht innerhalb des eingestellten Intervalls aufgerufen wird, markiert Kuma den Monitor als down und benachrichtigt dich. Ein kleines Skript auf dem NAS prüft den Zustand des Pools und pingt nur, wenn alles sauber ist:

#!/usr/bin/env bash
# /usr/local/bin/zfs-heartbeat.sh
set -u
PUSH_URL="https://kuma.lab.example/api/push/REPLACE_WITH_TOKEN"

if [ "$(zpool status -x)" = "all pools are healthy" ]; then
  curl -fsS -m 10 "${PUSH_URL}?status=up&msg=OK" > /dev/null
fi

Starte es etwa alle 15 Minuten per Cron und stelle das Heartbeat-Intervall des Kuma-Monitors etwas länger ein. Die Logik ist Absicht: Das Skript meldet selbst nie ein Problem. Es meldet nur Gesundheit, und das Ausbleiben des Pings ist der Alarm. Damit sind ein degradierter Pool, ein toter Host, ein kaputter Cron-Job und ein defekter Netzwerkpfad mit derselben Regel abgedeckt.

Der String-Vergleich auf all pools are healthy entspricht dem, was zpool status -x ausgibt, wenn alles in Ordnung ist. In meiner Erfahrung war das bisher stabil, aber ich würde es an einem absichtlich degradierten Test-Pool prüfen, bevor ich mich darauf verlasse.

Was ich nicht getestet habe

• Ich habe noch keine Platte aus einem Mirror gezogen, um die komplette Alarmkette Ende-zu-Ende auslösen zu sehen. Das gehört in dieselbe Übung wie meine Restore-Tests, und ich mache es an einem Scratch-Pool, nicht am echten.
• Ich bin mir nicht sicher, wie laut ZED_NOTIFY_VERBOSE=1 über Monate wird. Eventuell drehe ich es zurück.
• Ich weiß nicht, ob der Heartbeat auch den SMART-Status prüfen sollte oder ob das ein Skript zu viel wäre.

Fragen an euch

Wie oft scrubbt ihr einen Pool dieser Größe, und habt ihr den Zeitplan je geändert, nachdem ihr die Auswirkungen auf die I/O gesehen habt? Vertraut ihr SMART-Warnungen genug, um eine Platte aufgrund davon zu tauschen, oder wartet ihr auf ZFS-Fehler? Und hat jemand für ein Homelab einen saubereren Alarmweg als ein Mail-Relay gefunden?