Planifier les scrubs ZFS et les tests SMART, et être alerté en cas d'échec

Mon NAS est en bonne santé depuis que je le possède. Je le sais parce que je n'ai vu aucune erreur. Ce n'est pas la même chose que d'avoir vérifié le pool. Pendant longtemps, mon plan de supervision pour ZFS était « je m'en apercevrai », et je ne m'apercevais de quelque chose que lorsque je lançais zpool status par hasard pour une autre raison.

Ce post présente les trois couches que je mets en place : des scrubs planifiés, des tests SMART planifiés, et un circuit d'alerte qui ne dépend pas de ma mémoire pour aller regarder. Je n'ai pas encore fait tourner tout ça pendant une année complète, donc considérez-le comme une configuration qui fonctionne. Je signalerai les endroits où j'ai des doutes.

Ce que chaque vérification détecte réellement

Elles se recoupent, mais ce n'est pas la même chose.

• Un scrub lit chaque bloc du pool et le vérifie par rapport à son checksum. Avec de la redondance (mirror, RAIDZ), ZFS répare ce qu'il peut à partir de la bonne copie. Il trouve la corruption silencieuse que personne n'a lue depuis des mois.
• Un test SMART demande au disque de s'auto-examiner. Un test court est une vérification rapide des bases. Un test long lit toute la surface. SMART peut avertir qu'un disque est en train de lâcher avant que ZFS ne voie la moindre erreur de checksum. Il peut aussi ne rien dire jusqu'à la mort du disque, donc je le considère comme un indice, pas comme une garantie.
• ZED, le ZFS Event Daemon, réagit aux événements au moment où ils se produisent : un périphérique qui passe hors ligne, une erreur de checksum, la fin d'un scrub. C'est la brique qui peut vous envoyer un message.

Si je ne devais en garder qu'une, je choisirais les scrubs. Mais un scrub qui tourne et trouve des erreurs ne sert à rien si personne n'en est informé.

Scrubs : vérifiez ce que vous avez déjà

Sur les systèmes basés sur Debian (Proxmox compris), les paquets ZFS livrent généralement une entrée cron qui lance un scrub des pools chaque mois. Je vous conseille de le vérifier sur votre propre machine plutôt que de le supposer :

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

La ligne scan: vous indique quand le dernier scrub s'est terminé et s'il a réparé quelque chose. Si elle indique none requested, rien n'a jamais été lancé. Sur un Synology ou un TrueNAS, la planification se trouve plutôt dans l'interface, donc regardez là-bas.

Si vous devez ajouter votre propre planification, une simple ligne cron suffit :

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

Un scrub mensuel est un point de départ courant. Je n'ai pas d'avis tranché entre hebdomadaire et mensuel pour un pool domestique de 20 à 40 To. Un scrub lit l'intégralité du pool, ce qui ajoute de la charge d'I/O et un peu de chaleur, et je préfère ne pas en lancer un pendant qu'Immich digère un gros import. Je le planifie au milieu de la nuit et je n'y touche plus.

Si vous voulez un pool pour expérimenter avant de toucher au vrai, ce lab explique comment construire un mirror ZFS pendant une installation de Proxmox :

Vous vous exercerez à mettre en miroir deux SSD avec ZFS dans le cadre de l'installation de Proxmox VE, ce qui vous donne un pool sur lequel lancer zpool status.

Tests SMART avec smartd

Le paquet smartmontools inclut smartd, qui exécute des auto-tests planifiés et surveille les attributs. La configuration se trouve dans /etc/smartd.conf. Une entrée simplifiée pour un disque ressemble à ceci :

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

En gros : surveiller tous les attributs, lancer un test court tous les jours à 2 h, lancer un test long le premier du mois à 3 h, et envoyer un mail en cas de problème. La regex de planification est la partie que je dois toujours relire dans man smartd.conf, donc vérifiez-la par rapport à votre version plutôt que de vous fier à ma mémoire.

