Escenarios de desastre de ZFS: qué falla primero y qué puedes recuperar

enero 19, 2026 • febrero 3, 2026 • Lectura: 26 min • Views: 9

¿Te fue útil?

ZFS no suele fallar con fuegos artificiales. Falla como la batería de un portátil corporativo: despacio, en silencio y justo antes de la demostración.
Un día un pool pasa a DEGRADED, luego un scrub empieza a “encontrar” cosas, y después una importación se queda colgada mientras tu pager
te informa educadamente de que dormir ahora es cosa del pasado.

Esta es una guía de campo para esos momentos. No es un repaso de características. Es un mapa de los acantilados: qué suele romperse primero, cómo confirmarlo
rápido y qué datos puedes todavía rescatar—sin cometer el clásico movimiento de “lo arreglé borrándolo”.

Cómo “muere” ZFS: la pila de fallos

ZFS no es una sola cosa. Es un conjunto de promesas entrelazadas: sumas de verificación, copy-on-write, semántica transaccional, replicación,
caché y una topología de almacenamiento que mezcla “discos” con “intenciones”. Cuando el sistema se estresa, esas promesas fallan en un orden predecible.

1) Lo primero que falla suele ser el entorno, no ZFS

En incidentes reales, la falla inicial suele estar fuera del pool:

Alimentación (caídas de tensión, fuentes defectuosas, suposiciones de doble alimentación)
Controladoras (bugs de firmware del HBA, reinicios de expansores, flaps de enlace SATA)
Memoria (no ECC más mala suerte; ECC más módulo DIMM fallando)
Térmicas (unidades que fallan por calor, estrangulamiento o desconexión)
Humanos (el componente más compatible; funciona con cualquier sistema)

2) Luego I/O: picos de latencia que se vuelven timeouts y finalmente “device removed”

ZFS es conservador. Cuando un vdev empieza a devolver I/O lento o inconsistente, ZFS prefiere dejar de confiar en él. Ahí obtienes un pool
técnicamente online pero prácticamente inutilizable: todo se bloquea en unos pocos miembros moribundos, la lógica de reintentos se acumula y
la aplicación interpreta que “el almacenamiento está caído”.

3) Los metadatos se convierten en el campo de batalla

Los datos de usuario a menudo sobreviven más que la integridad de los metadatos. Si el pool no puede leer las estructuras que describen datasets,
snapshots y punteros de bloques, tus “datos” se convierten en un almacén sin sistema de inventario. Por eso los vdevs especiales y los dispositivos
pequeños para metadatos importan más de lo que la gente piensa.

4) Finalmente, la confianza colapsa: errores de checksum que no pueden autocorregirse

Un solo error de checksum es un aviso. Un patrón de errores de checksum irrecuperables es ZFS diciéndote que no puede encontrar una copia válida.
En mirrors/RAIDZ, eso normalmente significa que perdiste demasiadas réplicas o que la paridad no puede reconstruir porque la superficie de error
es mayor que la redundancia.

Idea parafraseada de Werner Vogels (CTO de Amazon): “Todo falla, todo el tiempo—diseña y opera como si eso fuera normal.” ZFS ayuda,
pero no deroga la física.

Hechos interesantes y contexto histórico (por qué se comporta así)

El comportamiento de ZFS ante desastres tiene más sentido si recuerdas de dónde viene y qué fue diseñado para sobrevivir.

ZFS nació en Sun a principios de los 2000 para arreglar la corrupción silenciosa y el dolor administrativo causado por la separación entre gestor de volúmenes y sistema de archivos.
Copy-on-write fue la clave: ZFS escribe nuevos bloques y luego confirma punteros, evitando estructuras de sistema de archivos “medio escritas” tras fallos.
Las sumas de verificación son de extremo a extremo: ZFS verifica los datos tal como se almacenan, no según lo que diga el disco. Por eso puede detectar “bit rot”.
Los scrubs no eran un lujo; respondían a corrupción real que los RAID clásicos servían como “datos válidos”.
El modelo de pool fue una rebelión: en vez de trocear discos en volúmenes, construyes un pool y asignas datasets. Los administradores dejaron de jugar Tetris.
RAIDZ existe porque los write holes existen: el RAID5/6 clásico puede producir franjas inconsistentes tras pérdida de energía; ZFS intenta evitarlo con escrituras transaccionales.
El diseño ARC/L2ARC refleja el coste de la RAM en la época: ARC en RAM, L2ARC opcional en flash cuando el flash se volvió asequible.
OpenZFS fue el plan de continuidad tras la caída de Sun; hoy es un proyecto multiplataforma con diferentes valores por defecto y flags según el OS.

