Fundamentos de recuperación de pools ZFS: pasos para no empeorar las cosas

enero 12, 2026 • febrero 3, 2026 • Lectura: 27 min • Views: 11

¿Te fue útil?

El momento más peligroso en la recuperación de ZFS son los primeros cinco minutos. No porque ZFS sea frágil, sino por los humanos. Estás de guardia, el pool está “UNAVAIL”, los paneles están en rojo y alguien sugiere “simplemente reinícialo”. Así es como conviertes un incidente recuperable en un pasatiempo forense.

Esta es la guía de campo para recuperar un pool ZFS con el mínimo drama: qué comprobar primero, qué comandos ejecutar, cómo leer la salida y las decisiones que tomas según esa salida. Es opinada. Da por sentado la presión de producción. También da por sentado que quieres conservar tu trabajo y tus datos.

Mentalidad de recuperación: dejar de cavar

La recuperación de un pool ZFS se parece menos a “reparar un sistema de archivos” y más a “manejar pruebas en la escena de un accidente”. Las herramientas son poderosas, las estructuras de datos son resilientes y puedes empeorar la situación siendo creativo bajo estrés.

Tres reglas que te mantienen fuera de problemas:

Minimiza las escrituras hasta entender la falla. Las escrituras pueden sobrescribir la metadata que necesitas para recuperar limpiamente.
Prefiere observar antes que actuar. Tus primeros comandos deben ser solo lectura: estado, descubrimiento de importación, logs del kernel.
Cambia una variable a la vez. Si intercambias discos, cambias cables y reescribes rutas de dispositivos todo a la vez, tu línea temporal se vuelve ficción.

Además: no “limpies” etiquetas y particiones hasta haber capturado suficiente estado para revertir tus decisiones. ZFS es indulgente; no es psíquico.

Broma #1: “Solo voy a ejecutar zpool import -f y ver qué pasa” es el equivalente en almacenamiento a “solo voy a mover el yugo del avión y ver qué pasa”.

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

Este es el camino más corto hacia “¿qué está realmente roto?” Está diseñado para encontrar el cuello de botella rápidamente: hardware, topología, metadata o error humano.

Primero: ¿es un problema de visibilidad de dispositivos o de metadata de ZFS?

Revisa los logs del kernel por reinicios de disco/enlace (timeouts SATA, SAS, NVMe).
Comprueba si el SO sigue viendo los dispositivos (rutas by-id, multipath, mapeo de bahías).
Ejecuta el descubrimiento de importación sin importar para ver si ZFS puede leer etiquetas.

Si los dispositivos faltan a nivel del SO, ZFS todavía no puede salvarte. Repara cables, HBAs, expanders, zonificación, multipath y solo entonces vuelve a ZFS.

Segundo: ¿cuál es el estado del pool y qué tipo de redundancia tienes?

Mirror vs RAIDZ cambia el riesgo. Un mirror degradado suele ser rutinario. Un RAIDZ degradado con múltiples fallos puede ser un baile cuidadoso.
Busca “demasiados errores” frente a “dispositivo eliminado”. Son modos de fallo diferentes con acciones distintas.

Tercero: ¿estás lidiando con corrupción o solo con “no se puede ensamblar el pool”?

Signos de corrupción: errores de checksum, “permanent errors”, errores de lectura en archivos concretos, reinicios repetidos de resilver.
Signos de ensamblaje: el pool no se importa, faltan vdevs de nivel superior, cachefile obsoleto, dispositivos renombrados, cambiado el orden del HBA.

Una vez que puedes etiquetar el incidente como “visibilidad”, “ensamblaje”, “degradado pero importable” o “corrupción”, dejas de aletear y empiezas a ejecutar.

Hechos interesantes y contexto histórico (resumen)

