Eventos de zpool de ZFS: el registro que ignoras hasta que te salva

Qué son realmente los eventos de zpool (y qué no son)

zpool events es el feed de eventos de ZFS. Muestra una línea temporal de eventos significativos relacionados con el pool:
errores de E/S en disco, problemas de checksum, cambios de estado de vdev, inicio y fin de scrubs, resilvers y diversos informes de gestión de fallos
(“ereports”). Es lo que desearías haber conservado cuando alguien pregunta: “¿Cuándo empezó esto?”

No es un reemplazo de zpool status. Piénsalo así:

• zpool status te dice el estado actual y un historial resumido (errores recientes, resilver/scrub en curso, etc.).
• zpool events te cuenta la secuencia de eventos que te llevó allí, a menudo con más contexto y la hora exacta.
• Los registros del sistema (mensajes del kernel, journalctl) te cuentan los síntomas a nivel SO: reinicios, timeouts, flaps de enlace.

Bajo el capó, en muchas plataformas, ZFS se integra en una canalización de gestión de fallos. En illumos/Solaris verás
el vocabulario de la Fault Management Architecture (FMA) más explícitamente. En Linux, ZED (ZFS Event Daemon) y la realidad tipo udev
proporcionan el puente de “algo pasó” hacia scripts, email y sistemas de tickets. Las palabras difieren; la intención operacional
es la misma: convertir rarezas de bajo nivel en una llamada antes de que los datos estén en riesgo.

Tu trabajo no es memorizar cada clase de evento. Tu trabajo es construir el hábito de correlacionar:
evento → dispositivo → síntoma de carga → riesgo → acción. Haz eso y zpool events deja de ser trivia y pasa a ser una palanca.

Primera broma seca, como prometí: ZFS tiene un gran sentido del humor—cada “checksum error” es el remate donde tu proveedor de almacenamiento hace la puesta en escena.

Datos interesantes y un poco de historia

Esto no es nostalgia. Son pistas sobre por qué las herramientas lucen como lucen y por qué algunos comportamientos sorprenden a la gente.

1. ZFS nació en Sun Microsystems y fue diseñado para tratar la integridad de los datos como una característica de primera clase, no como un accesorio de mejores esfuerzos.
2. Checksum de extremo a extremo significa que ZFS verifica los datos desde el disco hasta la memoria y la ruta de lectura de la aplicación; puede detectar corrupción silenciosa que los controladores RAID completan felizmente.
3. El lenguaje “ereport” viene de FMA (Fault Management Architecture), donde los fallos y diagnósticos están estructurados, no son basura de log libre.
4. zpool scrub es verificación proactiva; no es “desfragmentación” ni “teatro de mantenimiento”. Es una forma controlada de encontrar errores latentes antes de que falle un disco.
5. El resilvering es incremental en OpenZFS moderno: puede copiar solo lo que está en uso (especialmente con funciones como resilver secuencial), reduciendo el tiempo de reconstrucción comparado con reconstrucciones RAID antiguas.
6. ZFS prefiere intencionalmente la corrección sobre el optimismo; degradará un pool en lugar de seguir fingiendo que todo está bien si no puede confiar en las lecturas de un dispositivo.
7. Existe el demonio ZED porque los eventos necesitan acciones; la salida del comando es útil, pero operativamente quieres hooks: alertas, flujos de reemplazo y exportaciones automáticas para eventos de retirada.
8. Históricamente, las pilas de almacenamiento ocultaban errores detrás de “reintentos” y caches de controlador; ZFS hizo los errores visibles, lo cual es genial—si no los ignoras.
9. OpenZFS se volvió multiplataforma (Linux, FreeBSD, illumos), y la plomería de eventos difiere por SO, por eso los consejos deben nombrar las suposiciones de plataforma.

Una implicación operacional real: la gente que migra desde RAID por hardware suele asumir que el controlador “lo manejará”.
ZFS asume lo contrario: la pila es poco fiable hasta que se demuestre lo contrario. No es paranoia. Es experiencia.

Un modelo mental práctico: de síntomas a eventos a decisiones

1) Los eventos son señales; el estado es el resumen diagnóstico

Cuando un vdev pasa a DEGRADED, zpool status te dice qué es ahora. Pero zpool events puede decirte si fue:
una tormenta de reinicios de enlace, un cable malo, timeouts de firmware, un problema de energía o fallo real de soporte. Esos requieren soluciones diferentes.