Qué falla primero: escenarios comunes de desastre

Escenario A: Falla de un solo disco en mirror/RAIDZ

Este es el fallo “normal”. Si tu topología tiene redundancia y el resto del sistema está sano, ZFS hace lo que se espera:
se degrada, sigue sirviendo y exige un reemplazo.

Lo que falla primero aquí suele ser el rendimiento, no la corrección. Un vdev RAIDZ degradado tiene menos paralelismo. Un mirror degradado
está a un disco de un fin de semana largo.

Escenario B: Fallas múltiples durante el resilver

La ventana peligrosa no es “un disco falló”. La ventana peligrosa es “un disco falló y ahora estamos machacando los discos restantes”.
Resilver y scrub son procesos intensivos. Aumentan la carga, el calor y las tasas de error. Unidades marginales se vuelven francamente defectuosas.

Lo que falla primero: segundos discos, a menudo del mismo lote, misma edad, mismo perfil de vibración. Si tu política de compras compra discos idénticos el mismo día, enhorabuena: has fabricado una falla sincronizada.

Escenario C: Reinicios de controladora/HBA causando pérdida transitoria de dispositivos

ZFS reacciona cuando los dispositivos desaparecen. Si una controladora se reinicia y todos los discos desaparecen por un momento, ZFS puede marcarlos como no disponibles.
Dependiendo del momento y del comportamiento del SO, puedes obtener:

Pool en DEGRADED porque una ruta hizo flap
Pool en SUSPENDED porque los errores de I/O superaron umbrales de seguridad
Problemas de importación tras el reinicio porque los nombres de dispositivo cambiaron

Lo que falla primero: tus suposiciones sobre “falla de disco”. Los discos pueden estar bien. El bus no.

Escenario D: Pérdida de energía + caché de escritura mentirosa

ZFS es transaccional, pero aún confía en la pila de almacenamiento para respetar los flushes. Si un disco o controladora confirma escrituras que no persistió,
puedes obtener logs de intención corruptos, metadatos inconsistentes y un pool que importa pero se comporta como si tuviera conmoción cerebral.

Si ejecutas sync=disabled en algo que consideres “importante”, no estás optimizando; estás apostando con el trabajo de otra persona.

Chiste #1: “sync=disabled” es como quitar el cinturón del coche para mejorar la aceleración. Técnicamente cierto, estratégicamente cuestionable.

Escenario E: Falla de vdev especial (metadatos/bloques pequeños)

Los vdevs especiales son poderosos y peligrosos. Si colocas metadatos (y posiblemente bloques pequeños) en un vdev especial, creas una dependencia:
pierdes ese vdev, pierdes el pool. Los mirrors ayudan, pero el radio de explosión es real.

Lo que falla primero: la capacidad del pool para encontrar cualquier cosa. Puede que aún tengas la mayoría de bloques de datos intactos en los vdevs principales,
pero no puedes montar el sistema de archivos sin las estructuras de metadatos.

Escenario F: Pool casi lleno → fragmentación → colapso “repentino” de latencia

Los desastres más aburridos son autoinfligidos. Pools por encima de ~80–90% llenos (según recordsize, carga y topología) se fragmentan.
La asignación se vuelve cara. Las escrituras se amplifican. La latencia se dispara. Las aplicaciones hacen timeout. La gente culpa a “la sobrecarga de ZFS”
mientras el pool intenta asignar bloques como si estuviera empacando un camión de mudanza sin cajas vacías.

Escenario G: Presión de memoria y ARC mal dimensionado en un mundo de vecinos ruidosos

A ZFS le encanta la RAM. Tu base de datos también. Tu plataforma de contenedores también. Cuando pelean, el kernel gana matando a alguien.
ZFS bajo fuerte presión de memoria puede hacer thrashing, expulsando ARC, aumentando I/O a disco, aumentando latencia y presiones. Un bucle de retroalimentación
que acaba con tickets de “almacenamiento lento”.

