Recuperación ZFS: ¿El pool no se importa? Ruta calmada y repetible de solución

La mentalidad: preservar evidencia, reducir escrituras

Cuando un pool no se importa, estás en una situación de forense disfrazada de incidente. Tus objetivos son:

• No empeorar la situación. Reduce las escrituras en los discos afectados hasta que entiendas qué pasó.
• Capturar el estado. Guarda la salida de los comandos. Copia registros. Anota la línea de tiempo.
• Hacer un cambio a la vez. Si activas múltiples flags y “funciona”, no sabrás qué cambio importó ni qué riesgo aceptaste.

Además: trata las opciones “force” como una motosierra. Herramienta útil, pero no la malabarees en la sala de servidores.

Una cita de operaciones para pegar en un sticky: “La esperanza no es una estrategia.” — Gene Kranz

Broma corta #1: ZFS no se importa porque hoy se siente cauteloso. Igual que yo, ZFS. Igual.

Regla dura: empieza en solo lectura siempre que puedas

Si tu primer import exitoso es en lectura-escritura y estabas equivocado sobre el modo de fallo, puedes avanzar metadatos hacia una nueva realidad peor. Prefiere una importación en solo lectura para la inspección inicial. Siempre puedes remontar después.

Qué significa realmente “no se importa”

La frase encierra múltiples síntomas:

• zpool import muestra el pool, pero la importación falla con errores de I/O.
• zpool import no muestra el pool en absoluto.
• La importación “cuelga” (en realidad está atascada en reintentos de I/O o esperando dispositivos lentos).
• La importación funciona, pero los datasets no se montan o el pool se suspend inmediatamente.
• El host incorrecto lo importa (acceso multi-host, SAN, desastres en JBOD compartidos).

La ruta de solución depende de cuál tengas. Así que triageamos rápido.

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

Esta es la secuencia de “deja de desplazarte, empieza a comprobar”. El objetivo es encontrar el cuello de botella rápidamente: ¿es descubrimiento de dispositivos, salud de dispositivos, metadatos del pool o montajes/llaves?

Primero: ¿puede el SO ver los discos de forma fiable?

• Revisa los registros del kernel por resets/timeouts.
• Confirma identidad estable de los dispositivos: by-id, WWN o IDs GPT.
• Asegúrate de que el HBA/controlador vea el mismo número de discos que esperas.

Si el SO no puede ver los discos claramente, ZFS no es el problema. ZFS es solo el primer testigo honesto.

Segundo: ¿ve zpool import el pool, y qué dice?

• Si el pool aparece: lee el texto de estado cuidadosamente, en especial “UNAVAIL”, “was /dev/…”, “insufficient replicas” y el último TXG.
• Si no aparece: escanea rutas manualmente, revisa confusión con cachefile y considera daño en etiquetas.

Tercero: importa en el modo viable más seguro

• Intenta primero una importación en solo lectura (-o readonly=on).
• Sólo después considera flags de rewind/rollback (-F con o sin -X), y solo después de saber qué estás sacrificando.
• Si hay cifrado, separa “import pool” de “mount dataset”: las llaves pueden bloquear montajes aun cuando el pool se importe.

Hechos y contexto interesantes (por qué ZFS actúa así)

• ZFS almacena múltiples etiquetas por dispositivo. Cada disco suele tener etiquetas cerca del inicio y del final, por eso el daño parcial de etiquetas puede ser recuperable.
• Las importaciones de pool son transaccionales. ZFS avanza a través de TXGs (transaction groups). Las operaciones de rewind seleccionan un TXG consistente anterior.
• Los “uberblocks” son las migas de pan. ZFS escribe múltiples uberblocks; la lógica de importación elige el mejor válido que encuentre en los dispositivos.
• OpenZFS es la línea viva. ZFS se originó en Sun Microsystems y continuó como OpenZFS en illumos, FreeBSD y Linux, con feature flags para gestionar compatibilidad.
• Los feature flags no son cosméticos. Un pool con flags más recientes puede no importarse en un sistema más antiguo, aunque los discos estén sanos.
• ZFS se esfuerza por protegerte del split-brain. El “hostid” del pool y el comportamiento multihost existen porque importar el mismo pool en dos máquinas puede corromperlo rápidamente.
• La autocorrección necesita redundancia. Los checksums detectan corrupción, pero sin mirrors/RAIDZ parity, ZFS no siempre puede reparar automáticamente.
• La importación puede ser lenta por diseño. Con muchos discos o hardware defectuoso, ZFS puede sondear etiquetas y reintentar I/O; puede parecer un bloqueo mientras actúa con extrema prudencia.