2) No todos los errores son iguales

Tres categorías importan operativamente:

• Errores de transporte transitorios (timeouts, reinicios): a menudo cableado/HBA/backplane/energía. Reemplazar discos y aún tendrás el problema.
• Errores de lectura consistentes: probable fallo de medio. Reemplaza el dispositivo; revisa tu redundancia y comienza un resilver.
• Errores de checksum: pueden ser disco, cable, controlador, RAM (menos común con ECC) o firmware. Necesitas correlación, no adivinanzas.

3) “El scrub encontró errores” significa “acabas de aprender algo”, no “pánico”

Los errores detectados por scrub son telemetría de alerta temprana. Tu respuesta debe ser calmada y metódica:
identifica qué dispositivo(s), qué tipo de error, si los errores se repiten y si la redundancia cubrió el daño.
La línea temporal de eventos te ayuda a determinar si esto es un incidente único o una tendencia.

4) Operativamente, persigues dos preguntas

• ¿Están los datos en riesgo ahora? (pool en faulted, sin redundancia, errores durante scrub/resilver)
• ¿Está mintiendo la plataforma? (inestabilidad de transporte, reinicios intermitentes, errores de checksum “aleatorios” en múltiples discos)

La primera pregunta decide la urgencia. La segunda decide si tu arreglo realmente arreglará el problema.

Una cita que debería estar en cada rotación de on-call, de una voz notable en fiabilidad:
“La esperanza no es una estrategia.” — Gene Kranz

Guion de diagnóstico rápido (qué comprobar 1.º/2.º/3.º)

Esta es la secuencia que uso cuando un pool parece enfermo, el rendimiento cae o alguien publica una captura de pantalla de DEGRADED en el chat
sin más contexto. Está diseñada para rapidez y para evitar el error clásico: cambiar discos antes de saber qué falló.

Primero: establece el riesgo actual y si ya estás en modo “detener la hemorragia”

• Comprueba el estado del pool (zpool status -x, zpool status): ¿está degradado, faulted, suspendido, resilvering o scrubbing?
• Comprueba si la redundancia está intacta: cuántos vdevs, qué nivel de paridad, ¿faltan dispositivos?
• Comprueba si los errores siguen aumentando: conteos repetidos de lectura/escritura/checksum en aumento indican un problema activo.

Segundo: extrae la línea temporal de eventos e identifica la clase de fallo

• Mira eventos recientes (zpool events -v): ¿ves timeouts, retiradas, ereports de checksum, scrub terminado con errores?
• Correlaciona marcas de tiempo con los logs del kernel: los reinicios de enlace y errores SCSI suelen contar la historia del transporte.
• Mira la dispersión: un disco vs. múltiples discos en el mismo HBA/backplane. Varias fallas simultáneas rara vez son “mala suerte”.

Tercero: decide la vía—reemplazo de hardware, estabilización del transporte o contención de la carga

• Dispositivo único con errores de lectura persistentes: prepara el reemplazo, haz offline/replace, monitoriza el resilver.
• Múltiples dispositivos con problemas intermitentes: revisa cables, firmware/controlador HBA, backplane, energía; evita fallos en cascada durante una reconstrucción pesada.
• Scrub/resilver lento: inspecciona saturación de I/O, incompatibilidad recordsize/workload, problemas de vdev especiales, comportamiento SMR o un dispositivo enfermo que está relentizando el vdev.

Si recuerdas solo una cosa: la forma más rápida de perder un día es reemplazar hardware antes de clasificar la falla.
Los eventos te ayudan a clasificarla.

Tareas prácticas: comandos, salidas y la decisión que tomas

Estas son tareas reales que puedes ejecutar durante un incidente o como higiene rutinaria. Cada una incluye:
el comando, un ejemplo de lo que podrías ver, qué significa y qué decides a continuación.
Los nombres de host y de pools son intencionalmente anodinos; los sistemas de producción rara vez lo son.

Task 1: “¿Realmente hay algo mal?” comprobación rápida

cr0x@server:~$ zpool status -x
all pools are healthy

Significado: ZFS no detecta fallos conocidos ahora mismo.
Decisión: Si los usuarios reportan lentitud igualmente, cambia al triage de rendimiento (iostat, latencia, profundidad de cola). Aún así revisa eventos por problemas transitorios recientes.