Escenario H: Pérdida de la clave de cifrado

El cifrado nativo de ZFS es buena ingeniería. También es implacable. Pierde la clave (o la frase + ubicación de la clave), y el pool puede estar perfectamente sano mientras tus datos son perfectamente inaccesibles. Esto no es un bug. Es el trato que aceptaste.

Qué puedes salvar (y qué probablemente no)

Cuando normalmente puedes salvar todo

Fallo de un solo disco en un mirror/RAIDZ con reemplazo inmediato
Errores transitorios de controladora que no corrompieron metadatos (arregla el bus, limpia, scrub)
Errores a nivel de aplicación cuando tienes snapshots (rollback/clone/restore)
Borrados accidentales si existen snapshots y no han sido pruneados

Cuando normalmente puedes salvar algunas cosas

Importaciones de pool en solo lectura que entran en pánico o se cuelgan bajo carga de escritura: a menudo puedes zfs send datasets críticos hacia afuera
Algunos errores de checksum irrecuperables: a veces puedes copiar datasets o ficheros no afectados y luego reconstruir
Daño de metadatos limitado a algunos datasets: otros datasets pueden montarse; prioriza las exportaciones inmediatamente

Cuando mayormente solo salvas registros y lecciones

Vdev especial perdido sin redundancia: el pool generalmente no es recuperable en la práctica
Más miembros de vdev perdidos que permite la redundancia (p. ej., RAIDZ1 con 2 discos fallados)
Claves de cifrado desaparecidas (sin clave, sin datos, sin excepciones)

Chiste #2: Recuperar datos sin backups es como intentar des-tostar pan con un destornillador. Puedes estar muy ocupado y seguir teniendo hambre.

Guion de diagnóstico rápido (primero/segundo/tercero)

El camino más rápido hacia la cordura es separar salud del pool, salud del dispositivo y cuello de botella de rendimiento.
No empieces con heroicidades. Empieza con hechos.

Primero: ¿Es seguro tocar el pool?

Comprueba el estado del pool: zpool status -xv y zpool list. Si ves SUSPENDED, detente y estabiliza.
Confirma que no estás sin espacio: zfs list -o name,used,avail,refer,mountpoint. Pools al 95% generan “caídas misteriosas”.
Busca resilver/scrub activo: la salida de estado te lo dirá; si está en curso durante un incidente, considera pausar cargas competidoras.

Segundo: ¿Es fallo de disco, del bus o del software?

Mira dmesg/journal en busca de reinicios de enlace y timeouts (errores de sentido SATA/SAS, reinicios NVMe).
Comprueba SMART/NVMe para los dispositivos que ZFS señala. Un disco malo es plausible; ocho “discos malos” a la vez suele ser la controladora.
Verifica IDs de dispositivo estables (rutas by-id). Si los nombres cambiaron, las importaciones pueden volverse extrañas.

Tercero: Encuentra el cuello de botella rápidamente

Latencia I/O: zpool iostat -v 1—encuentra el vdev con alta espera y bajo rendimiento.
Presión ARC: si ARC es pequeño y los misses son altos, vas a disco.
Presión de escrituras sync: si tienes un SLOG y está lento o muerto, las cargas síncronas se arrastrarán.

Tareas prácticas: comandos, significado de la salida y decisiones

Estas son las tareas “haz esto a las 03:17”. Cada una incluye qué buscar y qué decisión debe desencadenar. Los comandos asumen Linux con OpenZFS; ajusta para tu plataforma, pero conserva la lógica.

Task 1: Confirmar si algo está realmente roto

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

Significado: ZFS no ve fallos a nivel de pool. Tu caída probablemente sea por encima de ZFS (aplicación, red) o por debajo (hardware causando latencia sin errores).
Decisión: Pasa a la triage de rendimiento (zpool iostat, ARC y métricas del sistema) en vez de reemplazar discos.

Task 2: Leer la historia real del pool, no el resumen reconfortante

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible.  Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 02:11:45 with 3 errors on Thu Dec 26 01:02:10 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     1
            ata-WDC_WD80...-part1   ONLINE       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     0

errors: Permanent errors have been detected in the following files:
/tank/data/db/index/segments_12