Tareas prácticas: comandos, salidas y decisiones

A continuación están las tareas prácticas que ejecuto más o menos en este orden. Cada una incluye qué buscar y qué decisión toma. Ejecútalas como root o con sudo. Guarda la salida en un archivo si estás en llamada con otros equipos.

Task 1: Captura lo obvio: ¿qué piensa ZFS ahora mismo?

cr0x@server:~$ zpool status -v
no pools available

Qué significa: Nada está importado. Eso aún no es un diagnóstico; es un punto de partida.

Decisión: Pasa al descubrimiento: ¿puede el sistema siquiera ver el pool en disco?

Task 2: Lista pools importables (y no ignores el texto)

cr0x@server:~$ zpool import
   pool: tank
     id: 1234567890123456789
  state: UNAVAIL
 status: One or more devices are unavailable.
 action: The pool cannot be imported. Attach the missing devices and try again.
   see: zpool(8)
 config:

        tank        UNAVAIL  insufficient replicas
          raidz1-0  UNAVAIL  insufficient replicas
            sda     ONLINE
            sdb     ONLINE
            sdc     UNAVAIL  cannot open
            sdd     ONLINE

Qué significa: ZFS ve los metadatos del pool y te dice exactamente por qué no se importa: replicas insuficientes porque un vdev carece de miembro (RAIDZ1 tolera una pérdida; esto puede ser más de una, o el que falta está presente pero inaccesible).

Decisión: Deja de probar flags al azar. Primero arregla la visibilidad del dispositivo: descubre por qué sdc no puede abrirse.

Task 3: Confirma la identidad del dispositivo (no confíes en /dev/sdX)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'ata-|wwn-' | head
lrwxrwxrwx 1 root root  9 Feb  4 09:11 ata-SAMSUNG_MZ7LM960HMJP-00005_S4X9NX0M123456 -> ../../sda
lrwxrwxrwx 1 root root  9 Feb  4 09:11 ata-SAMSUNG_MZ7LM960HMJP-00005_S4X9NX0M123457 -> ../../sdb
lrwxrwxrwx 1 root root  9 Feb  4 09:11 ata-SAMSUNG_MZ7LM960HMJP-00005_S4X9NX0M123458 -> ../../sdd

Qué significa: Falta una entrada by-id esperada, o apunta a un lugar inesperado. Eso suele ser un problema de cableado/HBA, un disco muerto o un disco que cambió de modo/namespace.

Decisión: Si un disco está ausente a nivel de SO, ningún flag de ZFS lo hará reaparecer. Ve a los registros del kernel y al estado del controlador.

Task 4: Triage de logs del kernel por errores I/O y resets

cr0x@server:~$ dmesg -T | egrep -i 'error|reset|timeout|sas|scsi|nvme' | tail -n 20
[Mon Feb  4 09:08:12 2026] sd 6:0:12:0: [sdc] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Mon Feb  4 09:08:12 2026] sd 6:0:12:0: [sdc] Sense Key : Hardware Error [current]
[Mon Feb  4 09:08:12 2026] sd 6:0:12:0: [sdc] Add. Sense: Internal target failure
[Mon Feb  4 09:08:13 2026] mpt3sas_cm0: log_info(0x31120405): originator(PL), code(0x12), sub_code(0x0405)
[Mon Feb  4 09:08:14 2026] scsi 6:0:12:0: rejecting I/O to offline device

Qué significa: El disco o la ruta está fallando en la capa de transporte. ZFS tiene razón al negarse a importar si la redundancia es insuficiente.

Decisión: Arregla hardware primero: reinspeccionar, reemplazar o mover la unidad/ruta. Si es SAN/JBOD de doble camino, revisa la configuración de multipath.

Task 5: Verifica que estés en la versión/features correctas de OpenZFS

cr0x@server:~$ zpool upgrade -v | head -n 12
This system supports ZFS pool feature flags.

The following features are supported:

FEAT DESCRIPTION
async_destroy                        Destroy filesystems asynchronously.
bookmarks                           ZFS bookmarks.
embedded_data                       Blocks which compress very well use even less space.