Task 2: Obtén la imagen completa de salud actual (no seas vago)

cr0x@server:~$ zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:12:11 with 2 errors on Sun Dec 21 01:10:44 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     2

errors: Permanent errors have been detected in the following files:
        tank/data/vmstore/guest42.img

Significado: Un scrub encontró corrupción incorrigible que afecta al menos a un archivo; los errores de checksum apuntan a una ruta de disco específica.
Decisión: Trátalo como incidente de integridad de datos. Identifica si la corrupción está limitada a ese archivo, restaura desde backup/snapshot e investiga inmediatamente el disco/transporte.

Task 3: Extrae eventos recientes con detalles verbosos

cr0x@server:~$ zpool events -v | tail -n 40
time: 2025-12-21.01:10:44
eid: 1876
class: scrub_finish
pool: tank
pool_guid: 1234567890123456789
scrub_errors: 2
scrub_repaired: 0
scrub_time_secs: 11531

time: 2025-12-21.00:58:19
eid: 1869
class: ereport.fs.zfs.checksum
pool: tank
vdev_guid: 9876543210987654321
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1
zio_err: 52
zio_objset: 54
zio_object: 102938
zio_level: 0

Significado: Tienes un ereport de checksum ligado a una ruta de vdev específica antes de que el scrub terminara con errores.
Decisión: Correlaciona esta marca de tiempo con los logs del kernel; decide si el disco está malo o si el transporte es inestable. Empieza con comprobaciones de transporte si existen eventos similares en múltiples discos.

Task 4: Sigue eventos en vivo durante una reconstrucción o sospecha de flapping

cr0x@server:~$ zpool events -f
time: 2025-12-25.09:14:03
eid: 2101
class: resilver_start
pool: tank
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1

time: 2025-12-25.09:16:27
eid: 2104
class: ereport.fs.zfs.io
pool: tank
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1
zio_err: 5

Significado: Los errores durante un resilver son especialmente peligrosos: estás forzando el sistema mientras la redundancia ya está reducida.
Decisión: Si los errores persisten, pausa y estabiliza: revisa cables/HBA, considera hacer offline el dispositivo sospechoso para evitar la suspensión del pool y reduce la carga durante el resilver.

Task 5: Confirma las propiedades del pool que afectan el comportamiento durante incidentes

cr0x@server:~$ zpool get -o name,property,value,source autoreplace,failmode,autotrim tank
NAME  PROPERTY     VALUE     SOURCE
tank  autoreplace  off       default
tank  failmode     wait      default
tank  autotrim     on        local

Significado: failmode=wait puede detener I/O cuando el pool no puede proceder con seguridad; autoreplace=off significa que debes reemplazar explícitamente.
Decisión: Para flotas, estandariza esto. En un incidente, conocer failmode explica “por qué todo se congeló” e informa si export/import o failover es apropiado.

Task 6: Identifica el disco exacto detrás de una ruta vdev

cr0x@server:~$ ls -l /dev/disk/by-id/ata-WDC_WD80...-part1
lrwxrwxrwx 1 root root 10 Dec 25 08:59 /dev/disk/by-id/ata-WDC_WD80...-part1 -> ../../sdc1

Significado: La ruta “amigable” by-id mapea a /dev/sdc1 ahora mismo.
Decisión: Usa rutas by-id en la configuración ZFS para reducir la “ruleta sdX” tras reinicios. Para el reemplazo, confirma la bahía física usando herramientas del enclosure si están disponibles.

Task 7: Correlaciona eventos ZFS con reinicios/timeouts a nivel OS (Linux)

cr0x@server:~$ journalctl -k --since "2025-12-21 00:50" --until "2025-12-21 01:05" | egrep -i "sd[cde]|ata|sas|reset|timeout|I/O error" | tail -n 20
Dec 21 00:58:11 server kernel: ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 21 00:58:12 server kernel: ata7.00: failed command: READ FPDMA QUEUED
Dec 21 00:58:12 server kernel: ata7: hard resetting link
Dec 21 00:58:17 server kernel: sd 7:0:0:0: [sdc] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 21 00:58:17 server kernel: sd 7:0:0:0: [sdc] Sense Key : Medium Error [current]
Dec 21 00:58:17 server kernel: blk_update_request: I/O error, dev sdc, sector 771920896 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Significado: Esto parece un problema real de medio (Medium Error) además de reinicios. No es solo un “pequeño movimiento del cable”.
Decisión: Reemplaza el disco. Aun así, inspecciona cableado/backplane si ves reinicios en múltiples puertos.