Significado: El pool está arriba, pero al menos un bloque no pudo ser reconstruido y un archivo está dañado.
Decisión: Trata esto como un incidente de datos, no solo como hardware. Restaura el archivo desde la replicación de la aplicación o backups; después, vuelve a scrubear y considera reemplazar el disco con errores CKSUM.

Task 3: Identificar si “READ/WRITE/CKSUM” apunta a disco, cableado o memoria

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

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sda     ONLINE       0     0    12
            sdb     ONLINE       0     0     0

Significado: Errores CKSUM en sda sugieren lecturas defectuosas desde esa ruta de dispositivo. Puede ser el disco, el cable/backplane o la memoria durante lecturas (menos común con ECC).
Decisión: Saca SMART y logs del kernel para sda; si aparecen reinicios de enlace, sospecha cableado/HBA. Si SMART muestra sectores reasignados/pending, reemplaza el disco.

Task 4: Comprobar si el pool se está ahogando por capacidad

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,health
NAME   SIZE   ALLOC   FREE  FRAG  HEALTH
tank  43.5T   40.9T  2.6T   73%  ONLINE

Significado: 73% de fragmentación con poco espacio libre es una trampa de rendimiento.
Decisión: Deja de discutir tunables y crea espacio. Borra snapshots antiguos, mueve datos fríos, o expande el pool. Si la carga es intensiva en escrituras aleatorias, considera añadir vdevs, no reemplazar discos por otros más grandes uno a uno.

Task 5: Encontrar el vdev caliente bajo carga

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        40.9T  2.6T     210    980  34.1M  112M
  raidz2-0  40.9T  2.6T     210    980  34.1M  112M
    sda         -      -      35    165  5.6M   19M
    sdb         -      -      36    164  5.5M   19M
    sdc         -      -      34    166  5.7M   18M
    sdd         -      -      35    321  5.5M   37M
    sde         -      -      35      0  5.6M     0
    sdf         -      -      35    164  5.6M   19M

Significado: Un disco (sdd) está recibiendo escrituras desproporcionadas; puede ser distribución normal, reintentos o un problema de ruta.
Decisión: Correlaciona con los contadores de error de zpool status y logs del kernel. Si un disco muestra alta latencia/timeouts, reemplázalo o vuelve a colocarlo.

Task 6: Confirmar si ZFS está limitando por errores (I/O suspendido)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: SUSPENDED
status: One or more devices are faulted in response to persistent errors.
action: Make sure the affected devices are connected, then run 'zpool clear'.
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     FAULTED     75     0     0  too many errors

Significado: ZFS detuvo I/O para prevenir más daño o bloqueos.
Decisión: No hagas “clear and pray” repetidamente. Arregla primero el problema subyacente de dispositivo/ruta (reemplaza disco, arregla HBA/backplane), luego zpool clear y scrub.

Task 7: Verificar identidad del dispositivo para evitar reemplazar el disco equivocado

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'sdc|WDC|SEAGATE' | head
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-WDC_WD80... -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-WDC_WD80... -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 01:10 ata-WDC_WD80... -> ../../sdc

Significado: Puedes mapear nombres lógicos a IDs estables.
Decisión: Usa rutas by-id en reemplazos y documentación. Si tu runbook dice “reemplazar sdc”, actualiza el runbook; miente en cuanto reinicias.

Task 8: Revisar SMART por los marcadores de “está muriendo”

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep 'Reallocated|Pending|Offline_Uncorrectable|CRC|SMART overall'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       8
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Significado: “PASSED” no es carta de libertad. Sectores pending y uncorrectable son problemas reales.
Decisión: Reemplaza la unidad. Si los CRC fueran altos en su lugar, sospecha cableado/backplane primero.

Task 9: Reemplazar un dispositivo fallado de forma segura

cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-WDC_WD80_BAD /dev/disk/by-id/ata-WDC_WD80_NEW
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
scan: resilver in progress since Thu Dec 26 01:22:01 2025
        1.23T scanned at 2.10G/s, 412G issued at 703M/s, 40.9T total
        412G resilvered, 0.98% done, 16:10:12 to go