ZFS se originó en Sun Microsystems a mediados de los 2000 con el objetivo de integridad de datos de extremo a extremo, no solo funciones de comodidad.
El modelo “copy-on-write” significa que ZFS normalmente no sobrescribe metadata en vivo en su lugar, por eso muchos modos de fallo son recuperables si evitas escrituras adicionales.
RAIDZ fue la respuesta de ZFS al clásico “RAID5 write hole”, apoyándose en semántica transaccional en lugar de trucos de batería del controlador.
ZFS suma checksums a datos y metadata (no opcional para metadata), por eso “checksum error” suele indicar corrupción real, no una advertencia cosmética.
OpenZFS se convirtió en un esfuerzo multiplataforma al salir ZFS de sistemas derivados de Solaris; hoy los comportamientos varían ligeramente entre plataformas y versiones.
La propiedad ashift existe porque los tamaños de sector físicos y las mentiras de los discos importan; el desalineamiento puede arruinar silenciosamente el rendimiento y a veces la previsibilidad de recuperación.
Las etiquetas de pool existen en varios lugares en cada vdev, por eso el “daño en etiquetas” suele ser recuperable a menos que algo siga reescribiendo lo incorrecto.
Los scrubs no siempre fueron “operación estándar”. Muchas organizaciones empezaron a tratarlos como rutina después de que las grandes capacidades de disco hicieran comunes los errores de sectores latentes.
Los special vdev y L2ARC hicieron los pools más rápidos pero también añadieron nuevas formas de dañarlos si tratas dispositivos de caché como prescindibles sin entender su rol.

Flujo de triage: confirmar, aislar, preservar

Si tu pool acaba de fallar, no empieces con “reparar”. Empieza por confirmar (qué es cierto), luego aislar (detener el daño), luego preservar (capturar el estado para poder razonar después).

Confirmar: ¿qué cambió exactamente?

La mayoría de las interrupciones de ZFS no son corrupciones místicas. Son mundanas: un disco se cayó, un HBA se reinició, un cable se soltó durante “mantenimiento”, un alias de multipath cambió, una actualización de firmware reordenó dispositivos. El pool está bien; tus suposiciones no.

Aislar: reducir el ruido y los efectos secundarios

Si las aplicaciones están martillando un pool degradado, pausalas o limita su tasa. Hacer resilver bajo carga de escritura es posible, pero es más lento y arriesgado.
Si el pool está fluctuando (dispositivos online/offline), detén la fluctuación: arregla la capa de enlace primero.
Si te tienta ejecutar comandos de “limpieza”, pausa y toma snapshots/exporta solo cuando sea seguro.

Preservar: captura información que desearás tener

Recopila el estado antes de cambiar nada: zpool status, salida de zpool import, lsblk y mapeos by-id, y los logs del kernel. Así evitas el clásico “reemplazamos el disco equivocado”.

Tareas prácticas (comandos + significado de la salida + decisiones)

Estas son tareas operativas reales. Cada una incluye: comando, salida de ejemplo, qué significa y la decisión que tomas. Ajusta nombres de pool e IDs de dispositivo a tu entorno.

Task 1: Check current pool health (if imported)

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

Significado: ZFS cree que todo está bien. Si sigues viendo errores en aplicaciones, el problema puede estar a un nivel superior (NFS/SMB, permisos, errores de la aplicación) o inferior (I/O intermitente aún no surfaced).

Decisión: Si el pool está sano, no ejecutes comandos de recuperación “por si acaso”. Pasa a logs y síntomas de la aplicación.

Task 2: Inspect a degraded pool and identify the failing vdev

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
  scan: scrub repaired 0B in 0 days 00:18:22 with 2 errors on Fri Dec 20 02:19:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LM1T9-0  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LM1T9-1  ONLINE       0     0     2
            ata-SAMSUNG_MZ7LM1T9-2  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        /tank/projects/db/wal/00000001000000A9000000FF

Significado: El pool es importable pero tiene errores de checksum y un archivo específico está afectado. Esto no es “falta un disco”. Es “ZFS no pudo reparar datos desde la redundancia” o “la redundancia devolvió datos inconsistentes”.

Decisión: Identifica si el archivo puede reconstruirse (WAL de base de datos, artefactos derivados) o debe restaurarse. No empieces a tirar discos solo porque viste “2” en CKSUM; correlaciona con SMART y logs de errores primero.

Task 3: Discover importable pools without importing

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

        tank                        ONLINE
          mirror-0                  ONLINE
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123  ONLINE
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456  ONLINE

Significado: ZFS ve las etiquetas del pool y puede ensamblar la topología. Buen signo. Si el pool aparece como “no encontrado” aquí, probablemente tienes problemas de visibilidad de dispositivos, daño en etiquetas o estás en el host equivocado.