Qué significa: Este host soporta feature flags en general, pero eso no confirma los flags exactos del pool.

Decisión: Si el pool se importó por última vez en un sistema más nuevo, puede que necesites importarlo allí (o actualizar este sistema). Los problemas de incompatibilidad suelen mostrarse como “unsupported feature” en la importación.

Task 6: Obtén salida detallada del escaneo de importación (la historia del pool)

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -N -f tank
cannot import 'tank': one or more devices is currently unavailable

Qué significa: Incluso al escanear rutas estables y evitar cachefiles obsoletos, falta un vdev.

Decisión: Si la redundancia lo permite, quizá importes degradado. Si no, detente y recupera los dispositivos/rutas que faltan primero.

Task 7: Ver si ZFS está simplemente esperando (triage de “colgado” en import)

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -N -f tank

Qué significa: Sin salida y sin prompt puede significar que la importación está atascada haciendo I/O. No asumas que está muerta; asume que está bloqueada.

Decisión: En otra terminal, confirma si el proceso está activo y si los dispositivos están en timeout.

cr0x@server:~$ ps -eo pid,etime,cmd | egrep 'zpool import|PID'
  PID     ELAPSED CMD
 8421       02:14 zpool import -d /dev/disk/by-id -o cachefile=none -N -f tank

Decisión: Si el tiempo transcurrido crece y los logs muestran reintentos/timeouts, tienes un problema de ruta hardware. Si no hay errores de I/O, podrías tener un pool muy grande y sondeo de etiquetas lento; sé paciente pero vigila métricas.

Task 8: Comprueba I/O activo e identifica el dispositivo lento

cr0x@server:~$ iostat -x 1 5
Linux 6.6.0 (server)  02/04/2026  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.02    0.00    2.31   35.44    0.00   61.23

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
sda              1.0      32.0     0.0    0.0   12.0    32.0       0.0      0.0     0.0    0.01    2.0
sdb              1.0      32.0     0.0    0.0   10.0    32.0       0.0      0.0     0.0    0.01    2.0
sdc              0.0       0.0     0.0    0.0    0.0     0.0       0.0      0.0     0.0    0.00    0.0
sdd              1.0      32.0     0.0    0.0   11.0    32.0       0.0      0.0     0.0    0.01    2.0

Qué significa: Alto iowait con un dispositivo sin actividad puede significar que no responde en absoluto, o que el kernel lo ha desconectado. Alternativamente, un único dispositivo al 100% de utilización con await enorme indica que está ralentizando la importación.

Decisión: Si un dispositivo está offline/no responde, arréglalo. Si está solo lento, a veces puedes completar una importación en solo lectura para extraer datos antes de reemplazarlo.

Task 9: Intenta una importación en solo lectura y sin montar (import seguro primero)

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -o readonly=on -N tank
cannot import 'tank': one or more devices is currently unavailable

Qué significa: Solo lectura no elude dispositivos faltantes. Solo reduce el riesgo cuando la importación es posible.

Decisión: Si existe redundancia (mirror/RAIDZ con pérdida tolerable), usa import degradado. Si no, detente y recupera el disco/ruta que falta.

Task 10: Intentar import degradado cuando la redundancia lo permite

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -o readonly=on -N -f -o failmode=continue tank
cannot import 'tank': insufficient replicas

Qué significa: ZFS te dice que no hay forma segura de ensamblar datos consistentes porque no puede reconstruir el vdev. Este es el mensaje de “falta demasiado”.

Decisión: Recuperación de hardware o restauración desde backup. No intentes flags mágicos esperando milagros; podrías crear nuevo daño.

Task 11: Si el pool se importa pero los datasets no se montan, verifica cifrado y ajustes de montaje

cr0x@server:~$ zpool import -d /dev/disk/by-id -o cachefile=none -N -f vault
cr0x@server:~$ zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
vault           1.2T   800G    96K  /vault
vault/secure     0B     800G    96K  /vault/secure

Qué significa: El pool está importado, los datasets son visibles, pero no necesariamente están montados. Si el cifrado está activado, los montajes pueden fallar hasta que se carguen las llaves.

Decisión: Comprueba el estado de las llaves y luego cárgalas y monta intencionalmente.

cr0x@server:~$ zfs get -H -o name,property,value keystatus vault/secure
vault/secure	keystatus	unavailable

Decisión: Carga la llave. Si no la tienes, detente y escala; la fuerza bruta no es una característica.