Significado: Ha empezado el resilver; la estimación de tiempo suele ser ficción optimista.
Decisión: Reduce la carga si puedes. Observa nuevos errores. Si más discos empiezan a fallar durante el resilver, deja de fingir que es un evento de un solo disco y reevalúa el hardware.

Task 10: Confirmar comportamiento del scrub e interpretar contadores de error

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
scan: scrub in progress since Thu Dec 26 02:01:44 2025
        7.88T scanned at 1.05G/s, 1.12T issued at 153M/s, 40.9T total
        0B repaired, 2.74% done, 06:12:10 to go

Significado: El scrub está verificando checksums. “0B repaired” es bueno por ahora; si termina con reparados >0 y sin errores permanentes, la redundancia funcionó.
Decisión: Si el scrub encuentra errores permanentes, identifica archivos afectados y restaura desde snapshots/backup. No ignores “solo unos pocos” errores de checksum.

Task 11: Problemas de montaje—ver qué piensa ZFS que está montado

cr0x@server:~$ zfs list -o name,mounted,mountpoint,canmount
NAME                 MOUNTED  MOUNTPOINT     CANMOUNT
tank                 yes      /tank          on
tank/data             no      /tank/data     on
tank/data/db          no      /tank/data/db  on

Significado: Los datasets están presentes pero no montados. Puede deberse a fallos de dependencia, cifrado bloqueado o conflictos de mountpoint.
Decisión: Revisa el estado de cifrado y errores en zpool status y logs del sistema. Intenta montar explícitamente y captura el error.

Task 12: Triage de cifrado—¿puedes cargar las claves?

cr0x@server:~$ zfs get -H -o name,property,value encryption,keylocation,keystatus tank/data
tank/data	encryption	aes-256-gcm
tank/data	keylocation	file:///root/keys/tank_data.key
tank/data	keystatus	unavailable
cr0x@server:~$ sudo zfs load-key -a
Enter passphrase for 'tank/data': 
cr0x@server:~$ zfs get -H -o name,property,value keystatus tank/data
tank/data	keystatus	available

Significado: El dataset estaba cifrado y bloqueado; ahora está desbloqueado.
Decisión: Si no puedes cargar las claves, detente. No destruyas ni recrees nada. Tu incidente ahora es “gestión de claves”, no “fiabilidad del almacenamiento”.

Task 13: Importar un pool de forma segura tras un fallo (solo lectura primero)

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1234567890123456789
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          raidz2-0  ONLINE
            sda     ONLINE
            sdb     ONLINE
            sdc     ONLINE
            sdd     ONLINE
            sde     ONLINE
            sdf     ONLINE
cr0x@server:~$ sudo zpool import -o readonly=on tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
status: The pool is imported in read-only mode.

Significado: Importaste sin permitir escrituras. Eso reduce el riesgo mientras evalúas.
Decisión: Si sospechas corrupción, mantén en solo lectura y empieza a extraer datasets críticos vía zfs send o copia a nivel de ficheros a un destino seguro.

Task 14: Encontrar qué cambió recientemente (snapshots, holds, clones)

cr0x@server:~$ zfs list -t snapshot -o name,creation -S creation | head
NAME                         CREATION
tank/data@auto-2025-12-26-0100  Thu Dec 26 01:00 2025
tank/data@auto-2025-12-26-0000  Thu Dec 26 00:00 2025
tank/data@auto-2025-12-25-2300  Wed Dec 25 23:00 2025

Significado: Tienes snapshots recientes; bien. Si no, tu yo futuro tendrá una seria conversación contigo.
Decisión: Si el incidente fue “una mala implementación borró cosas”, restaura desde snapshot (clone o rollback). Si el incidente es corrupción, usa snapshots para zfs send a un nuevo pool.

Task 15: Replicar primero los datos más valiosos

cr0x@server:~$ sudo zfs send -v tank/data@auto-2025-12-26-0100 | sudo zfs receive -u rescue/data
send from @auto-2025-12-26-0100 estimated size is 3.12T
total estimated size is 3.12T
TIME        SENT   SNAPSHOT
00:00:10   5.28G   tank/data@auto-2025-12-26-0100

Significado: Estás enviando en streaming un snapshot consistente a un pool/dataset de rescate, no intentando “arreglar in situ”.
Decisión: Si ves errores de send, anota el dataset y ajusta prioridades. A menudo puedes salvar otros datasets aunque uno esté dañado.