Decisión: Si la importación es posible, importa en modo solo lectura primero cuando la situación sea ambigua.

Task 4: Attempt a cautious read-only import

cr0x@server:~$ sudo zpool import -o readonly=on -N tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: none requested
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    ONLINE       0     0     0

Significado: Importado sin montar datasets (-N) y en modo solo lectura. Es un estado excelente para inspección: puedes listar datasets y propiedades sin escribir nueva metadata.

Decisión: Si necesitas copiar datos, puedes montar datasets específicos en solo lectura. Si planeas reparaciones, cambia a lectura-escritura solo cuando estés seguro de que la capa de dispositivos es estable.

Task 5: Check OS-level device presence and stable identifiers

cr0x@server:~$ ls -l /dev/disk/by-id/ | head
total 0
lrwxrwxrwx 1 root root  9 Dec 26 03:10 ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 03:10 ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 03:10 nvme-SAMSUNG_MZVL21T0HCLR-00B00_S6XYZ123 -> ../../nvme0n1

Significado: Existen enlaces by-id. Esto importa porque el orden /dev/sdX no es una promesa; es una sugerencia que cambia cuando pestañeas.

Decisión: Si el pool se construyó con rutas /dev/sdX, planifica una migración controlada a by-id en horarios normales. Durante una recuperación, mapea qué disco físico es cuál antes de reemplazar nada.

Task 6: Read the kernel’s opinion about your storage (timeouts, resets)

cr0x@server:~$ sudo dmesg -T | egrep -i "zfs|sd[a-z]|ata|nvme|sas|reset|timeout|I/O error" | tail -20
[Thu Dec 26 03:01:22 2025] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Thu Dec 26 03:01:22 2025] ata6.00: failed command: READ FPDMA QUEUED
[Thu Dec 26 03:01:22 2025] blk_update_request: I/O error, dev sdc, sector 1219024896 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 03:01:23 2025] ata6: hard resetting link
[Thu Dec 26 03:01:29 2025] ata6: link is slow to respond, please be patient (ready=0)
[Thu Dec 26 03:01:35 2025] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Thu Dec 26 03:01:35 2025] sd 6:0:0:0: [sdc] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Thu Dec 26 03:01:35 2025] zfs: vdev state changed, pool_guid=10293847566554433211

Significado: Esto es flapping clásico: reinicio de enlace, fallos de lectura y ZFS notando cambios de estado en vdev. ZFS puede recuperarse de problemas transitorios, pero reinicios repetidos durante un resilver pueden alargar mucho el incidente.

Decisión: Repara la capa física antes de hacer acciones ZFS que dependan de lecturas sostenidas (scrub/resilver). Cambia cable, mueve puerto, revisa firmware del HBA, comprueba el expander.

Task 7: Check SMART/NVMe health to confirm a drive is actually sick

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Model|Serial|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count|SMART overall"
Device Model:     WDC WD80EFAX-68LHPN0
Serial Number:    WD-DEF456
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   095   095   140    Pre-fail  Always       -       0
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       -       12

Significado: “PASSED” no es absolución. Sectores pendientes y no corregibles indican que el disco tiene áreas ilegibles. Los errores CRC sugieren problema de cableado/backplane también.

Decisión: Si pending/uncorrectable son no cero y están creciendo, reemplaza el disco. Si los errores CRC crecen sin otras señales, sospecha primero de cableado/backplane/HBA.

Task 8: Find which device corresponds to which bay (enclosure mapping)

cr0x@server:~$ sudo lsblk -o NAME,SIZE,SERIAL,MODEL,HCTL,WWN
NAME   SIZE SERIAL    MODEL            HCTL       WWN
sdb    7.3T WD-ABC123 WDC WD80EFAX-68L  6:0:0:0   0x50014ee2b1234567
sdc    7.3T WD-DEF456 WDC WD80EFAX-68L  6:0:1:0   0x50014ee2b7654321
nvme0n1 1.8T S6XYZ123 SAMSUNG MZVL21T0  -         0x002538b111223344

Significado: Estás construyendo un mapeo desde nombres lógicos a dispositivos físicos. Esto te salva de reemplazar el disco equivocado—la forma más cara de cardio.

Decisión: Antes de cualquier reemplazo, registra seriales y ubicaciones de ranura (desde las herramientas del chasis o inventario). Si no puedes mapearlo, detente y averígualo.