Task 8: Verifica la programación de scrub y el último resultado

cr0x@server:~$ zpool status tank | sed -n '1,20p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:44:09 with 0 errors on Sun Dec 14 03:12:33 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0

Significado: El scrub reciente se completó sin problemas; buena línea de base.
Decisión: Si el incidente de hoy es “repentino”, compáralo con el tiempo de eventos. Un scrub limpio la semana pasada hace menos probable “meses de corrupción silenciosa”.

Task 9: Lanza un scrub intencionalmente (y vigila problemas)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ zpool status tank | egrep -i "scan|scrub"
  scan: scrub in progress since Thu Dec 25 09:22:10 2025
        312G scanned at 1.12G/s, 74.2G issued at 273M/s, 4.21T total
        0B repaired, 1.72% done, no estimated completion time

Significado: El scrub está en marcha; la tasa “issued” muestra las lecturas realmente enviadas. Si va lento, algo está limitando.
Decisión: Si la velocidad del scrub colapsa, busca un disco enfermo, unidades SMR o un sistema sobrecargado. Considera programar scrubs fuera de pico o reducir temporalmente la carga.

Task 10: Averigua si los errores están concentrados en un vdev (vista rápida por vdev)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            /dev/disk/by-id/ata-ST4000...  ONLINE       0     0     0
            /dev/disk/by-id/ata-ST4000...  DEGRADED     0     0    34

errors: No known data errors

Significado: Muchos errores de checksum en un lado del mirror, pero ZFS pudo corregirlos usando el otro lado (sin errores permanentes).
Decisión: Sigue siendo un defecto de hardware/transporte. Planifica el reemplazo; no te felicites porque la redundancia te salvó esta vez.

Task 11: Reemplaza un disco fallado de forma segura (ejemplo mirror)

cr0x@server:~$ sudo zpool offline tank /dev/disk/by-id/ata-ST4000...bad
cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-ST4000...bad /dev/disk/by-id/ata-ST4000...new
cr0x@server:~$ zpool status tank | egrep -i "state|scan|resilver"
 state: DEGRADED
  scan: resilver in progress since Thu Dec 25 09:31:02 2025
        98.4G scanned at 1.02G/s, 21.7G issued at 231M/s, 98.4G total
        21.7G resilvered, 22.06% done, 0:05:09 to go

Significado: Reemplazo iniciado; el resilver progresa.
Decisión: Vigila eventos nuevos durante el resilver. Si más dispositivos fallan, para y reevalúa la plataforma (HBA/backplane/energía) antes de convertir una falla en tres.

Task 12: Comprueba que ZED está instalado y funcionando (systemd en Linux)

cr0x@server:~$ systemctl status zfs-zed.service --no-pager
● zfs-zed.service - ZFS Event Daemon (zed)
     Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-25 07:12:09 UTC; 2h 19min ago
       Docs: man:zed(8)
   Main PID: 1124 (zed)
      Tasks: 2 (limit: 38454)
     Memory: 4.3M
        CPU: 1.221s

Significado: ZED está en marcha, por lo que los eventos pueden disparar notificaciones y scripts.
Decisión: Si ZED no está activo, dependes de humanos para notar zpool status. Arregla eso—hoy, no “después del cierre del trimestre”.

Task 13: Inspecciona la actividad reciente de ZED por alertas perdidas

cr0x@server:~$ journalctl -u zfs-zed.service --since "2025-12-21 00:00" | tail -n 25
Dec 21 00:58:20 server zed[1124]: eid=1869 class=ereport.fs.zfs.checksum pool=tank
Dec 21 00:58:20 server zed[1124]: Executing ZEDLET: /usr/lib/zfs/zed.d/zed.rc
Dec 21 00:58:20 server zed[1124]: Executing ZEDLET: /usr/lib/zfs/zed.d/all-syslog.sh
Dec 21 00:58:20 server zed[1124]: Executing ZEDLET: /usr/lib/zfs/zed.d/zed.email
Dec 21 00:58:20 server zed[1124]: email: to=storage-oncall@example.internal subject="ZFS checksum error on tank"