Deux réserves que j'ai rencontrées ou dont j'ai lu le récit :

• HBA et contrôleurs RAID. Derrière certains contrôleurs, il faut -d sat ou un type de périphérique propre au contrôleur pour accéder aux données SMART du disque. Testez d'abord avec smartctl -a /dev/sdX, et ne mettez le périphérique dans smartd.conf qu'ensuite.
• Ne pas chevaucher le scrub. Lancer des tests SMART longs sur tous les disques en même temps, pendant un scrub, représente beaucoup de lectures simultanées. Je les décale d'un jour ou plus.

ZED : laissez le pool vous prévenir

La configuration de ZED sur les systèmes de type Debian se trouve dans /etc/zfs/zed.d/zed.rc. Les paramètres qui m'intéressent :

ZED_EMAIL_ADDR="[email protected]"
ZED_NOTIFY_VERBOSE=1

Avec les notifications verbeuses activées, vous recevez un message quand un scrub se termine, et pas seulement quand quelque chose casse. C'est plus important qu'il n'y paraît. Si le mail mensuel « scrub terminé, aucune erreur » cesse d'arriver, ce silence est en soi un signal.

Le hic, c'est que les mails de ZED nécessitent un chemin d'envoi fonctionnel depuis l'hôte. Un homelab n'a généralement pas de serveur de mail, ce qui implique de configurer un relais (msmtp, Postfix avec un smarthost, ce que vous utilisez déjà). J'ai entendu assez d'histoires de « l'e-mail n'a jamais fonctionné, sans qu'on s'en rende compte » pour m'envoyer désormais un message de test avant de faire confiance au dispositif :

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

Si ce message n'arrive pas, rien d'autre dans ce post n'arrivera non plus.

Un heartbeat, parce que l'e-mail échoue en silence

Les alertes ne servent que si le chemin d'alerte fonctionne. Le mode de défaillance qui m'inquiète n'est pas bruyant : c'est le NAS hors ligne, la tâche cron désactivée ou le relais de mail en panne, avec tout qui reste calme.

J'ajoute donc un heartbeat. Uptime Kuma propose un type de moniteur push : vous obtenez une URL, et si elle n'est pas appelée dans l'intervalle que vous avez défini, Kuma marque le moniteur comme hors service et vous notifie. Un petit script sur le NAS vérifie la santé du pool et n'envoie un ping que si tout est propre :

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

Lancez-le depuis cron toutes les 15 minutes environ, et réglez l'intervalle de heartbeat du moniteur Kuma un peu plus long. La logique est délibérée : le script ne signale jamais un problème lui-même. Il ne signale que la bonne santé, et l'absence de ping est l'alarme. Cela couvre un pool dégradé, un hôte mort, une tâche cron cassée et un chemin réseau défaillant avec la même règle.

La correspondance de chaîne sur all pools are healthy correspond à ce que zpool status -x affiche quand tout va bien. Dans mon expérience, cela a été stable, mais je le testerais sur un pool de test volontairement dégradé avant de m'y fier.

Ce que je n'ai pas testé

• Je n'ai pas retiré un disque d'un mirror pour voir toute la chaîne d'alerte se déclencher de bout en bout. Cela relève du même exercice que mes tests de restauration, et je le ferai sur un pool de test, pas sur le vrai.
• Je ne sais pas à quel point ZED_NOTIFY_VERBOSE=1 devient bruyant au fil des mois. Je le réduirai peut-être.
• Je ne sais pas si le heartbeat devrait aussi vérifier l'état SMART, ou si ce serait un script de trop.

Questions pour vous

À quelle fréquence faites-vous un scrub sur un pool de cette taille, et avez-vous déjà changé la planification après avoir constaté l'impact sur les I/O ? Faites-vous assez confiance aux avertissements SMART pour remplacer un disque à cause d'eux, ou attendez-vous les erreurs ZFS ? Et quelqu'un a-t-il trouvé un chemin d'alerte plus propre qu'un relais de mail pour un homelab ?