Task 9: Clear transient errors only after the underlying cause is fixed

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

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    ONLINE       0     0     0

Significado: Los contadores se reinician. Esto no “arregla” nada; solo te da una pizarra limpia para monitorear tras la remediación.

Decisión: Usa zpool clear después de reparar el cableado o reemplazar un disco y quieres confirmar que el problema no vuelve.

Task 10: Replace a failed disk in a mirror (clean and boring)

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
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    FAULTED      0     0     0  too many errors

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ata-WDC_WD80EFAX-68LHPN0_WD-NEW999
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
  scan: resilver in progress since Thu Dec 26 03:22:01 2025
        1.21T scanned at 1.18G/s, 312G issued at 305M/s, 7.30T total
        312G resilvered, 4.17% done, 06:35:11 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      DEGRADED     0     0     0
          mirror-0                                DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-NEW999    ONLINE       0     0     0  (resilvering)

Significado: El reemplazo comenzó y el resilver está en marcha. Si la tasa de resilver es extremadamente baja, sospecha de errores I/O en curso, discos SMR bajo carga o carga competitiva.

Decisión: Monitorea la estabilidad del resilver. Si el disco antiguo sigue siendo legible de forma intermitente, mantenlo conectado hasta que termine el resilver—a menos que esté bloqueando el bus activamente.

Task 11: Identify what’s preventing import (missing device vs wrong hostid)

cr0x@server:~$ sudo zpool import tank
cannot import 'tank': pool may be in use from other system, it was last accessed by server-a (hostid=0x12ab34cd) on Thu Dec 26 01:50:20 2025
use '-f' to import anyway

Significado: ZFS cree que otro host tenía el pool. Esto puede ser legítimo (almacenamiento compartido, cluster, SAN) o simplemente un hostid obsoleto después de mover discos.

Decisión: Confirma que el pool no está importado activamente en otro lugar. Si estás seguro, importa con fuerza, pero trátalo como un evento operativo que vale la pena documentar y auditar.

Task 12: Force import safely, ideally read-only first

cr0x@server:~$ sudo zpool import -f -o readonly=on -N tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    ONLINE       0     0     0

Significado: El pool se importa y está estable en modo solo lectura. Es un punto de preparación seguro para verificar datos antes de permitir escrituras.

Decisión: Si el incidente involucró reinicios inesperados o problemas del HBA, mantenlo en solo lectura hasta confirmar la estabilidad de los dispositivos y capturar datos irrecuperables.

Task 13: Import using an alternate root (for recovery environments)

cr0x@server:~$ sudo zpool import -R /mnt -N tank
cr0x@server:~$ sudo zfs mount -a
cr0x@server:~$ mount | grep tank
tank/home on /mnt/home type zfs (rw,xattr,noacl)

Significado: -R establece una raíz de mountpoint alternativa. Esto es útil en shells de rescate, hosts de recuperación o cuando no quieres chocar con puntos de montaje de producción.

Decisión: Usa esto al recuperar desde un SO en vivo o migrar discos a un host temporal para inspección.

Task 14: Verify snapshots exist before you attempt “repairs”

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -S creation tank | head
NAME                              CREATION
tank@autosnap_2025-12-26_0200      Thu Dec 26 02:00 2025
tank@autosnap_2025-12-26_0100      Thu Dec 26 01:00 2025
tank@autosnap_2025-12-26_0000      Thu Dec 26 00:00 2025

Significado: Las snapshots ofrecen un punto lógico de recuperación incluso cuando el hardware es inestable. También te dan confianza para revertir datasets si hace falta (con cuidado).

Decisión: Si faltan snapshots y estás considerando acciones destructivas, pausa. Tus opciones de recuperación se han estrechado.

Task 15: Run a scrub when the pool is stable, then interpret results

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 03:40:11 2025
        2.88T scanned at 1.02G/s, 1.44T issued at 512M/s, 7.30T total
        0B repaired, 19.72% done, 03:05:19 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-ABC123    ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_WD-DEF456    ONLINE       0     0     0

Significado: El scrub lee todo y verifica checksums. “Repaired” indica que ZFS corrigió datos malos usando redundancia. Si las reparaciones siguen ocurriendo, tienes un problema persistente (disco, cableado, memoria, controlador).