Significado: ZED vio el ereport de checksum y ejecutó los hooks de alerta.
Decisión: Si el on-call dice “no llegó alerta”, investiga el ruteo de correo/ingestión del monitoreo. ZFS hizo su parte; la cadena de notificación puede ser el eslabón débil.

Task 14: Comprueba síntomas de suspensión del pool (el incidente de “todo cuelga”)

cr0x@server:~$ zpool status tank | egrep -i "state|suspend|status"
 state: ONLINE
status: One or more devices has been removed by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a degraded state.
action: Online the device using 'zpool online' or replace the device with 'zpool replace'.

Significado: Aquí no está suspendido, pero es donde lo verás. Si el pool está suspendido, las aplicaciones suelen colgar en I/O.
Decisión: Si está suspendido, deja de insistir con reintentos. Estabiliza hardware, considera export/import y prioriza evacuación de datos o failover.

Task 15: Obtén una lista limpia de “qué cambió recientemente” a partir de eventos

cr0x@server:~$ zpool events | egrep "vdev_(add|remove)|config_sync|scrub_start|scrub_finish|resilver_(start|finish)" | tail -n 20
time: 2025-12-25.09:14:03 class: resilver_start
time: 2025-12-25.09:20:11 class: config_sync
time: 2025-12-25.09:37:18 class: resilver_finish
time: 2025-12-25.09:40:00 class: scrub_start

Significado: Puedes ver el ciclo de vida de operaciones: inicio/fin de resilver, config sync, inicio de scrub.
Decisión: Úsalo para explicar causa/efecto en notas de incidente y para detectar “alguien empezó un scrub en horas pico” sin adivinar.

Task 16: Extrae eventos desde una hora conocida mala para líneas temporales de incidente

cr0x@server:~$ zpool events -v | awk '/time: 2025-12-21/{p=1} p{print}'
time: 2025-12-21.00:58:19
eid: 1869
class: ereport.fs.zfs.checksum
pool: tank
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1
zio_err: 52

Significado: Una forma rápida de extraer bloques de eventos relevantes para un postmortem o ticket.
Decisión: Conserva esta salida durante incidentes. Los eventos pueden rotar o ser efímeros según la plataforma y herramientas; tu ticket no debería depender de “lo reproduciremos.”

Tres micro-historias corporativas (errores que puedes evitar)

Micro-historia 1: El incidente causado por una asunción errónea

La empresa operaba un clúster de virtualización mediano sobre mirrors ZFS. Buena elección: reconstrucciones simples y rápidas, dominios de fallo claros.
El runbook on-call decía: “Si un disco muestra errores de checksum, reemplázalo.” No es un mal consejo. Tampoco es completo.

Un martes, empezaron a aparecer errores de checksum en dos hosts—diferentes pools, diferentes discos, mismo modelo de HBA. El on-call cambió un disco en el host A.
Empezó el resilver, luego el host A arrojó más errores de checksum, luego timeouts y finalmente el pool colgó lo suficiente como para disparar watchdogs de guests.
“Lote malo de discos,” dijo alguien, porque esa es la historia que todos han oído antes.

La traza de eventos—ignorada hasta después—mostró algo más específico: ráfagas de errores de I/O y reinicios de enlace que coincidían con una actualización de un módulo del kernel.
Los discos no estaban fallando de forma independiente; el transporte estaba flappeando bajo carga. Reemplazar un disco incrementó la carga (lecturas/escrituras del resilver), empeorando los flaps.

La solución no fue “más discos.” Fue fijar la versión del driver del HBA, ajustar settings de cola y programar resilvers solo después de confirmar la estabilidad del transporte.
Aún reemplazaron un disco eventualmente—porque uno sí tenía errores reales de medio—pero no antes de detener la falla sistémica.

La asunción equivocada: “Errores de checksum significan disco.” A veces sí. A veces significan “todo tu camino I/O es sospechoso.” Los eventos te dicen en qué historia estás.

Micro-historia 2: La optimización que salió mal

Otro equipo amaba los dashboards. Querían menos páginas, menos “falsos positivos” y una experiencia on-call más tranquila. Objetivos respetables.
Decidieron alertar solo en cambios de estado de zpool status: ONLINE→DEGRADED, DEGRADED→FAULTED. No alertaron por eventos como timeouts o ereports de checksum únicos.