cr0x@server:~$ zfs load-key -r vault/secure
Enter passphrase for 'vault/secure':
cr0x@server:~$ zfs mount -a
cr0x@server:~$ mount | grep vault
vault on /vault type zfs (ro,relatime,xattr,noacl)
vault/secure on /vault/secure type zfs (rw,relatime,xattr,noacl)

Task 12: Si la importación se queja de “active pool” o host incorrecto, verifica hostid y situación multihost

cr0x@server:~$ zpool import
   pool: prod
     id: 9876543210987654321
  state: ONLINE
 status: The pool is currently imported by another system.
 action: The pool must be exported from the other system, then imported.
   see: zpool(8)
 config:

        prod        ONLINE
          mirror-0  ONLINE
            wwn-0x5000c500a1b2c3d4  ONLINE
            wwn-0x5000c500a1b2c3d5  ONLINE

Qué significa: ZFS piensa que otro host lo posee. A veces eso es cierto (estantería compartida), a veces es un estado obsoleto tras un crash, a veces es un split-brain esperando ocurrir.

Decisión: Confirma que el otro host esté realmente abajo o que haya exportado. Si no estás 100% seguro, detente. La corrupción multi-host es rápida y humillante.

Task 13: Si debes forzar la importación, hazlo primero en solo lectura

cr0x@server:~$ zpool import -f -o readonly=on -o cachefile=none -N prod
cr0x@server:~$ zpool status -x
pool 'prod' is healthy

Qué significa: Trajiste el pool de forma segura (solo lectura, sin montajes). Esto es modo inspección.

Decisión: Valida datos y salud de dispositivos antes de pasar a lectura-escritura. Si es un problema de propiedad, planifica una secuencia limpia de export/import.

Task 14: Revisa errores a nivel de pool y si se suspendió

cr0x@server:~$ zpool status -v prod
  pool: prod
 state: SUSPENDED
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
config:

        NAME                        STATE     READ WRITE CKSUM
        prod                        SUSPENDED     0     0     0
          mirror-0                  DEGRADED      0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE        0     0     0
            wwn-0x5000c500a1b2c3d5  FAULTED       0    12     0  too many errors

errors: No known data errors

Qué significa: ZFS suspendió I/O para proteger la consistencia. Normalmente es un dispositivo que falló a mitad de operación.

Decisión: Arregla/reemplaza el dispositivo con fallo primero. Limpiar sin arreglar es pedirle a ZFS que reanude sobre fuego.

Task 15: Después de arreglar hardware, limpia errores e intenta acciones de recuperación deliberadamente

cr0x@server:~$ zpool clear prod
cr0x@server:~$ zpool status prod
  pool: prod
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
config:

        NAME                        STATE     READ WRITE CKSUM
        prod                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  UNAVAIL      0     0     0  cannot open

Qué significa: El pool funciona con las réplicas restantes. Necesitas re-adjuntar/reemplazar el lado ausente.

Decisión: Reemplaza el disco fallado y realiza resilver. No lo dejes degradado “un rato”. Así es como “un rato” se convierte en “un evento que genera reanudación”.

Task 16: Identifica TXGs recientes y considera rewind solo cuando la corrupción sea plausible

cr0x@server:~$ zpool import -F -n -d /dev/disk/by-id tank
Would be able to return pool to state as of Tue Feb  3 18:22:41 2026.
Would discard 2.14G of transactions.

Qué significa: El dry-run de rewind está disponible. Revertiría algunas escrituras recientes. Eso puede ser aceptable si la alternativa es “no hay pool”. También puede ser inaceptable si esas escrituras eran críticas.

Decisión: Pausa y alinea con los stakeholders. Si procedes, haz la primera importación exitosa en solo lectura, confirma datasets y luego decide sobre lectura-escritura.

Task 17: Ejecuta la importación con rewind cuidadosamente (solo si decides sacrificar TXGs recientes)

cr0x@server:~$ zpool import -F -o readonly=on -o cachefile=none -N -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
status: Pool was previously in use from another system.
action: Export the pool from the other system, then import it.
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     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Qué significa: El pool es accesible de nuevo (en modo inspección solo lectura). La advertencia de “previously in use” es común tras crashes o migraciones; no siempre es una condición multi-host real, pero trátala seriamente.