Decisión: Si el scrub completa con errores, trátalo como un incidente real, no como una advertencia. Recopila zpool status -v y decide si restaurar archivos impactados o reemplazar hardware.

Task 16: List and evaluate permanent errors

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
errors: Permanent errors have been detected in the following files:
        /tank/projects/db/base/16384/2609
        /tank/projects/db/base/16384/2610

Significado: ZFS te está diciendo: “Sé qué archivos están mal”. Eso es un regalo. Para bases de datos e imágenes de VM, esas rutas importan.

Decisión: Si son archivos críticos: restaura desde backup/snapshot de replicación, o reconstruye el dataset/aplicación. No asumas que otro scrub arreglará mágicamente “permanent errors”.

Task 17: Check whether you’re dealing with insufficient replicas (a.k.a. you lost redundancy)

cr0x@server:~$ sudo zpool status -v vault
  pool: vault
 state: DEGRADED
status: One or more devices could not be used because the label is missing or invalid.
action: Replace the device using 'zpool replace'.
config:

        NAME                        STATE     READ WRITE CKSUM
        vault                       DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-ST12000NM0008_A1    ONLINE       0     0     0
            ata-ST12000NM0008_A2    ONLINE       0     0     0
            15553461652766218490    UNAVAIL      0     0     0  was /dev/disk/by-id/ata-ST12000NM0008_A3
            ata-ST12000NM0008_A4    ONLINE       0     0     0
            ata-ST12000NM0008_A5    ONLINE       0     0     0
            ata-ST12000NM0008_A6    ONLINE       0     0     0

Significado: ZFS recuerda un vdev por GUID y te está indicando la antigua ruta. Esto suele ser “disco faltante” o “disco reenumerado pero etiqueta perdida”.

Decisión: Encuentra el disco faltante (por serial, bahía, ruta HBA). Si está presente pero la etiqueta falta, trata eso como sospechoso—algo la sobreescribió. No ejecutes zpool replace hasta saber qué disco físico corresponde a ese GUID.

Task 18: Export a pool cleanly before moving disks to another host

cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import
no pools available to import

Significado: Export limpia y cierra el pool de forma ordenada. Cuando mueves discos entre hosts, esto reduce la fricción de “pool may be in use” y baja el riesgo de estado obsoleto.

Decisión: Si la máquina está lo bastante estable para exportar, hazlo. Si no, planifica una importación en solo lectura en el host de recuperación y documenta por qué.

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

Esta es la parte donde te salvo de tu yo futuro. No son teóricos. Son cosas que la gente hace a las 03:00 mientras Slack grita.

1) Pool no se importa después de “un simple reinicio”

Síntomas: zpool import muestra el pool, pero la importación se queja de “in use from other system” o se queda colgada.
Causa raíz: hostid obsoleto, el pool no se exportó limpliamente, o dispositivos están fluctuando causando que la importación se estanque.
Solución: Verifica que ningún otro host lo tenga importado. Haz una importación forzada en solo lectura (-f -o readonly=on -N) para inspeccionar. Repara la capa de dispositivos antes de permitir escrituras.

2) Aparecen “checksum errors” y alguien reemplaza el disco de inmediato

Síntomas: CKSUM no cero en un vdev; pool degradado; scrub informa errores.
Causa raíz: Podría ser medio del disco, pero también RAM, HBA/backplane, cable SAS defectuoso o bugs de firmware. Reemplazar el disco puede no arreglarlo y añadir estrés durante el resilver.
Solución: Correlaciona: estadísticas SMART, dmesg, contadores de error en múltiples discos y si los errores “se mueven” con un cable/puerto. Reemplaza hardware basado en evidencia, no en intuiciones.

3) El resilver está “atascado” a baja velocidad

Síntomas: zpool status muestra resilver en progreso con horas/días restantes; el rendimiento colapsa.
Causa raíz: Comportamiento SMR bajo escrituras aleatorias, reintentos de lectura por medios marginales, pool ocupado con escrituras, o un dispositivo lento en RAIDZ que arrastra el vdev.
Solución: Reduce la carga, verifica errores I/O en logs, considera parar escrituras pesadas temporalmente y asegura que el disco de reemplazo no sea un desajuste de rendimiento. Si ves reinicios repetidos, arregla cableado/HBA primero.