El entorno funcionó bien durante meses. Luego un backplane empezó a dejar caer intermitentemente un disco por unos segundos bajo ráfagas de escritura intensas.
ZFS lo marcaba como indisponible brevemente, reintentaba y recuperaba. El pool nunca permaneció degradado el tiempo suficiente para que saltara la alerta de “cambio de estado”.
Mientras tanto, zpool events básicamente gritaba en el vacío con un patrón repetitivo: errores de I/O, retiro de dispositivo, retorno de dispositivo, config sync.

El primer síntoma real notado por humanos no fue una alerta. Fue una base de datos lenta y luego un resilver prolongado cuando el disco finalmente dejó de volver.
Para entonces, el pool había soportado semanas de ciclos de estrés y tenía menos margen del que nadie imaginaba.

Tras el incidente, reintrodujeron alertas para clases específicas de eventos (remociones, ereports de I/O, ráfagas de checksum) con limitación de tasa y correlación.
¿Menos páginas? Sí. Pero no yendo a ciegas. Siendo más listos.

Segunda broma seca: El sistema de monitoreo más silencioso también es el más barato—hasta que calculas el coste del corte.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización financiera operaba ZFS en un par de nodos de almacenamiento. Nada exótico: RAIDZ2 para datasets masivos, SLOG espejado para cargas sync, scrubs regulares y ZED conectado a tickets.
La configuración era tan aburrida que nadie hablaba de ella, que es exactamente lo que quieres del almacenamiento.

Durante un scrub semanal rutinario, ZFS registró un pequeño número de errores de checksum en un disco. Sin errores de datos permanentes. El pool se mantuvo ONLINE.
ZED generó un ticket con el dispositivo by-id, el host y el contexto del scrub. El ticket no era urgente, pero tampoco fue ignorado.

El ingeniero de almacenamiento revisó zpool events -v y vio que los ereports de checksum estaban agrupados en un intervalo de cinco minutos.
Los logs del kernel en ese intervalo mostraron un solo reinicio de enlace en una línea SAS—clásico “tic del transporte”. Reasentaron el cable en la ventana de mantenimiento y volvieron a scrubear.
Sin errores.

Dos meses después, el mismo backplane empezó a fallar más en otra bahía. Esta vez, porque tenían historial,
reconocieron el patrón inmediatamente. Movieron preventivamente discos fuera del enclosure sospechoso antes de que causara un incidente de múltiples discos.

La práctica que salvó el día no fue heroica. Fue: scrubs programados, tickets impulsados por eventos y leer realmente la línea temporal.
Aburrido es una característica.

Errores comunes: síntoma → causa raíz → solución

Esta sección es intencionalmente directa. Estos son modos de fallo que he visto repetir porque la gente “manejó ZFS una vez”
y asumió que eso significaba “entender almacenamiento.”

1) “Pool está degradado, pero el rendimiento está bien” → complacencia → corte sorpresa

• Síntoma: estado DEGRADED durante días; los usuarios no se quejan.
• Causa raíz: Estás operando sin margen de redundancia. La siguiente falla será un corte o pérdida de datos.
• Solución: Reemplaza/restaura la redundancia prontamente. Usa zpool events -v para confirmar que la falla está localizada y no es de transporte antes de reemplazar.

2) “Errores de checksum aleatorios en múltiples discos” → mal diagnosticado como “discos malos” → reemplazos innecesarios

• Síntoma: Errores de checksum en distintos discos, a veces tras reboots o picos de carga.
• Causa raíz: Firmware/driver del HBA, expander/backplane SAS malo, cable marginal, inestabilidad de energía.
• Solución: Correlaciona eventos por marca de tiempo con logs del kernel; busca reinicios/timeouts en el mismo bus. Estabiliza el transporte primero y luego reemplaza discos que aún muestren errores persistentes de medio.

3) “El scrub es lento, debe ser normal” → dispositivo enfermo oculto → resilver interminable

• Síntoma: Scrubs/resilvers a una fracción de la velocidad esperada; a veces “sin ETA”.
• Causa raíz: Un disco está reintentando lecturas, unidades SMR bajo I/O aleatorio sostenido, o un sistema saturado con carga competidora.
• Solución: Observa zpool events -f durante el scrub para errores de I/O; revisa logs del SO por reintentos/timeouts; considera mover cargas pesadas fuera durante el resilver y reemplazar el dispositivo lento/fallido.

4) “Sin alertas, entonces no hay problema” → ZED no está activo → degradación silenciosa