Tres micro-historias del mundo corporativo

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana ejecutaba una plataforma de VM sobre ZFS. Dos nodos de almacenamiento, cada uno con un pool RAIDZ2. Había replicación, pero era “best effort”.
La suposición del equipo—nunca escrita, siempre repetida—era que RAIDZ2 significaba “podemos perder dos discos y estar bien”.

Un viernes, un pool pasó a DEGRADED. Se reemplazó un disco. Empezó el resilver. Durante el resilver, un segundo disco empezó a registrar timeouts.
Todos estaban tranquilos: “Todavía estamos dentro de RAIDZ2.” Entonces la controladora se reinició. Todos los discos cayeron por un momento, volvieron y ZFS marcó un tercer
dispositivo como faulted debido a errores acumulados. El pool pasó de “bien” a “SUSPENDED” en un parpadeo.

La suposición errónea no era sobre la aritmética de paridad. Era la idea de que las fallas son independientes y que “perder” un dispositivo es lo mismo que
“un disco físicamente muerto”. En realidad, un HBA o backplane malo puede hacer que múltiples discos parezcan muertos a la vez. A ZFS no le importa por qué el dispositivo dejó
de responder; solo sabe que dejó de hacerlo.

La recuperación no fue heroica. Importaron en solo lectura, empezaron inmediatamente zfs send para los datasets de VM más críticos hacia el otro nodo,
y aceptaron que algunas VMs de baja prioridad serían reconstruidas desde imágenes más tarde. La solución fue aburrida: firmware nuevo en el HBA, mejor disciplina de cableado
y una política que dice “cualquier anomalía multi-disco es bus-primero hasta demostrar lo contrario”.

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

Otra empresa ejecutaba NFS de baja latencia sobre ZFS. Hicieron benchmark y vieron grandes ganancias deshabilitando sync, y lo pusieron en producción.
La justificación sonaba razonable: “La app ya es resiliente y tenemos UPS.”

Meses después, un evento de energía golpeó. No un apagón total—solo una caída de tensión que hizo reiniciar un nodo. El pool se importó. Los servicios arrancaron. Los usuarios notaron
corrupción de archivos extraña: pequeña, aleatoria, no reproducible. El tipo de problema que hace que todos cuestionen la realidad.

Lo que pasó: “sync disabled” permitió al sistema confirmar escrituras antes de que fueran duraderas. El UPS no ayudó porque el modo de fallo no fue tanto “apagado de energía”
como “hardware comportándose de forma impredecible bajo tensión inestable”. ZFS hizo su trabajo dentro del contrato que tenía; el contrato había sido reescrito por un flag de tuning.

La solución fue dolorosa pero directa: restaurar datasets afectados desde snapshots y replicación conocida buena, reactivar sync y añadir un dispositivo SLOG
dimensionado y especificado para escrituras síncronas sostenidas. La lección quedó. Siguen benchmarkeando. Solo que benchmarkean la realidad, no una fantasía.

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

Un proveedor SaaS tenía un pool ZFS que alojaba uploads de clientes y algunos artefactos de build internos. Sus datos no eran “de vida o muerte”, pero eran del tipo
que generan churn cuando desaparecen. Ejecutaban scrubs semanales y replicación de snapshots diaria a un sistema separado. Sin drama, sin diapositivas ejecutivas. Solo mantenimiento calendarizado.

Una semana, el scrub reportó un puñado de errores de checksum que reparó. El ingeniero on-call abrió un ticket de todos modos, porque “reparado” no es lo mismo que “bien”.
SMART mostró una unidad con sectores pending en aumento. El disco se reemplazó en horario laboral. Nadie lo notó.

Dos semanas después, otro disco en el mismo chasis falló de forma grave durante carga máxima. Empezó el resilver. Otro disco empezó a tambalearse. Esta vez,
había una real posibilidad de cruzar los límites de redundancia si las cosas empeoraban.

El equipo no jugó a ver quién aguantaba. Redujeron la carga, pararon temporalmente escrituras no esenciales y confirmaron la frescura de la replicación.
Cuando el pool sobrevivió, perfecto. Si no lo hubiera hecho, ya estaban listos para hacer failover. La “práctica aburrida” no fue solo scrubs; fue tener
un plan para dejar de cavar cuando el hoyo se hizo profundo.

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