4) Pool está UNAVAIL tras cambios de “optimización”

Síntomas: Un special vdev, SLOG o dispositivo de metadata falla; el pool no monta datasets; picos de latencia extraños antes de la falla.
Causa raíz: Tratar dispositivos “rápidos” como opcionales cuando estaban configurados como requeridos (special vdev no es como L2ARC). O sobrecargarlos por mal dimensionamiento.
Solución: Reemplaza el dispositivo failed del special vdev como harías con un disco crítico. Diseña special vdevs con redundancia. No añadas uno a menos que estés dispuesto a operarlo.

5) Alguien ejecuta `zpool labelclear` en el disco equivocado

Síntomas: Un vdev previamente visible pasa a “missing”, el pool se degrada más y la salida de import cambia de formas confusas.
Causa raíz: Identificación incorrecta de discos físicos, confiar en /dev/sdX o saltarse el paso de mapeo serial-a-bahía.
Solución: Para. Captura la salida actual de zpool import. Reconstruye el mapeo usando seriales, WWN y herramientas del chasis. Solo borra etiquetas cuando estés absolutamente seguro de que el disco no forma parte de ningún pool necesario.

6) Los scrubs “reparan” cada semana de forma recurrente

Síntomas: Los scrubs reparan pequeñas cantidades repetidamente; los errores de checksum rotan entre discos; ningún disco es consistentemente culpable.
Causa raíz: A menudo no es el disco: RAM inestable (especialmente sin ECC), problemas del HBA, cableado, backplane o inestabilidad de alimentación.
Solución: Trátalo como un problema de integridad de plataforma. Ejecuta pruebas de memoria en mantenimiento, revisa logs de ECC, actualiza firmware y valida cableado/backplane. Reemplazar discos al azar es solo negación cara.

Listas de comprobación / plan paso a paso

Checklist A: Cuando un pool está degradado pero online

Ejecuta zpool status -v. Identifica si los errores son READ/WRITE/CKSUM y si existen “permanent errors”.
Revisa dmesg por reinicios/timeouts alrededor del mismo tiempo.
Comprueba SMART/NVMe de los dispositivos implicados.
Mapea dispositivos por serial/WWN a bahías físicas.
Si un disco está claramente fallando: reemplázalo y monitoriza el resilver.
Tras el resilver: haz un scrub del pool. Confirma cero errores.
Sólo entonces: limpia contadores (zpool clear) y devuelve la carga normal.

Checklist B: When a pool won’t import

Ejecuta zpool import (sin argumentos) y guarda la salida.
Confirma que el SO ve todos los dispositivos esperados (ls -l /dev/disk/by-id/, lsblk).
Revisa logs del kernel por reinicios/timeouts de enlace.
Si “in use from other system”: verifica que ningún otro host lo tenga importado; luego intenta importación forzada en solo lectura: zpool import -f -o readonly=on -N POOL.
Si faltan dispositivos: repara la ruta de hardware primero (cables/HBA/chasis), luego vuelve a ejecutar el descubrimiento de importación.
Si la importación tiene éxito en solo lectura: monta selectivamente y copia datos irreemplazables antes de intentar cualquier recuperación con escritura.

Checklist C: When you suspect corruption

Importa en solo lectura y sin montar (-o readonly=on -N) si es posible.
Ejecuta zpool status -v e identifica rutas con permanent errors.
Decide la respuesta a nivel de archivo: restaurar/reconstruir/eliminar artefactos derivados.
Haz scrub solo cuando los dispositivos sean estables.
Si la corrupción reaparece: investiga RAM, HBA, firmware, alimentación y cableado. ZFS reporta síntomas; tu plataforma suministra la enfermedad.

Tres micro-historias del mundo corporativo

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

Tenían un servidor de almacenamiento con doce discos en RAIDZ2, un par de SSDs espejo para el arranque y una hoja de cálculo ordenada que mapeaba bahías a seriales. La hoja era “bastante precisa”, lo que es como decir que un paracaídas está “más o menos plegado”.

Un disco empezó a dar timeouts. El ingeniero on-call vio /dev/sdj acumulando errores y sacó el “disco en la bahía 10”, porque eso decía el mapeo del trimestre pasado. El pool empeoró inmediatamente. Ahora faltaban dos miembros de un vdev RAIDZ2: el disco realmente fallido y el disco perfectamente sano que se había retirado.