• Síntoma: Alguien descubre problemas manualmente; no se crearon tickets/páginas.
• Causa raíz: ZED deshabilitado, email/handler mal configurado o monitoreo que solo comprueba zpool status diariamente.
• Solución: Activa y valida ZED; prueba un evento controlado (inicio/fin de scrub) y verifica que las alertas lleguen a quienes las verán.

5) “Reemplazar disco inmediatamente” → estrés de rebuild desencadena fallos latentes de transporte → fallos en cascada

• Síntoma: En el momento en que comienza el resilver, otros discos empiezan a dar errores o el mismo disco “falla más.”
• Causa raíz: La reconstrucción incrementa I/O y revela un HBA/backplane/cableado inestable.
• Solución: Antes de reemplazar, busca patrones multi-disco en zpool events. Si sospechas inestabilidad de transporte, estabiliza primero y luego reconstruye.

6) “Se detectaron errores permanentes” → borrar en pánico → empeorar la recuperación

• Síntoma: errors: Permanent errors have been detected... lista archivos.
• Causa raíz: ZFS no pudo reconstruir ciertos bloques desde la redundancia. Borrar el archivo puede destruir valor forense o complicar la recuperación a nivel de aplicación.
• Solución: Haz snapshot del estado actual (si es posible), identifica objetos impactados, restaura desde backup/snapshot cuando proceda y preserva eventos/logs para el análisis de causa raíz.

Listas de verificación / plan paso a paso

Checklist A: Configurar monitoreo para no llevarte sorpresas por eventos zpool

1. Activa ZED y confirma que está en ejecución: systemctl status zfs-zed.service.
2. Verifica al menos una vía de entrega: ingestión por syslog, email o un hook de ticket vía zedlets.
3. Alerta sobre estas clases de eventos (limitadas por tasa): retirada de dispositivo, ereports de I/O, ereports de checksum, scrub terminado con errores, resilver terminado con errores.
4. Incluye la ruta vdev by-id en las alertas. No alerts con /dev/sdX a secas.
5. Almacena un historial corto y rotativo de la salida de zpool events -v en tu sistema de incidentes durante las páginas (copiar/pegar está bien; la perfección es sobrevalorada cuando pierdes un disco).

Checklist B: Cuando un pool pasa a DEGRADED

1. Ejecuta zpool status y registra la salida completa en el ticket.
2. Ejecuta zpool events -v | tail -n 200 y regístralo.
3. Identifica si el problema es de dispositivo único o multi-dispositivo.
4. Correlaciona con logs del kernel por reinicios/timeouts alrededor de la primera marca de tiempo mala.
5. Si son errores de medio de dispositivo único: offline/replace; monitoriza eventos de resilver en vivo.
6. Si es un patrón de transporte: pausa operaciones riesgosas; inspecciona cables/HBA/backplane/energía; luego procede con reemplazos.
7. Tras el resilver, ejecuta un scrub y verifica que scrub_finish tenga scrub_errors: 0.

Checklist C: Después de una reparación sin errores (la parte que la gente salta)

1. Confirma que el pool está ONLINE y que zpool status -x está limpio.
2. Revisa eventos desde el inicio del incidente; asegura que no haya ereports de I/O o checksum recurrentes.
3. Realiza un cambio durable: fijar firmware, registro de reemplazo de cable, ajuste de programación de scrub o arreglo en el ruteo de alertas.
4. Documenta la “primera marca de tiempo mala” y la “última marca de tiempo mala.” Importa para acotar el alcance.

Checklist D: Caza rápida de cuello de botella cuando resilver/scrub es lento

1. Comprueba si ocurren errores durante la operación: zpool events -f durante 5–10 minutos.
2. Revisa logs del SO por reintentos/timeouts en la misma ventana.
3. Verifica si un dispositivo está limitando el vdev (alta latencia): si un disco está enfermo, reemplazarlo suele ser más rápido que “esperar”.
4. Reduce cargas competidoras temporalmente. La reconstrucción es una prueba de estrés; no corras benchmarks durante ella.

Preguntas frecuentes (FAQ)

1) ¿Cuál es la diferencia entre zpool events y zpool status?

zpool status es una instantánea actual más un resumen corto de actividad reciente. zpool events es la línea temporal: qué pasó, cuándo y a menudo qué ruta de dispositivo y clase de error.
En incidentes, la línea temporal gana a las intuiciones.