Decisión: Valida datos, exporta limpiamente si es necesario y luego importa normalmente en lectura-escritura. Si realmente tienes acceso multi-host, corrige esa arquitectura.

Task 18: Una vez importado, monta intencionalmente y verifica

cr0x@server:~$ zfs mount -a
cr0x@server:~$ zfs list -o name,used,avail,mountpoint | head
NAME               USED  AVAIL  MOUNTPOINT
tank               128K  10.9T  /tank
tank/home          2.1T  10.9T  /tank/home
tank/vm            6.4T  10.9T  /tank/vm

Qué significa: Los datasets están montados, los puntos de montaje tienen sentido y puedes proceder a comprobaciones a nivel de aplicación.

Decisión: Si los puntos de montaje son incorrectos (por ejemplo, legacy vs gestionado por ZFS), pausa y corrige propiedades antes de arrancar servicios.

Modos de fallo que realmente puedes arreglar

1) El pool está bien; el SO no puede ver los discos (o los ve diferente)

La mayoría de incidentes de “ZFS no se importa” son en realidad “la capa de almacenamiento cambió”. Disparadores comunes:

• Actualización de firmware del HBA cambió cómo se enumeran las unidades.
• Expanders SAS intermitentes bajo carga.
• Namespaces NVMe cambiados tras ejecutar herramientas del proveedor.
• Misconfiguración de multipath que presenta dos nodos por LUN.

Solución: Estabiliza la capa de dispositivos primero. Usa rutas by-id; confirma que todos los WWN esperados existan; elimina nodos multipath obsoletos; reemplaza cables/transceptores defectuosos.

2) Confusión con cachefile y rutas de dispositivo obsoletas

En algunos sistemas, ZFS usa un cachefile para recordar rutas de vdev. Si el cachefile apunta a antiguos /dev/sdX, la importación puede fallar aunque las unidades existan.

Solución: Usa -o cachefile=none y escanea explícitamente -d /dev/disk/by-id. Tras una importación limpia, establece un cachefile sensato para tu SO o deja que el servicio lo gestione.

3) Incompatibilidad de feature flags / versión

Si un pool se actualizó (feature flags habilitadas) en un host, hosts más antiguos pueden negarse a importarlo. Esto parece un error de importación, no una falla de disco.

Solución: Importa en un sistema con soporte de features compatible. Si debes mover pools entre hosts, gestiona versiones de ZFS como gestionas versiones de bases de datos: deliberadamente.

4) Corrupción en los TXGs más recientes tras un crash (territorio de rewind)

Pérdida de energía inesperada más caché de escritura mentirosa más un timing desafortunado puede dejar el TXG más reciente inconsistente. ZFS normalmente detecta y evita uberblocks inconsistentes, pero a veces necesitas hacer rewind.

Solución: Usa zpool import -F -n para ver el coste del rollback. Procede solo si aceptas descartar transacciones recientes. Prefiere la primera importación en solo lectura.

5) Pool suspendido debido a fallos de I/O

Esto es ZFS haciendo lo correcto: detener I/O para proteger la consistencia. A la gente le molesta porque es ruidoso, pero es mejor que la corrupción silenciosa.

Solución: Identifica y reemplaza/restaura la ruta de dispositivo con fallo. Luego zpool clear y resilver.

6) Advertencias de “Imported elsewhere” (multi-host real o estado obsoleto)

A veces otro host es real. A veces murió y dejó migas. En cualquier caso, importar en dos hosts es cómo conviertes un incidente recuperable en un proyecto forense.

Solución: Confirma exclusividad. Si el otro host está activo, exporta allí. Si está muerto, asegúrate de que no pueda ver los discos (apagar, desconectar estantería) antes de forzar import.

Broma corta #2: Forzar una importación en almacenamiento compartido sin comprobar el otro host es como hacer merge a main sin tests—técnicamente posible, emocionalmente costoso.

Tres mini-historias corporativas desde el frente

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

El equipo de almacenamiento reemplazó un HBA en un host de virtualización durante una ventana planificada. Nueva tarjeta, misma familia, mismo cableado. El ingeniero supuso que los nombres de dispositivo permanecerían, porque “Linux siempre encuentra los discos”. Los encontró—solo que en distinto orden.

Tras el reinicio, el pool ZFS no se importó. El on-call vio errores de cannot open para un par de dispositivos y de inmediato sospechó fallo de disco. Se abrió un ticket para que removieran discos en el centro de datos. Esa fue una reacción costosa: los intercambios de discos son fáciles de hacer mal, y cada extracción es una oportunidad para crear una segunda interrupción.