Lo inquietante fue lo normal que se veía al principio. ZFS no gritó de una forma nueva. Simplemente pasó de “degradado pero disponible” a “import falla intermitentemente” porque los discos restantes estaban bajo una carga masiva de reconstrucción y el enlace originalmente defectuoso seguía flapping.

La recuperación llevó más tiempo del necesario porque pasaron horas debatiendo comandos de ZFS. La solución fue aburrida: volver a asentar el disco sospechoso original, reconstruir correctamente el mapeo bahía-serial desde datos del chasis, y luego reemplazar el serial que realmente fallaba. Tras eso, el resilver completó y el pool volvió limpio.

Acción postmortem: prohibir el uso de /dev/sdX en procedimientos operativos y exigir confirmación por serial antes de sacar un disco. No hizo a nadie sentirse inteligente. Hizo que el siguiente incidente fuera sobrevivible.

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

Un equipo quería operaciones de metadata más rápidas para millones de archivos pequeños. Añadieron un special vdev sobre un par de SSDs rápidos. Funcionó. La latencia bajó, los recorridos de directorio quedaron ágiles y todos disfrutaron el subidón de “arreglamos el almacenamiento”.

Meses después, uno de los SSDs empezó a fallar. No catastróficamente—solo lo suficiente para desaparecer intermitentemente bajo carga. El pool no simplemente se degradó como un mirror normal. La carga intensiva en metadata hizo del special vdev el centro del universo, así que cada contratiempo se convirtió en timeouts de aplicación.

Durante el incidente alguien sugirió, “Si es solo caché, ¿podemos desacoplarla?” Ahí residía el malentendido: un special vdev no es una caché. Puede ser un almacenamiento requerido para metadata (y opcionalmente bloques pequeños). Perderlo puede dejar inservible el pool.

La recuperación fue directa pero tensa: estabilizar la ruta del dispositivo (resultó ser un conector marginal del backplane), reemplazar el SSD malo y resilver el espejo del special vdev. Tras eso, el pool volvió a normalidad en rendimiento y estabilidad.

Lección: si añades un componente de optimización que puede tumbar todo el pool, no es una optimización. Es una nueva capa de infraestructura crítica. Trátala como producción, porque lo es.

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

Un equipo empresarial ejecutaba scrubs semanales, pruebas de restauración mensuales y mantenía una costumbre casi anticuada: tras cualquier cambio de hardware capturaban zpool status, zpool get all para propiedades clave, y un inventario de dispositivos con seriales y WWN. Era papeleo. Nadie se jactaba.

Una tarde, una estantería de almacenamiento se reinició inesperadamente. El SO volvió con distinto orden de enumeración y un camino no regresó. El pool no se importó automáticamente. El canal de incidentes empezó a formarse, como lo hace, como nubes de tormenta sobre un picnic.

En lugar de improvisar, siguieron el playbook. Compararon el inventario by-id actual con la última captura registrada, identificaron exactamente qué serial faltaba y lo correlacionaron con logs del chasis. No era un disco muerto—era una ruta SAS que no volvió a iniciar sesión tras el reinicio del estante.

Arreglaron la ruta, volvieron a ejecutar zpool import, importaron en solo lectura para validar y luego importaron normalmente. Sin flags “force”, sin borrar etiquetas, sin magia. El outage fue corto porque el equipo pasó años invirtiendo en ser aburrido.

Broma #2: El heroísmo en almacenamiento que mejor funciona es tan aburrido que nadie lo nota—como un extintor que nunca se usa.

Una cita para tu canal de incidentes

Werner Vogels (idea parafraseada): Everything fails all the time; design and operate assuming failure is normal.

Decisiones que importan (y por qué)

La importación en solo lectura es tu válvula de alivio de presión

Cuando no estás seguro de si los dispositivos son estables, la importación en solo lectura te permite inspeccionar datasets, validar metadata y copiar datos sin escribir. No es una cura; es una postura diagnóstica más segura.

El scrub no es primeros auxilios; es un escáner completo