1) Síntoma: El pool está ONLINE pero todo es lento

Causa raíz: Pool casi lleno + fragmentación; o un dispositivo lento/defectuoso causando acumulación de colas.
Solución: Revisa zpool list por espacio libre/frag; ejecuta zpool iostat -v 1 para encontrar el dispositivo rezagado; crea espacio y reemplaza/repara el miembro lento.

2) Síntoma: Muchos discos “fallan” a la vez

Causa raíz: Reinicio del HBA, expansor/backplane, problema de alimentación o cableado.
Solución: Inspecciona logs del sistema por reinicios/timeouts de enlace; vuelve a colocar/reemplaza HBA o backplane; no reemplaces discos a lo loco hasta probar que están malos.

3) Síntoma: Aumentan errores CKSUM, SMART parece bien

Causa raíz: Integridad de la ruta (cables), problemas de controladora o corrupción de memoria.
Solución: Revisa contadores UDMA CRC, vuelve a colocar cables, prueba memoria, mueve el disco a otro puerto/controladora y ve si los errores siguen al disco o a la ruta.

4) Síntoma: El scrub encuentra “errores permanentes”

Causa raíz: ZFS no puede reconstruir al menos un bloque desde la redundancia.
Solución: Restaura archivos/datasets afectados desde snapshot/backup/replica; tras restaurar, scrubea de nuevo. Trátalo como un incidente de integridad de datos.

5) Síntoma: La importación se cuelga o tarda muchísimo

Causa raíz: Uno o más dispositivos hacen timeout; lecturas extremadamente lentas durante el replay; churn masivo de metadatos.
Solución: Importa en solo lectura; aisla discos que fallen (SMART/logs); prueba importar en un sistema con HBAs conocidos buenos; prioriza exportar datos críticos.

6) Síntoma: Dataset no monta tras el reboot

Causa raíz: Clave de cifrado no cargada; conflicto de mountpoint; canmount=off; o propiedades de dataset corruptas/bloqueadas.
Solución: Revisa zfs get keystatus, zfs list -o mounted,canmount,mountpoint y arregla claves/propiedades; monta explícitamente y captura errores.

7) Síntoma: El resilver es dolorosamente lento

Causa raíz: Carga concurrente pesada; discos SMR; disco de reemplazo lento; mismatch de ashift; cuello de botella de controladora.
Solución: Reduce la carga, verifica el tipo de disco, revisa zpool iostat para throughput por disco; no “optimices” subiendo tunables a ciegas—encuentra el limitador.

8) Síntoma: Todo murió después de añadir un vdev especial

Causa raíz: El vdev especial no era redundante o no estaba monitorizado; falló y se llevó los metadatos con él.
Solución: Si se fue, las opciones de recuperación son limitadas. Prevénlo la próxima vez: haz mirrors de vdevs especiales, monitorízalos como si tu trabajo dependiera de ello (porque depende), y trátalos como dispositivos de nivel 0.

Listas de verificación / plan paso a paso

Checklist: Cuando un pool pasa a DEGRADED

Captura la salida de zpool status -v para el registro del incidente.
Comprueba si hay resilver/scrub en curso; decide si reducir la carga.
Valida capacidad/fragmentación: zpool list, zfs list.
Mapea nombres de dispositivo a by-id y ranuras físicas antes de tocar el hardware.
Saca salud SMART/NVMe y revisa logs del sistema por reinicios de enlace.
Reemplaza el componente fallido (disco vs cable vs HBA) basado en evidencias.
Monitorea el resilver; vigila nuevos errores en otros miembros.
Scrubea después de que el resilver termine.
Si se reportan errores permanentes: restaura archivos/datasets afectados desde fuentes conocidas buenas.

Checklist: Cuando ves errores permanentes de checksum

Deja de escribir si es posible; considera importar en solo lectura si puedes reiniciar con seguridad.
Identifica archivos afectados desde zpool status -v.
Decide la fuente de restauración: snapshots, replicación, reconstrucción a nivel de aplicación o backups.
Restaura y verifica integridad (chequeos de aplicación, hashes o validación específica de dominio).
Scrubea de nuevo; si los errores persisten, sospecha daño silencioso adicional y escala a migración de pool.