Treinta minutos después, alguien finalmente ejecutó zpool import -d /dev/disk/by-id -o cachefile=none y vio los metadatos del pool perfectamente intactos. El problema era que el cachefile del sistema referenciaba antiguas rutas /dev/sdX y la nueva enumeración del HBA no coincidía. Nadie había confirmado identificadores estables.

La solución fue aburrida: importar usando by-id, actualizar el comportamiento del cachefile y añadir un paso en la checklist pre-mantenimiento que valide todos los WWN tras cualquier cambio de controlador. El postmortem dejó claro el problema real: la suposición equivocada no era sobre ZFS; era sobre identidad.

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

Un equipo quería más rapidez en writes sync para una canalización de logs. Añadieron SSDs consumidores rápidos como dispositivo SLOG, lo configuraron agresivamente y celebraron cuando los benchmarks se duplicaron. Luego llegó la realidad: un evento de energía más un brownout que no cortó totalmente el rack, solo lo suficiente para confundir varios dispositivos.

Tras el reinicio, la importación del pool a veces funcionaba y a veces se colgaba. Los logs mostraron resets intermitentes e “Internal target failure” en uno de los SSDs. Como el SLOG estaba en un dispositivo consumidor inestable sin protección ante pérdida de energía, el sistema tardaba demasiado intentando comunicarse con él durante la importación. No era el único problema, pero sí el más ruidoso.

El primer “arreglo” fue forzar la importación con todos los flags imaginables. Eso hizo que el sistema importara ocasionalmente, pero no fue estable. ZFS hizo lo que pudo; el hardware hizo lo que quiso.

La recuperación real: retirar físicamente el dispositivo de log defectuoso (o reemplazarlo por uno conocido y con PLP), luego importar en solo lectura, reemplazar piezas malas y reintroducir un dispositivo de log con criterios de selección adecuados. La “optimización” se convirtió en un impuesto a la disponibilidad.

La lección: si optimizas límites de durabilidad (sync writes, intent logs, write caches), heredas sus modos de fallo. Si a tu negocio le importan esas escrituras, tu hardware también debe importarle.

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

Una empresa tenía la política de que cada chasis de almacenamiento llevaba una hoja laminada pegada en la puerta frontal. Listaba slot de disco → WWN → pertenencia a pool/vdev. Parecía algo de un NOC de los años 90, y todos se burlaban hasta que importó.

Un pool dejó de importarse tras un contratista de mantenimiento que “ordenó el cableado”. La mitad de los discos estaban presentes, la otra mitad invisibles. El contratista juró que no movió nada. Los logs del SO decían otra cosa.

Como el equipo tenía el mapeo slot→WWN, rápidamente identificaron qué slots físicos correspondían a los WWN faltantes y rastrearon el problema hasta un cable de expander medio insertado. Sin adivinanzas. Sin “prueba intercambiando sdc y sdd”. Sin extracción accidental del disco incorrecto del único mirror sobreviviente.

El pool se importó degradado y luego completamente tras arreglar el cable. El resilver terminó durante la noche. La política era aburrida. También fue la diferencia entre un incidente de dos horas y una restauración de varios días.

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

1) Síntoma: zpool import no muestra nada

Causa raíz: Dispositivos no descubiertos, ruta de escaneo incorrecta o etiquetas no legibles por problemas hardware/controlador. A veces el pool existe pero está detrás de nodos multipath que no estás escaneando.

Solución: Escanea directorios explícitos (-d /dev/disk/by-id), revisa dmesg por errores de descubrimiento y confirma que los WWN esperados estén presentes. Si estás en SAN, verifica que multipath presente un único dispositivo estable por LUN.

2) Síntoma: Import falla con “insufficient replicas”

Causa raíz: Demasiados dispositivos ausentes en un vdev. Los mirrors necesitan un lado; RAIDZ necesita suficientes miembros para reconstruir la paridad; si estás por debajo de ese umbral, ZFS no puede ensamblar el vdev.

Solución: Restaura dispositivos faltantes (cable/HBA/ruta), reemplaza discos fallados o recupera desde backup. No esperes que -f eluda la física.

3) Síntoma: Import se cuelga indefinidamente

