Programar scrubs de ZFS y pruebas SMART, y recibir alertas cuando fallan

Mi NAS ha estado sano desde que lo tengo. Lo sé porque no he visto ningún error. Pero eso no es lo mismo que haber comprobado el pool. Durante mucho tiempo mi plan de monitorización para ZFS fue "ya me daré cuenta", y solo me daba cuenta de las cosas cuando por casualidad ejecutaba zpool status por otro motivo.

Este post cubre las tres capas que estoy implementando: scrubs programados, pruebas SMART programadas y una vía de alertas que no depende de que yo me acuerde de mirar. Todavía no lo he tenido funcionando un año completo, así que tómalo como una configuración en funcionamiento. Señalaré dónde tengo dudas.

Qué detecta realmente cada comprobación

Se solapan, pero no son lo mismo.

• Un scrub lee cada bloque del pool y lo verifica contra su checksum. Con redundancia (mirror, RAIDZ), ZFS repara lo que puede a partir de la copia buena. Encuentra corrupción silenciosa en datos que nadie ha leído en meses.
• Una prueba SMART le pide al disco que se examine a sí mismo. Una prueba corta es una comprobación rápida de lo básico. Una prueba larga lee toda la superficie. SMART puede avisar de un disco que está fallando antes de que ZFS vea un solo error de checksum. También puede no decir nada hasta justo antes de que el disco muera, así que lo trato como una pista, no como una garantía.
• ZED, el ZFS Event Daemon, reacciona a los eventos según ocurren: un dispositivo que pasa a offline, un error de checksum, un scrub que termina. Es la pieza que puede enviarte un mensaje.

Si solo pudiera tener una, elegiría los scrubs. Pero un scrub que se ejecuta y encuentra errores no sirve de nada si nadie se entera.

Scrubs: revisa lo que ya tienes

En sistemas basados en Debian (Proxmox incluido), los paquetes de ZFS suelen traer una entrada de cron que hace scrub de los pools una vez al mes. Yo lo verificaría en tu propio equipo en lugar de darlo por hecho:

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

La línea scan: te dice cuándo terminó el último scrub y si reparó algo. Si dice none requested, nunca se ha ejecutado ninguno. En un equipo Synology o TrueNAS la programación está en la interfaz, así que revísala allí.

Si necesitas añadir tu propia programación, una simple línea de cron funciona:

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

Mensual es un punto de partida habitual. No tengo una opinión firme sobre semanal frente a mensual para un pool doméstico de 20 a 40 TB. Un scrub lee el pool entero, así que añade carga de I/O y algo de calor, y prefiero no lanzar uno mientras Immich está procesando una importación grande. Lo programo para la madrugada y lo dejo así.

Si quieres un pool con el que experimentar antes de tocar el real, este lab explica cómo crear un mirror de ZFS durante una instalación de Proxmox:

Practicarás el mirroring de dos SSD con ZFS como parte de la instalación de Proxmox VE, lo que te da un pool contra el que ejecutar zpool status.

Pruebas SMART con smartd

El paquete smartmontools incluye smartd, que ejecuta autopruebas programadas y vigila los atributos. La configuración está en /etc/smartd.conf. Una entrada reducida para un disco se ve así:

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

A grandes rasgos: monitoriza todos los atributos, ejecuta una prueba corta a diario a las 2 AM, una prueba larga el día 1 de cada mes a las 3 AM, y envía un correo si hay problemas. La expresión regular de la programación es la parte que siempre tengo que releer en man smartd.conf, así que compruébala contra tu versión en lugar de fiarte de mi memoria.

Dos salvedades con las que me he topado o sobre las que he leído:

• HBAs y controladoras RAID. Detrás de algunas controladoras necesitas -d sat o un tipo de dispositivo específico de la controladora para llegar a los datos SMART del disco. Prueba primero con smartctl -a /dev/sdX y solo después pon el dispositivo en smartd.conf.
• No lo solapes con el scrub. Pruebas SMART largas en todos los discos a la vez, durante un scrub, son muchísimas lecturas simultáneas. Yo las escalono con un día o más de diferencia.

ZED: deja que el pool te avise

La configuración de ZED en sistemas tipo Debian está en /etc/zfs/zed.d/zed.rc. Los ajustes que me importan:

ZED_EMAIL_ADDR="[email protected]"
ZED_NOTIFY_VERBOSE=1

Con las notificaciones verbose activadas, recibes un mensaje cuando termina un scrub, no solo cuando algo se rompe. Eso importa más de lo que parece. Si el correo mensual de "scrub terminado, sin errores" deja de llegar, ese silencio es en sí mismo una señal.

El problema es que el correo de ZED necesita una vía de correo funcional desde el host. Un homelab normalmente no tiene servidor de correo, así que esto implica configurar un relay (msmtp, Postfix con un smarthost, lo que ya uses). He visto suficientes historias de "el correo nunca funcionó y nadie se enteró" como para enviarme ahora un mensaje de prueba antes de fiarme:

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

Si eso no llega, nada más de este post llegará tampoco.

Un heartbeat, porque el correo falla en silencio

Las alertas solo sirven si la vía de alertas funciona. El modo de fallo que me preocupa no es uno ruidoso: es que el NAS esté offline, que el trabajo de cron esté deshabilitado o que el relay de correo se rompa, y que todo siga en calma.

Así que estoy añadiendo un heartbeat. Uptime Kuma tiene un tipo de monitor push: te da una URL, y si no recibe una petición dentro del intervalo que configures, Kuma marca el monitor como caído y te notifica. Un pequeño script en el NAS comprueba la salud del pool y solo hace ping cuando está limpio:

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

Ejecútalo desde cron cada 15 minutos más o menos, y configura el intervalo de heartbeat del monitor de Kuma algo más largo que eso. La lógica es deliberada: el script nunca reporta un problema por sí mismo. Solo reporta salud, y la ausencia del ping es la alarma. Eso cubre un pool degradado, un host caído, un trabajo de cron roto y una ruta de red rota con la misma regla.

La comparación de cadena con all pools are healthy es lo que imprime zpool status -x cuando no pasa nada. En mi experiencia ha sido estable, pero lo probaría en un pool de pruebas degradado a propósito antes de depender de ello.

Lo que no he probado

• No he sacado un disco de un mirror para ver toda la cadena de alertas dispararse de principio a fin. Eso pertenece al mismo simulacro que mis pruebas de restauración, y lo haré en un pool de pruebas, no en el real.
• No estoy seguro de cuánto ruido genera ZED_NOTIFY_VERBOSE=1 con el paso de los meses. Puede que lo baje.
• No sé si el heartbeat debería comprobar también el estado SMART, o si eso sería un script de más.

Preguntas para ti

¿Con qué frecuencia haces scrub de un pool de este tamaño, y alguna vez cambiaste la programación después de ver el impacto en I/O? ¿Confías lo bastante en los avisos de SMART como para reemplazar un disco por ellos, o esperas a los errores de ZFS? ¿Y alguien ha encontrado una vía de alertas más limpia que un relay de correo para un homelab?