2) Si veo errores de checksum, ¿siempre reemplazo el disco?

No. Si los errores de checksum están aislados a un disco y persisten, el reemplazo suele ser correcto. Si aparecen en múltiples discos, sospecha primero del transporte (HBA/backplane/cableado) o del firmware.
Eventos más logs del kernel deciden con cuál de los dos estás lidiando.

3) ¿Por qué ZFS reporta errores cuando la aplicación parece bien?

Porque ZFS verifica la integridad de los datos agresivamente y a menudo puede reparar lecturas corruptas desde la redundancia sin surfaciarlo a las aplicaciones.
Ese es el punto. Trata los errores reparados como una señal de advertencia, no como un trofeo.

4) ¿Son “ereport.fs.zfs.*” eventos “serios”?

Son reportes de fallos estructurados. Algunos son informativos; muchos indican problemas reales de I/O. Lo que importa es la frecuencia, si se repiten en el mismo vdev y si coinciden con scrubs/resilvers o cambios de estado.

5) ¿Puedo borrar eventos o reiniciar el historial de eventos?

La retención de eventos depende de la plataforma/herramientas. No confíes en poder “borrarlos” como un panel de contadores.
Operativamente, preserva la salida relevante en el registro del incidente y enfócate en detener la aparición de nuevos eventos.

6) ¿Cómo sé si es un cable/backplane en lugar de un disco?

Busca patrones: múltiples discos en el mismo lane HBA mostrando timeouts/reinicios a la misma hora; dispositivos que desaparecen y reaparecen; errores que pican bajo carga (resilver/scrub) y desaparecen después.
Los logs estilo “Medium Error” en un solo disco apuntan más fuertemente a fallo de medio.

7) ¿Por qué se desplomó el rendimiento cuando falló un disco, aunque el pool siguió online?

La redundancia degradada cambia el comportamiento de lectura/escritura e incrementa trabajo (más reconstrucción de paridad, más reintentos, más scrubbing/resilvering).
Además, un disco fallando puede estar “online” mientras tarda una eternidad en responder, arrastrando todo el vdev.

8) ¿Debo ejecutar scrubs semanal o mensualmente?

Depende de capacidad, carga de trabajo y tolerancia al riesgo. Pools grandes se benefician de verificaciones más frecuentes porque los errores latentes se acumulan.
Lo no negociable es la consistencia: elige un intervalo sostenible y alerta en scrub finish con errores.

9) ¿Cómo uso eventos para evitar falsos positivos en las alertas?

Limita la tasa y correlaciona. Alerta en la primera ocurrencia y luego suprime repeticiones por una ventana a menos que el estado del pool cambie o los errores aumenten.
No alertes solo por cambios de estado; así pasas semanas de flapping desapercibido.

10) ¿Los eventos ayudan con quejas de “ZFS está lento”?

Sí, indirectamente. Los eventos pueden decirte que el sistema está reintentando I/O, experimentando retiradas de dispositivos o scrubs/resilvers—exactamente el tipo de estrés en segundo plano que empeora la latencia.
Para afinamiento de rendimiento puro aún necesitas métricas I/O, pero los eventos a menudo revelan el “por qué ahora”.

Conclusión: siguientes pasos que realmente reducen el riesgo

zpool events no es un comando novedoso. Es la narrativa que tu pila de almacenamiento escribe mientras tú miras dashboards que promedian la verdad.
Léele, automatízalo y úsalo para decidir si tratas con un disco muriendo o un transporte mintiendo.

Haz esto, en este orden:

1. Asegúrate de que ZED esté en ejecución y conectado a humanos (tickets/páginas), no solo a syslog.
2. Añade un paso en el runbook: cada vez que zpool status se vea mal, captura zpool events -v y logs del kernel alrededor de la primera marca de tiempo mala.
3. Alerta por clases de eventos que indican riesgo (I/O, retiradas, errores de scrub/resilver), con limitación de tasa en lugar de silencio.
4. Programa scrubs y trata los “errores reparados” como una señal accionable, no como un FYI.
5. Durante el reemplazo de un disco, observa eventos en vivo. Si los errores se extienden, deja de cambiar partes y arregla el transporte.

El almacenamiento no falla con educación. Falla de maneras que parecen problemas de red, de base de datos o “la nube está lenta hoy”.
ZFS te da una línea temporal. Úsala antes de que tenga que salvarte.