Un scrub es pesado. Toca todo. En un pool con un disco marginal o un HBA inestable, scrubbing puede convertir “más o menos bien” en “ahora descubrimos cada sector débil a la vez”. Ese descubrimiento es útil, pero no cuando la capa de transporte está en llamas.

La velocidad de resilver es una señal de salud, no una métrica de confort

Los resilvers lentos ocurren por razones inocentes (pool ocupado, comportamiento SMR). También ocurren porque el sistema está haciendo reintentos infinitos en lecturas. Vigila reinicios y errores I/O en logs; ahí vive la verdad.

Preguntas frecuentes

1) ¿Debo reiniciar un servidor ZFS cuando el pool está degradado?

No como primer movimiento. Reiniciar puede reordenar dispositivos, perder estado transitorio y hacer que un enlace fluctante parezca un disco faltante. Estabiliza hardware y captura salidas primero.

2) ¿Cuándo es apropiado `zpool import -f`?

Cuando has confirmado que el pool no está importado en otro lugar y el estado “in use” es obsoleto (migración de host, crash). Prefiere -o readonly=on -N junto a -f para la primera importación si tienes dudas.

3) Si SMART dice “PASSED”, ¿el disco aún puede estar malo?

Sí. “PASSED” suele ser una comprobación por umbral. Sectores pendientes, no corregibles y CRC en crecimiento son señales operativas independientemente del resultado global.

4) ¿Qué significan realmente los errores de checksum?

ZFS leyó datos, calculó su checksum y no coincidió con lo almacenado. Los datos malos pueden venir del medio del disco, un cable, un controlador, la RAM o incluso firmware. Trátalo como evidencia y correlaciónalo.

5) ¿Es un scrub lo mismo que un resilver?

No. Scrub es verificación proactiva de todos los datos. Resilver es la reconstrucción sobre un reemplazo o dispositivo que vuelve. Ambos hacen lecturas intensivas; resilver además escribe.

6) ¿Puedo simplemente desacoplar un dispositivo “cache” que falle para recuperar el pool?

Depende de qué sea. L2ARC típicamente se puede quitar sin perder integridad. Un dispositivo SLOG normalmente puede eliminarse con consideraciones. Un special vdev puede ser requerido—no lo trates como caché.

7) ¿Por qué ZFS muestra un ID numérico largo en vez de un nombre de dispositivo?

Ese es el GUID del vdev. ZFS lo usa para rastrear miembros aun si las rutas de dispositivo cambian. Es también una pista de que ZFS recuerda algo que el SO no presenta ahora mismo.

8) ¿Cuál es la forma más segura de mover un pool a otra máquina para recuperación?

Exporta el pool limpiamente si puedes, mueve discos, luego importa en solo lectura con una raíz alternativa (-o readonly=on -R /mnt -N) para inspeccionar antes de comprometer escrituras.

9) Si el pool está degradado, ¿debo ejecutar `zpool clear` para “arreglarlo”?

No. zpool clear reinicia contadores de error. Es útil después de arreglar la causa subyacente para confirmar si los errores vuelven. No repara datos.

10) ¿Cómo decido entre “reemplazar disco” y “arreglar cableado”?

Mira la evidencia: errores CRC y reinicios de enlace sugieren transporte. Sectores pending/uncorrectable sugieren medio. Si múltiples discos en la misma ruta HBA muestran problemas, sospecha el componente compartido.

Conclusión: siguientes pasos que realmente puedes hacer

Si no recuerdas nada más: estabiliza la capa de dispositivos, importa en solo lectura cuando no estés seguro y nunca reemplaces un disco que no puedas identificar positivamente. ZFS está diseñado para sobrevivir fallos de hardware. Es menos tolerante a la improvisación.

Pasos prácticos para tu entorno:

Escribe una página con el runbook on-call usando el “Guion de diagnóstico rápido” y las listas de comprobación arriba.
Asegura que cada pool use rutas de dispositivo estables (by-id/WWN) y documenta cómo mapear seriales a bahías.
Programa scrubs y alerta sobre nuevos errores de checksum, no solo cambios en el estado del pool.
Prueba restauraciones. No en teoría. Con datos reales. El día que lo necesites no es el día para descubrir que tus backups son arte performático.
Audita cualquier vdev de “optimización” (special, SLOG) y asegúrate de que sean redundantes y monitoreados como componentes de primera clase.