Checklist: Cuando el rendimiento colapsa pero la salud parece bien

Revisa llenado y fragmentación del pool.
Ejecuta zpool iostat -v 1 y encuentra el dispositivo/vdev más lento.
Comprueba presión de sync y salud del SLOG (si se usa).
Revisa presión de memoria y swap; la “lentitud” de almacenamiento puede ser una guerra por RAM.
Busca actividad en background: scrub/resilver, destrucción de snapshots, recepciones de replicación.
Arregla el cuello de botella que puedas probar. No tunées primero.

Preguntas frecuentes

1) ¿Qué falla realmente primero en la mayoría de desastres de ZFS?

El entorno: energía, controladoras, cableado o cambios humanos. ZFS suele ser el mensajero que se niega a mentir al respecto.

2) ¿Los errores de checksum siempre indican un disco muerto?

No. Pueden ser medio del disco, pero también cableado/backplane, problemas de controladora o corrupción de memoria. Usa SMART más logs del kernel para separarlos.

3) ¿Debería scrubbear durante un incidente?

Si el pool está estable pero sospechas corrupción latente, un scrub es diagnóstico y correctivo. Si el hardware está fallando activamente, el scrub puede acelerar el colapso. Estabiliza primero.

4) ¿Es RAIDZ2 “suficientemente seguro” para discos grandes?

Es más seguro que RAIDZ1, pero la seguridad depende del tiempo de reconstrucción, la carga y fallas correlacionadas. Los mirrors se reconstruyen más rápido; RAIDZ ahorra espacio. Elige según tus objetivos de recuperación, no tu hoja de cálculo.

5) ¿Puedo importar un pool en solo lectura para rescatar datos?

Sí, y a menudo deberías. zpool import -o readonly=on reduce el riesgo mientras evalúas y extraes datos.

6) ¿Cuál es el modo de fallo más irrecuperable en ZFS?

Perder claves de cifrado es absoluto. Perder un vdev especial no redundante está cerca. En ambos casos, el pool puede estar “sano” y aun así inutilizable.

7) ¿Agregar un SLOG hace mi pool más seguro?

Puede hacer las escrituras síncronas más rápidas y predecibles. No reemplaza backups, y un SLOG mal especificado puede volverse un problema de rendimiento o fiabilidad.

8) ¿Por qué ZFS se vuelve lento cuando el pool está casi lleno?

ZFS asigna bloques a través del espacio libre; cuando el espacio libre es escaso y fragmentado, la asignación se vuelve cara y la amplificación de escritura aumenta. La solución es más espacio, no más esperanza.

9) ¿Debería usar alguna vez `sync=disabled`?

Solo cuando la pérdida de datos sea aceptable y acordada explícitamente. Para la mayoría de sistemas productivos, es una trampa con un bonito resultado de benchmark.

10) ¿Puedo “clear” errores y seguir adelante?

Puedes limpiar contadores, no la realidad. Si los errores provinieron de un evento transitorio y los scrubs vuelven limpios, bien. Si los errores siguen aumentando, estás enmascarando un fallo activo.

Próximos pasos que puedes hacer esta semana

Si quieres menos desastres ZFS, haz menos magia y más rutina. ZFS recompensa la competencia aburrida.

Programa scrubs y revisa los resultados como si importaran. Importan.
Establece una política de reemplazo basada en tendencias SMART y edad, no solo en fallos.
Migra a nombres de dispositivo estables (by-id) en configuraciones de pool y runbooks.
Prueba importación en solo lectura y restauración de snapshots en un clon no productivo. No esperes al incidente para descubrir que el backup es “teórico”.
Haz de la gestión de espacio una métrica de primera clase: alerta por pool >80–85% y anomalías en crecimiento de snapshots.
Audita vdevs especiales y dispositivos de log: asegura redundancia, monitorización y hardware apropiado.
Escribe el orden de triage (salud del pool → salud del dispositivo/ruta → cuello de botella de rendimiento) y haz que el on-call lo siga.

El objetivo no es nunca ver DEGRADED. El objetivo es verlo temprano, responder con calma y nunca tener que aprender lo que se siente “errores permanentes” en las entrañas.