Causa raíz: El kernel está reintentando I/O a un dispositivo que entra en timeout, a menudo por disco defectuoso, expander o incompatibilidad de firmware del controlador.

Solución: Identifica el dispositivo lento/defectuoso vía logs del kernel y iostat. Quita/reemplaza el culpable. Luego reintenta la importación, preferiblemente en solo lectura primero.

4) Síntoma: Pool se importa, pero servicios fallan porque los datasets no están montados

Causa raíz: Import con -N, propiedades de mountpoint, montajes legacy o llaves de cifrado no cargadas.

Solución: Revisa zfs get mountpoint,canmount,keystatus. Carga llaves si es necesario. Monta explícitamente con zfs mount -a o por dataset.

5) Síntoma: Pool se vuelve inmediatamente SUSPENDED

Causa raíz: ZFS detectó fallos de I/O repetidos y suspendió para proteger el pool. A menudo un dispositivo falla bajo carga de escritura.

Solución: Reemplaza/soluciona la ruta del dispositivo. Luego limpia errores y resilver. No sigas limpiando sin arreglar hardware.

6) Síntoma: “The pool is currently imported by another system”

Causa raíz: O bien está importado en otro lado, o el sistema cree que lo estuvo (estado obsoleto tras crash). En entornos de almacenamiento compartido, esta es la advertencia más importante.

Solución: Confirma exclusividad: asegúrate de que otros hosts no puedan ver los discos, luego importa en solo lectura primero. Implementa multihost y controles operativos si existen estanterías compartidas.

7) Síntoma: Error de import menciona features no soportadas

Causa raíz: El pool se creó o actualizó con feature flags no soportadas por esta implementación/versión de ZFS.

Solución: Importa en un host más nuevo y compatible. Alinea versiones de ZFS en la flota. No “actualices features del pool” a la ligera en entornos mezclados.

8) Síntoma: Tras forzar la importación, los datos parecen “más antiguos” de lo esperado

Causa raíz: El rewind/rollback descartó TXGs recientes, o las aplicaciones asumieron semánticas de sync que no tenían.

Solución: Trata el rewind como pérdida de datos por diseño. Comunica claramente. Valida la consistencia a nivel de aplicación; restaura logs de aplicación si están disponibles.

Listas de verificación / plan paso a paso

Fase 0: Congelar la escena (5–10 minutos)

• Detén cualquier automatización que pueda seguir reintentando imports o montando datasets.
• Captura: dmesg -T, journalctl -k (si está disponible), zpool import y salida de inventario hardware.
• Confirma si esto es almacenamiento compartido. Si sí, asegúrate de que solo un host pueda acceder a los discos.

Fase 1: Verdad de la capa de dispositivos

1. Lista identificadores estables: ls -l /dev/disk/by-id.
2. Compara los WWN esperados con los presentes (desde tu inventario, etiquetas o última salida conocida de zpool status).
3. Revisa logs del kernel por resets/timeouts de los dispositivos faltantes.
4. Arregla cableado/HBA/discos hasta que todos los dispositivos esperados estén presentes y estables.

Fase 2: Descubrimiento ZFS no destructivo e intento de import

1. Escanea explícitamente: zpool import -d /dev/disk/by-id.
2. Si aparece el pool, anota estado, vdevs faltantes y cualquier pista de “last TXG”.
3. Intenta import seguro: zpool import -d /dev/disk/by-id -o cachefile=none -o readonly=on -N POOL.
4. Si se importa, inspecciona zpool status -v y zfs list antes de montar o arrancar servicios.

Fase 3: Riesgo controlado (solo cuando sea necesario)

1. Si la import falla por sospecha de corrupción reciente, prueba rewind en dry-run: zpool import -F -n POOL.
2. Decide si puedes descartar las transacciones mostradas. Trátalo como pérdida de datos.
3. Si procedes, importa con rewind en solo lectura primero: zpool import -F -o readonly=on -N POOL.
4. Valida datos, luego exporta e importa normalmente en lectura-escritura si procede.

Fase 4: Después de la importación—volver a estabilizar

• Reemplaza dispositivos fallados y realiza resilver.
• Ejecuta un scrub cuando el sistema esté estable y el impacto en rendimiento sea aceptable.
• Documenta la causa raíz. Actualiza runbooks y mapeos de inventario.

Qué evitar (estos son reincidentes)

