ZFS: Ihre Scrubs laufen vielleicht gar nicht (cron fehlt)

ZFS hat eine seltene Eigenschaft: Es kann stille Datenbeschädigung erkennen und reparieren, also Bits, die auf der Festplatte nach und nach kippen, ohne dass irgendeine Anwendung es bemerkt. Aber diese Prüfung, der Scrub, startet nicht von selbst: Sie muss geplant werden. Und genau hier wartet auf minimale Installationen eine unauffällige Falle: Die von den ZFS-Paketen abgelegte Planung setzt eine Komponente voraus, die nicht immer vorhanden ist.

Die Falle: cron-Aufgaben ohne cron #

Unter Debian legt das Paket zfsutils eine Datei in /etc/cron.d/ ab, die monatlich einen Scrub jedes Pools startet. Alles beruht also auf einer Annahme: dass ein cron-Daemon dieses Verzeichnis liest. Auf einer minimalen Installation (und wir haben das auf Proxmox-Hypervisoren unserer eigenen Serverflotte festgestellt) ist das Paket cron aber unter Umständen gar nicht installiert. Die Dateien in /etc/cron.d/ sind dann toter Text: Nichts liest sie, nichts wird ausgeführt, und nichts meldet es. Der Pool zeigt stolz state: ONLINE, während sich stille Datenbeschädigung ansammelt, ohne dass je nach ihr gesucht wird.

Das ist ein klassischer Konstruktionsfehler: Eine Wartung, die lautlos scheitert, ist schlimmer als gar keine Wartung, weil sie die Illusion vermittelt, abgesichert zu sein. Dreißig Sekunden genügen, um zu wissen, wo Sie stehen:

# Ist der cron-Daemon überhaupt installiert?
dpkg -l cron 2>/dev/null | grep ^ii || echo 'cron ABSENT'

# Was wird von ihm erwartet?
ls /etc/cron.d/

# Datum des letzten tatsächlich ausgeführten Scrubs:
zpool status | grep scan
# 'scrub repaired 0B in ... ' + aktuelles Datum = OK
# 'none requested' = es ist NOCH NIE ein Scrub gelaufen

Zeigt die Zeile scan bei einem Pool, der seit Monaten in Betrieb ist, none requested an, haben Sie gerade dasselbe Problem gefunden wie wir.

Die saubere Umsetzung: systemd-Timer #

Statt cron für zwei Aufgaben zu installieren, überträgt man die Planung besser dem, was schon vorhanden und überwachbar ist: systemd. Zwei Vorlagen-Units (@) reichen für alle Pools; hier der monatliche Scrub:

# /etc/systemd/system/zfs-scrub@.service
[Unit]
Description=Scrub ZFS du pool %i

[Service]
Type=oneshot
ExecStart=/usr/sbin/zpool scrub -w %i

# /etc/systemd/system/zfs-scrub@.timer
[Unit]
Description=Scrub ZFS mensuel du pool %i

[Timer]
OnCalendar=*-*-01 03:00
RandomizedDelaySec=6h
Persistent=true

[Install]
WantedBy=timers.target

Dasselbe Schema gilt für den TRIM der Pools auf SSD (zpool trim), bei uns wöchentlich. Aktivierung pro Pool, dann Prüfung, und hier zahlt sich systemd aus: Die Planung wird beobachtbar:

systemctl enable --now zfs-scrub@rpool.timer
systemctl enable --now zfs-trim@rpool.timer

# Der Nachweis, jederzeit:
systemctl list-timers 'zfs-*'
# NEXT = nächste Ausführung, LAST = letzte: kein toter Winkel mehr

Das letzte Glied: benachrichtigt werden #

Ein Scrub, der Fehler findet, nützt nichts, wenn niemand das Ergebnis liest. ZFS liefert ZED (ZFS Event Daemon) mit, der bei Ereignissen benachrichtigen kann, aber seine Standardkonfiguration verschickt nichts, und seine Benachrichtigung per E-Mail setzt einen funktionierenden lokalen MTA voraus, den moderne Server nicht mehr haben. Bei uns schließt sich der Kreis anders: Der Zustand der Pools und Timer fließt in die zentrale Überwachung ein, die über die bereits eingerichteten Kanäle alarmiert. Das Werkzeug ist zweitrangig, das Prinzip ist dasselbe wie bei den Backups: Jede Wartung muss nachweisen, dass sie gelaufen ist, und laut werden, wenn sie scheitert.

Genau diese Art von Prüfung decken unsere Managed Services ab: keine Magie, nur eine Liste von Dingen, die laufen müssen, und der Nachweis, dass sie laufen. Zweifel an Ihren ZFS-Pools? Die drei Befehle vom Anfang geben Ihnen die Antwort; wir auch, falls nötig.