• No ejecutes comandos destructivos (como reparticionar, formatear o “inicializar” discos) en dispositivos que no hayas identificado positivamente por WWN/serial.
• No actualices features del pool durante la recuperación. El tiempo de recuperación no es tiempo de features.
• No importes en lectura-escritura primero cuando no estés seguro. Estás depurando; minimiza efectos secundarios.
• No ignores logs de hardware. Suelen decir la verdad que no quieres oír.

Preguntas frecuentes

1) ¿Debo intentar zpool import -f inmediatamente?

No. Primero determina si el pool está realmente importado en otro lado y si faltan dispositivos. Force import es para conflictos de propiedad, no para discos ausentes.

2) ¿Qué me aporta -o cachefile=none?

Evita que ZFS confíe en rutas cacheadas potencialmente obsoletas y fuerza un escaneo fresco de los dispositivos que especifiques. Es una forma barata de eliminar problemas de “antiguo nombre /dev/sdX”.

3) ¿Por qué sigues diciendo “escanear by-id”?

Los nombres /dev/sdX se asignan al arranque y pueden cambiar cuando controladores, firmware o tiempos de disco cambian. By-id y nombrado por WWN es cómo mantener la cordura en producción.

4) Si puedo importar en solo lectura, ¿puedo copiar los datos y reconstruir?

A menudo sí, y es una gran opción cuando sospechas degradación hardware continua. La importación en solo lectura reduce la probabilidad de empeorar metadatos mientras extraes datos.

5) ¿Cuándo es apropiado el rewind (zpool import -F)?

Cuando sospechas firmemente que los TXGs más recientes están inconsistentes (crash a mitad de write, caché de escritura mentirosa, pérdida súbita de energía) y la importación normal falla. Haz siempre -n primero para ver el coste.

6) ¿ZFS puede recuperar corrupción silenciosa sin redundancia?

ZFS puede detectar corrupción mediante checksums. La reparación requiere redundancia (mirror/RAIDZ o copias) o una fuente externa confiable (backup). Detectar sin reparar sigue siendo valioso; te dice qué no confiar.

7) ¿Por qué la importación tarda tanto en pools grandes?

La importación puede sondear etiquetas a través de muchos dispositivos y reintentar I/O cuando los dispositivos responden lentamente. Si un solo disco está intermitente, el tiempo de import puede dispararse porque el kernel sigue intentando ayudar.

8) ¿Y si el pool se importa pero mis aplicaciones siguen fallando?

Separa la salud del almacenamiento de la corrección de la aplicación. Revisa puntos de montaje de datasets, llaves de cifrado y si los servicios esperan rutas/permiso específicos. Luego valida la consistencia a nivel de aplicación.

9) ¿Es seguro ejecutar un scrub inmediatamente después de la recuperación?

Usualmente sí, pero el momento importa. Si el hardware sigue inestable, un scrub puede amplificar fallos. Estabiliza hardware, restaura redundancia y luego scrub para confirmar integridad.

10) ¿Cómo evito problemas de “pool importado en otro lado”?

Arquitectónicamente: no presentes los mismos discos a múltiples hosts a menos que tengas una estrategia multi-host diseñada y probada. Operativamente: aplica fencing y usa prácticas de identidad de host estables.

Conclusión: siguientes pasos para reducir incidentes recurrentes

Si tu pool ZFS no se importa, la ruta calmada es: estabilizar dispositivos, escanear con identificadores estables, importar primero en solo lectura, y luego tomar riesgos controlados solo cuando la evidencia lo respalde.

Pasos prácticos que asignaría tras el incidente:

• Estandarizar rutas vdev por by-id/WWN para todos los pools. Arreglar el pool legado antes de que sea una interrupción.
• Añadir una comprobación pre-mantenimiento que registre zpool status, inventario WWN y versiones de firmware del controlador.
• Revisar caché de escritura, protección contra pérdida de energía y cualquier “optimización de rendimiento” que cambie el comportamiento ante fallos.
• Ensayar recuperación en laboratorio: importar con dispositivos faltantes, probar dry-runs de rewind, practicar flujos de trabajo de llaves de cifrado.
• Hacer backups aburridos y verificados. ZFS es resiliente, no mágico.

Cuando haces esto lo suficiente, lo aterrador deja de ser los comandos. Se vuelve la tendencia humana a apresurarse. No lo hagas. ZFS premia la paciencia y castiga la improvisación.