Proxmox ZFS «cannot import pool»: causas raíz, comprobaciones y opciones de recuperación

Qué significa realmente “cannot import pool” en Proxmox

Proxmox no está haciendo nada místico aquí. Es un host basado en Debian con herramientas ZFS. Si el pool no se importa,
Proxmox no puede montar datasets, no puede presentar ZVOLs, y tu definición de almacenamiento en la GUI se convierte en una etiqueta triste e inerte.

El proceso de importación es ZFS leyendo etiquetas desde los vdevs, reconstruyendo el estado del pool desde el grupo de transacciones (TXG) más reciente,
y asegurando que puede abrir el pool de forma segura con la identidad y las rutas de dispositivo del host actual.
Cuando falla, casi siempre es una de cinco categorías:

• Problemas de visibilidad de dispositivos: los discos no están (o no son estables), rutas by-id equivocadas, HBA/firmware raro, conflictos de multipath.
• Comprobaciones de seguridad de metadatos: multihost/hostid en conflicto, importaciones antiguas, el pool cree que sigue activo en otro sitio.
• Corrupción o escrituras incompletas: apagados sucios, bloques malos, dispositivos fallando que hacen ilegibles etiquetas/uberblocks.
• Desajuste de características/propiedades: usuariospace antiguo vs flags de pool, claves de cifrado no cargadas, opciones no soportadas.
• Secuenciación de arranque/importación en Proxmox: initramfs, servicio zfs-import, deriva del cachefile, condiciones de carrera al arrancar.

El trabajo es identificar en qué categoría estás usando evidencia, y luego elegir el método de importación menos peligroso que te devuelva el servicio.
Empieza con importaciones en solo lectura, evita “force” a menos que puedas explicar a otro ingeniero por qué es seguro, y no “pruebes cosas” sobre la única copia de tus datos.

Guion rápido de diagnóstico (primeras/segundas/terceras comprobaciones)

0. Estabilizar: detener la hemorragia

• Si esto es almacenamiento compartido o potencialmente visible por múltiples hosts (caja SAS, LUNs iSCSI, FC), asegura que solo un host pueda tocarlo. Desconecta cables o deshabilita targets si hace falta.
• Congela la automatización: detén cron jobs, backups y cualquier cosa que pueda seguir sondeando dispositivos.
• Si sospechas discos fallando, evita bucles de reinicio. Cada arranque es otra tirada de dados.

1. Primera comprobación: ¿los vdevs están realmente presentes y estables?

La mayoría de tickets “cannot import” no son “ZFS está roto.” Son “la ruta del disco cambió,” “el HBA está enojado,” o “multipath miente.”
Confirma la visibilidad de dispositivos y confirma que son los mismos discos que crees.

• Ejecuta zpool import y lee el mensaje de fallo exacto.
• Revisa ls -l /dev/disk/by-id por los WWN esperados.
• Consulta dmesg -T por resets, timeouts, “I/O error”, “offline device”.

2. Segunda comprobación: ¿ZFS rechaza por seguridad (hostid/multihost/estado obsoleto)?

Si ZFS piensa que el pool está activo en otro sistema, rechazará o requerirá un override explícito. Esto es bueno; evita escrituras en split-brain.
Busca “pool may be in use from another system” y comprueba el hostid.

3. Tercera comprobación: ¿puedes importar en solo lectura e inspeccionar?

Si el pool es visible, intenta una importación en solo lectura. Esto es lo más cercano a “modo seguro” que tiene ZFS.
Si la importación en solo lectura falla, es probable que estés tratando con dispositivos faltantes, corrupción severa, características no soportadas o problemas de claves de cifrado.

Si no haces nada más: recopila las salidas de zpool import -D, zdb -l en cada dispositivo, y journalctl -u zfs-import-cache -u zfs-import-scan.
Esos tres suelen indicarte hacia dónde ir.

Datos interesantes y contexto (por qué ZFS se comporta así)

1. Los pools ZFS se autodescriben: la configuración vive en cada etiqueta de vdev, no en un único archivo frágil.
2. La importación es un proceso de consenso: ZFS elige el TXG consistente más reciente entre dispositivos; no es solo “montar y esperar”.
3. Hostid existe para prevenir split brain: ZFS puede registrar el último host que importó un pool y bloquear importaciones inseguras cuando multihost=on.
4. Los feature flags reemplazaron números de versión: los pools modernos anuncian características; las herramientas antiguas pueden negarse a importar si no las entienden.
5. ZFS prefiere IDs de dispositivo estables: /dev/sdX es una opinión, no un hecho. /dev/disk/by-id es la elección adulta.
6. El «cachefile» es una optimización: acelera importaciones, pero los cachefiles obsoletos pueden engañar en importaciones al arrancar tras cambios de hardware.
7. OpenZFS se desvió del ZFS de Solaris: Proxmox usa OpenZFS en Linux, lo que trae su propia integración de arranque y peculiaridades de orden de servicios.
8. Los scrubs no son backups: los scrubs detectan y corrigen corrupción silenciosa (cuando hay redundancia), pero no te protegen de un «rm -rf» o de la pérdida de claves de cifrado.

Causas raíz: los sospechosos habituales, con síntomas

1) Discos faltantes, renombrados o cayéndose intermitentemente

Síntomas: cannot import 'pool': no such pool available, o one or more devices is currently unavailable.
En Proxmox, esto suele seguir a un reinicio, intercambio de HBA, actualización de firmware, mover estantes o “limpiamos el cableado”.

Realidad: las etiquetas ZFS están en los discos, pero Linux puede que no los presente de forma consistente, o los nombres udev cambiaron,
o multipath está creando nodos duplicados. El pool puede ser importable con -d /dev/disk/by-id o tras arreglar el descubrimiento de dispositivos.

2) El pool aparece “en uso” en otro sistema (hostid / multihost / importación obsoleta)

Síntomas: pool may be in use from another system. Esto es común tras clonar discos de arranque, restaurar imágenes del SO de Proxmox,
o importar un pool que se usó por última vez en otro nodo.

Realidad: ZFS intenta evitar que dos máquinas escriban en el mismo pool al mismo tiempo. Si estás absolutamente seguro de que un solo host tiene acceso,
puedes importar con -f. Si no estás seguro, detente aquí y demuéstralo.

3) Clave de cifrado no disponible (cifrado nativo ZFS)

Síntomas: la importación tiene éxito pero los datasets no se montan, o la importación falla con errores relacionados con la clave.
Proxmox puede mostrar el almacenamiento presente pero inutilizable.

Realidad: el pool puede importarse, pero los datasets quedan bloqueados hasta que se carguen las claves. A veces la gente interpreta esto como “el pool no se importa”
porque sus VMs no arrancan. Es un fallo diferente, diferente solución.

4) Flags de característica no soportadas o desajuste de versión

Síntomas: la importación se niega con mensajes sobre características no soportadas, o “pool uses the following feature(s) not supported by this system.”

Realidad: actualizaste el pool en un OpenZFS más nuevo y luego intentaste importar en un nodo Proxmox más antiguo o en un entorno rescue.
La solución suele ser arrancar un entorno moderno con OpenZFS compatible, no “degradar el pool” (no puedes).

5) Daño de metadatos / dispositivo fallando / etiquetas ilegibles

Síntomas: errores I/O durante la importación, cannot open en vdevs específicos, bad label, reintentos repetidos, o el pool aparece en zpool import pero falla al importarlo.

Realidad: uno o más dispositivos no pueden leer metadatos críticos. La redundancia ayuda. Sin redundancia, estás en modo recuperación: intenta solo-lectura, intentar importar con dispositivos faltantes,
y prepárate para copiar datos rápidamente.

6) Carreras en importación al arrancar y cachefiles obsoletos

Síntomas: el pool se importa manualmente pero no en el arranque; el almacenamiento en la GUI aparece “faltante” tras reiniciar hasta que ejecutas zpool import.

Realidad: los servicios de importación ZFS se ejecutaron antes de que los dispositivos estuvieran listos, o el cachefile apunta a rutas antiguas. El pool está bien; la secuencia de arranque no lo está.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las tareas que realmente ejecuto en incidentes. Cada una incluye: el comando, un fragmento de salida realista, qué significa y la decisión que tomas.
Ejecútalas como root (o con sudo) en el nodo Proxmox o en un shell de rescate con las herramientas ZFS instaladas.

Task 1: See what ZFS thinks is importable

cr0x@server:~$ zpool import
   pool: rpool
     id: 1234567890123456789
  state: ONLINE
 status: The pool was last accessed by another system.
 action: The pool can be imported using its name or numeric identifier and the '-f' flag.
 config:

        rpool       ONLINE
          sda3      ONLINE

Qué significa: ZFS puede ver el pool y sus vdev(s). El bloqueo es “last accessed by another system”.

Decisión: Antes de usar -f, demuestra que solo este host puede escribir en esos discos (especialmente si esto es almacenamiento compartido). Si son discos locales de un solo host, procede con una importación forzada.

Task 2: Get verbose import diagnostics, including destroyed pools (-D)

cr0x@server:~$ zpool import -D -d /dev/disk/by-id
pool: tank
  id: 9876543210987654321
state: UNAVAIL
status: One or more devices are missing from the system.
action: The pool cannot be imported. Attach the missing devices and try again.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-3C
config:

        tank                         UNAVAIL  missing device
          raidz1-0                   UNAVAIL
            wwn-0x5000cca2abcd0001   ONLINE
            wwn-0x5000cca2abcd0002   ONLINE
            wwn-0x5000cca2abcd0003   UNAVAIL

Qué significa: ZFS tiene una expectativa clara del miembro faltante. No es un problema de nombres; está ausente/ilegible.

Decisión: Ve a buscar ese dispositivo a nivel de hardware. Si realmente no está y tienes redundancia, puedes importar degradado. Si no tienes redundancia, prioriza la imagen/copia de lo que puedas.

Task 3: Confirm the kernel is seeing storage errors

cr0x@server:~$ dmesg -T | egrep -i "zfs|sd |sas|nvme|ata|reset|timed out|I/O error" | tail -n 12
[Thu Dec 26 10:12:09 2025] sd 2:0:3:0: timing out command, waited 180s
[Thu Dec 26 10:12:09 2025] sd 2:0:3:0: [sdd] tag#24 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
[Thu Dec 26 10:12:10 2025] blk_update_request: I/O error, dev sdd, sector 2048 op 0x0:(READ)
[Thu Dec 26 10:12:12 2025] ata4: hard resetting link
[Thu Dec 26 10:12:18 2025] sd 2:0:3:0: [sdd] Synchronizing SCSI cache

Qué significa: Esto no es ZFS dramatizando. El SO no puede leer de forma fiable desde un dispositivo.

Decisión: Deja de probar flags de importación al azar. Estabiliza la ruta hardware (reemplaza disco/cable/puerto HBA) o espera una recuperación parcial como máximo.

Task 4: Verify you’re using stable device identifiers

cr0x@server:~$ ls -l /dev/disk/by-id | egrep "wwn|nvme|ata" | head
lrwxrwxrwx 1 root root  9 Dec 26 10:10 wwn-0x5000cca2abcd0001 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 10:10 wwn-0x5000cca2abcd0002 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 10:10 wwn-0x5000cca2abcd0003 -> ../../sdd
lrwxrwxrwx 1 root root 13 Dec 26 10:10 nvme-SAMSUNG_MZVL21T0HCLR-00000_S6Z7... -> ../../nvme0n1

Qué significa: Tienes symlinks basados en WWN; eso es lo que ZFS quiere para importaciones consistentes.

Decisión: Al importar manualmente, apunta ZFS a /dev/disk/by-id usando zpool import -d. Si tu pool se creó usando /dev/sdX, planifica una remediación (export/import o actualización de configuración) una vez estable.

Task 5: Identify which disks actually contain ZFS labels

cr0x@server:~$ for d in /dev/disk/by-id/wwn-*; do echo "== $d =="; zdb -l $d 2>/dev/null | egrep "name:|pool_guid|vdev_guid|state:"; done | head -n 20
== /dev/disk/by-id/wwn-0x5000cca2abcd0001 ==
    name: 'tank'
    state: 0
    pool_guid: 9876543210987654321
== /dev/disk/by-id/wwn-0x5000cca2abcd0002 ==
    name: 'tank'
    state: 0
    pool_guid: 9876543210987654321
== /dev/disk/by-id/wwn-0x5000cca2abcd0003 ==
    name: 'tank'
    state: 1
    pool_guid: 9876543210987654321

Qué significa: Estos dispositivos realmente pertenecen al pool, y uno parece poco saludable o incompleto (state: 1 varía según contexto).

Decisión: Si ZFS ve etiquetas en los dispositivos esperados, el problema probablemente sea disponibilidad/comprobaciones de seguridad, no “discos equivocados”. Si un disco no tiene etiqueta, puede que estés viendo el LUN equivocado o la bahía equivocada del estante.

Task 6: Check hostid and multihost properties to explain “in use”

cr0x@server:~$ hostid
7f01000a
cr0x@server:~$ zpool get multihost tank
NAME  PROPERTY  VALUE     SOURCE
tank  multihost  on        local

Qué significa: multihost=on hace que ZFS sea más estricto sobre la seguridad de acceso concurrente. Cambios de hostid (imágenes OS clonadas) pueden disparar advertencias.

Decisión: Si este pool es realmente almacenamiento local de un solo host, considera dejar multihost=off más tarde. Por ahora, confirma exclusividad e importa con -f solo cuando puedas justificarlo.

Task 7: Attempt a read-only import (safe inspection mode)

cr0x@server:~$ zpool import -o readonly=on -N -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         DEGRADED     0     0     0
          raidz1-0                   DEGRADED     0     0     0
            wwn-0x5000cca2abcd0001   ONLINE       0     0     0
            wwn-0x5000cca2abcd0002   ONLINE       0     0     0
            wwn-0x5000cca2abcd0003   UNAVAIL      0     0     0  cannot open

Qué significa: El pool puede abrirse sin montar datasets (-N) y sin escrituras (readonly=on).

Decisión: Esto es una luz verde para proceder con cuidado: monta datasets en solo lectura y copia los datos críticos, o reemplaza el disco faltante y luego resilveriza.

Task 8: Import with missing log device (if you had a separate SLOG)

cr0x@server:~$ zpool import -m -d /dev/disk/by-id tank
cannot import 'tank': one or more devices is currently unavailable
cr0x@server:~$ zpool import -m -o readonly=on -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank | egrep -i "logs|missing|unavail"
logs
  wwn-0x5000cca2beef0009   UNAVAIL  cannot open

Qué significa: El dispositivo faltante es un vdev de logs. ZFS a menudo puede importar sin él usando -m (missing log) si los vdevs principales están intactos.

Decisión: Importa sin el log, acepta degradación de rendimiento y planea eliminar/reemplazar el vdev de log correctamente una vez estable.

Task 9: Inspect ZFS import services and boot-time failures

cr0x@server:~$ systemctl status zfs-import-cache zfs-import-scan --no-pager
● zfs-import-cache.service - Import ZFS pools by cache file
     Loaded: loaded (/lib/systemd/system/zfs-import-cache.service; enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-26 10:01:21 UTC; 3min ago
   Process: 812 ExecStart=/sbin/zpool import -c /etc/zfs/zpool.cache -aN (code=exited, status=1/FAILURE)

● zfs-import-scan.service - Import ZFS pools by device scanning
     Loaded: loaded (/lib/systemd/system/zfs-import-scan.service; enabled)
     Active: inactive (dead)

Qué significa: La importación basada en cache falló, y la importación por escaneo no se ejecutó (o no está habilitada). Clásico “el pool se importa manualmente, no en el arranque”.

Decisión: Arregla el cachefile o habilita la importación por escaneo. También investiga por qué los dispositivos no estaban listos cuando corrió la importación por cache.

Task 10: Read the journal for ZFS import hints (it’s usually blunt)

cr0x@server:~$ journalctl -u zfs-import-cache -u zfs-import-scan -b --no-pager | tail -n 40
Dec 26 10:01:20 server zpool[812]: cannot import 'tank': one or more devices is currently unavailable
Dec 26 10:01:20 server zpool[812]: Destroy and re-create the pool from a backup source.
Dec 26 10:01:20 server systemd[1]: zfs-import-cache.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 10:01:21 server systemd[1]: zfs-import-cache.service: Failed with result 'exit-code'.

Qué significa: La importación falló por la misma razón que ves manualmente. No es “drama de systemd”; es disponibilidad de dispositivos.

Decisión: Vuelve a la enumeración de dispositivos y a los errores hardware. Si la importación funciona manualmente tras un retraso, probablemente tengas un problema de temporización en el arranque.

Task 11: Check for multipath conflicts (common with SAN/iSCSI/FC)

cr0x@server:~$ multipath -ll | head -n 25
mpatha (3600508b400105e210000900000490000) dm-2 IBM,2145
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Qué significa: El mismo LUN es visible por múltiples rutas y está correctamente agregado en /dev/dm-2 como mpatha.

Decisión: Asegura que ZFS use el dispositivo multipath consistentemente (dm-id) y no estés accidentalmente importando usando /dev/sdb//dev/sdc crudos. La visibilidad duplicada puede causar corrupción si se gestiona mal.

Task 12: Verify pool feature compatibility (especially on rescue environments)

cr0x@server:~$ zpool import -o readonly=on -N tank
cannot import 'tank': unsupported feature(s)
This pool uses the following feature(s) not supported by this system:
        org.openzfs:encryption
        org.openzfs:project_quota

Qué significa: Tu userspace/kernel ZFS actual no entiende el pool. Esto es común al arrancar un live ISO antiguo.

Decisión: Arranca una versión de Proxmox (o un entorno rescue) con un OpenZFS moderno que soporte esas características. No intentes “reparar” desde un entorno incompatible.

Task 13: Load encryption keys and mount datasets (the “pool imported but nothing works” case)

cr0x@server:~$ zpool import -N -d /dev/disk/by-id tank
cr0x@server:~$ zfs get -r -o name,property,value keystatus tank | head
NAME          PROPERTY   VALUE
tank/secure   keystatus  unavailable
tank/vmdata   keystatus  available
cr0x@server:~$ zfs load-key -r tank/secure
Enter passphrase for 'tank/secure':
cr0x@server:~$ zfs mount -a
cr0x@server:~$ zfs get -r -o name,mounted,mountpoint mounted tank/secure | head -n 3
NAME         MOUNTED  MOUNTPOINT
tank/secure  yes      /tank/secure

Qué significa: La importación del pool está bien. Tu problema eran datasets bloqueados.

Decisión: Arregla la gestión de claves (prompt en el arranque vs keyfiles vs KMS externo). No persigas falsos “fallos de importación” en la GUI.

Task 14: Confirm the pool isn’t already imported (yes, it happens)

cr0x@server:~$ zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  5.45T  3.12T  2.33T        -         -    18%    57%  1.00x  ONLINE  -
cr0x@server:~$ pvesm status | head
Name             Type     Status           Total            Used       Available        %
local             dir     active       102399872        4823424        972...          4%

Qué significa: El pool ya está importado y sano. La queja podría ser un problema de montaje de dataset, una descoordinación de configuración de almacenamiento o una definición de Proxmox apuntando a otro lugar.

Decisión: Cambia de “importar” a “por qué Proxmox no lo usa”: revisa mountpoints de datasets, /etc/pve/storage.cfg y permisos.

Task 15: Attempt a forced import (only after proving exclusivity)

cr0x@server:~$ zpool import -f -d /dev/disk/by-id rpool
cr0x@server:~$ zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          sda3      ONLINE       0     0     0

Qué significa: La advertencia “in use” se limpió con la importación forzada.

Decisión: Si este pool alguna vez es visible para otro host, arregla el modelo de fencing/propiedad subyacente. Force import es una herramienta, no un modo de vida.

Opciones de recuperación ordenadas por riesgo

Tier 0: No empeorar las cosas

• Evita zpool clear como reflejo. Borra errores; no arregla la causa.
• Evita escribir en un pool que no has validado. Importa en solo lectura primero cuando haya dudas.
• Evita zpool labelclear a menos que estés destruyendo intencionalmente etiquetas (y estés seguro de estar en los discos correctos).
• Evita “probar flags al azar hasta que funcione.” Así conviertes un pool recuperable en un artefacto forense.

Tier 1: Importaciones e inspecciones seguras

• Importación en solo lectura: zpool import -o readonly=on -N ... te permite inspeccionar sin cambiar el estado en disco.
• Importación sin montar: -N previene montajes de datasets para que puedas arreglar mountpoints o claves deliberadamente.
• Directorio de dispositivos explícito: -d /dev/disk/by-id evita la ruleta de nombres de dispositivo.

Tier 2: Overrides controlados para escenarios conocidos

• Importación forzada (-f): solo cuando has demostrado que el pool no está importado en otra parte y controlas todas las rutas.
• Log faltante (-m): si un SLOG dedicado ha desaparecido. Importa y luego remueve/reemplaza el vdev de log correctamente.
• Importar con raíz alternativa (-R /mnt): monta datasets bajo una raíz temporal para copiar en rescate sin alterar mountpoints normales.

Tier 3: Importaciones degradadas y evacuación de datos

• Importar degradado cuando exista redundancia y falte un dispositivo. Importa en solo lectura si no estás seguro de la salud de los discos restantes.
• Copiar inmediatamente discos VM críticos y configuraciones. Si un disco falla, resilverizar estresa el sistema; copiar también estresa; elige la vía que saque los datos más rápido.

Tier 4: Últimos recursos

• Recuperación extrema usando herramientas de depuración ZFS (zdb en modos más profundos) puede a veces recuperar información, pero en este punto debes tratar el pool como inestable y priorizar sacar los datos.
• Recuperación profesional para datos irremplazables sin redundancia. Si piensas “quizá sigamos intentando,” probablemente estés a punto de borrar la última metadata legible.

Una idea parafraseada de Werner Vogels: “Everything fails all the time.” ZFS está construido con esto en mente. Tus prácticas operativas también deberían estarlo.

Broma #1: ZFS no “pierde” tus discos; solo te fuerza a aprender finalmente qué cable va a qué sitio.

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

1) “No pools available to import” después de mover discos

Síntoma: zpool import no muestra nada.

Causa raíz: Estás escaneando el namespace de dispositivo equivocado (p. ej. detrás de multipath), o el HBA no presenta los discos, o arrancaste un kernel sin el driver.

Solución: Verifica discos con lsblk, revisa dmesg por attach del driver, escanea con zpool import -d /dev/disk/by-id, y resuelve multipath hacia un conjunto canónico único.

2) “Pool may be in use from another system” y la gente usa -f a ciegas

Síntoma: La importación pide -f.

Causa raíz: El acceso compartido es posible (SAN, JBOD compartido, dual-path accidental). O el hostid cambió por clonación.

Solución: Demuestra exclusividad (físicamente o vía control de acceso en el lado del target). Luego usa zpool import -f. Si el hostid es inestable, arregla /etc/hostid y evita clonar imágenes OS sin regenerarlo.

3) El pool se importa, pero el almacenamiento en Proxmox sigue muerto

Síntoma: zpool list muestra pool online, pero la GUI indica almacenamiento “inactivo” o las VMs no arrancan.

Causa raíz: Datasets no montados, mountpoints cambiados, claves de cifrado no cargadas, o /etc/pve/storage.cfg apuntando a un dataset que ya no existe.

Solución: zfs mount -a, revisa zfs get mountpoint,mounted, carga claves y valida /etc/pve/storage.cfg contra datasets reales y ZVOLs.

4) La importación falla solo en el arranque, pero la importación manual funciona

Síntoma: Tras reiniciar, el pool falta hasta que ejecutas un comando.

Causa raíz: El descubrimiento de dispositivos llega tarde (inicialización HBA, login iSCSI, multipath), y la importación basada en cache corre demasiado pronto o apunta a rutas obsoletas.

Solución: Habilita importación por escaneo, arregla el orden de iSCSI/multipath, regenera /etc/zfs/zpool.cache haciendo export/import limpio en una ventana de mantenimiento, y asegura que servicios dependan de la disponibilidad del almacenamiento.

5) “Unsupported feature(s)” en modo rescue

Síntoma: El pool es visible pero se niega a importar con lista de características.

Causa raíz: El entorno rescue usa OpenZFS más antiguo que el que requiere el pool.

Solución: Usa un kernel/userspace de Proxmox moderno que coincida con las características del pool. No “actualices el pool” en un host sin planear los entornos de recuperación.

6) Intento de importación degradada en un pool no redundante

Síntoma: Pool de un solo disco pierde su único disco, o mirror pierde un lado con corrupción silenciosa.

Causa raíz: Sin redundancia o ambos lados afectados; ZFS no puede conjurar bloques desde la física.

Solución: Recuperación a nivel hardware (recupera dispositivo), luego evacuación inmediata de datos. Si realmente se perdió, restaura desde backup. Si no hay backup, la solución es “aprender y presupuestar”.

Listas de verificación / plan paso a paso

Checklist A: Triage “El pool no se importa” en 15 minutos

1. Confirma exclusividad: asegúrate de que ningún otro host pueda ver los discos/LUNs.
2. Ejecuta zpool import y captura el mensaje exacto.
3. Verifica presencia de dispositivos: lsblk -o NAME,SIZE,MODEL,SERIAL y ls -l /dev/disk/by-id.
4. Escanea errores del kernel: dmesg -T | tail y busca timeouts/resets.
5. Intenta importación solo-lectura sin montar: zpool import -o readonly=on -N -d /dev/disk/by-id POOL.
6. Si se importa: revisa zpool status y decide “resilver vs copiar datos primero”.
7. Si no se importa: revisa feature flags, dispositivos faltantes y señales hostid/multihost.

Checklist B: Flujo de recuperación cuando falta un vdev pero existe redundancia

1. Importa en solo-lectura primero para validar que los dispositivos restantes son estables.
2. Recopila zpool status -v y contadores de error; si suben en reposo, el hardware sigue enfermo.
3. Reemplaza/restaura la ruta de disco faltante (swap de disco, reinsertar, arreglar multipath).
4. Importa en lectura-escritura y comienza resilver cuando confíes en que el bus está estable.
5. Monitorea progreso de resilver y logs del sistema por resets/timeouts.
6. Después del resilver, ejecuta scrub.

Checklist C: Fallos de importación en arranque

1. Confirma que la importación manual funciona de forma consistente.
2. Revisa systemctl status zfs-import-cache zfs-import-scan.
3. Verifica el orden para iSCSI/multipath (si se usa): los dispositivos deben existir antes de que corra la importación ZFS.
4. Regenera cachefile exportando/importando limpiamente durante una ventana de mantenimiento.
5. Reinicia una vez. Si funciona, reinicia de nuevo. No declares victoria tras un solo arranque.

Broma #2: “Funcionó después de un reinicio” no es una solución; es un giro argumental.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana corría Proxmox en dos nodos con un estante SAS compartido. Alguien lo etiquetó “como un SAN pero más barato”, y así sabes que se va a volver caro después.
Tenían ZFS sobre el estante compartido porque “funcionó bien en pruebas”.

Una tarde, un nodo se reinició tras una actualización de kernel. El pool no se importó automáticamente, y el ingeniero on-call hizo lo que hace toda persona impaciente:
ejecutó zpool import -f porque la herramienta lo sugería. El pool levantó. Las VMs arrancaron. Todos respiraron.

El otro nodo, que todavía tenía acceso físico al estante, también estaba configurado para importar el mismo pool por un experimento anterior.
No lo había importado en ese momento, pero ejecutaba monitorización y reglas udev que ocasionalmente tocaban los dispositivos.
Unas horas después, una tarea programada disparó un intento de importación allí también, y también usó -f, porque ese era el runbook.

Obtuvieron un clásico escenario de split-brain. ZFS hizo lo que pudo, pero ningún sistema de ficheros puede reconciliar dos escritores en los mismos bloques sin coordinación.
La corrupción no fue inmediata; se manifestó como errores “aleatorios” en discos VM y una desintegración lenta de la confianza.

La solución no fue ingeniosa. Fue de gobernanza: fencing, eliminar visibilidad compartida y parar el mito de que ZFS es un filesystem cluster. No lo es.
Reconstruyeron el pool desde backups. El cambio real fue político: “probar exclusividad” se volvió un paso no negociable.

Microhistoria 2: La optimización que salió mal

Otro equipo corría Proxmox con ZFS sobre LUNs iSCSI. Puede funcionar, pero es un pacto con el diablo: debes gestionar multipath consistentemente y evitar churn de dispositivos.
Quisieron importaciones y arranques más rápidos, así que ajustaron cosas: fijaron imports al cachefile, deshabilitaron scan import y recortaron delays de arranque “innecesarios”.

Funcionó hasta que un failover rutinario del controlador SAN hizo que las rutas de LUN aparecieran unos segundos más tarde de lo habitual durante el arranque.
zfs-import-cache corrió temprano, no vio los dispositivos esperados y falló. Como scan import estaba deshabilitado, nadie reintentó.
Proxmox arrancó sin almacenamiento. El cluster consideró que el nodo estaba vivo pero vacío, combinación entretenida.

El on-call hizo una importación manual y todo funcionó. Esa es la trampa: las soluciones manuales te hacen pensar que el sistema subyacente es confiable.
Pero siguió pasando en cada cold boot, solo en días en que el SAN quería hacer drama.

La solución final fue aburrida: habilitar scan import como fallback, añadir dependencias para que iSCSI login y multipath se estabilicen antes de zfs-import,
y regenerar el cachefile tras confirmar nombres by-id estables. El arranque ganó unos segundos; la disponibilidad dejó de ser emocionante.

Microhistoria 3: La práctica correcta y aburrida que salvó el día

Una compañía del sector financiero corría Proxmox en discos de arranque en espejo y un pool ZFS separado para VM storage. Nada exótico: HBAs en modo IT, discos con WWN,
datasets con nombres sensatos y scrubs mensuales enviados a un buzón que nadie leía—hasta que lo hicieron.

Una mañana tras un evento de energía, un nodo se negó a importar el pool VM. El error fue “one or more devices is currently unavailable.”
En vez de agitarse, siguieron su checklist: confirmar inventario de dispositivos, revisar dmesg, intentar importación en solo-lectura.
El pool se importó degradado; un disco había muerto.

El detalle clave: por hacer scrubs regularmente, ya sabían que los discos restantes estaban limpios la semana anterior.
Eso cambió la evaluación. Importaron lectura-escritura, reemplazaron el disco fallado, resilverizaron y luego volvieron a hacer scrub.
El downtime de VMs fue acotado a la ventana de mantenimiento, no a un cambio de carrera.

El postmortem fue casi aburrido. “Fallo de disco; la redundancia funcionó; historial de scrubs confirmó salud; reemplazo completado.”
Eso es lo que quieres en operaciones: una historia que nadie quiere oír porque nada explotó.

Preguntas frecuentes

1) ¿Debo usar siempre zpool import -f si ZFS lo sugiere?

No. Usa -f solo cuando hayas probado que el pool no está importado en otra parte y ningún otro host puede escribir en esos dispositivos.
En almacenamiento compartido, importación forzada es cómo compras corrupción con urgencia.

2) ¿Qué suele significar “no pools available to import” en Proxmox?

ZFS no encontró etiquetas. Eso suele ser drivers faltantes, dispositivos ausentes, escaneo en el namespace equivocado (multipath vs crudo),
o simplemente no estás mirando los discos que crees.

3) Si puedo importar en solo-lectura, ¿eso garantiza que mi pool está seguro?

Es una fuerte señal de que la metadata principal es legible y coherente, pero no garantiza estabilidad futura.
El hardware puede degradarse bajo carga. Usa la importación en solo-lectura para inspeccionar, luego decide si resilverizar o evacuar datos primero.

4) ¿Por qué Proxmox a veces falla al importar en el arranque pero funciona manualmente?

Secuenciación de arranque. Los dispositivos aparecen tarde (init HBA, login iSCSI, multipath), mientras los servicios de importación ZFS corren temprano.
Arregla el orden y mecanismos de fallback; no dependas de “alguien ejecuta el comando”.

5) ¿Puedo “degradar” un pool ZFS para importarlo en un Proxmox más antiguo?

No. Si el pool tiene feature flags no soportadas por el entorno más antiguo, necesitas un entorno más moderno para importarlo.
Planifica las actualizaciones con las herramientas de recuperación en mente.

6) Pool importado pero datasets no montaron. ¿Es eso un fallo de importación?

Usualmente no. Es un problema de montaje/clave/mountpoint. Revisa zfs mount, zfs get mounted,mountpoint y keystatus de cifrado.
Proxmox puede parecer “caído” cuando en realidad está “bloqueado” o “no montado”.

7) ¿Es seguro importar un pool con dispositivos faltantes?

Si existe redundancia y ZFS reporta réplicas suficientes, puede ser lo suficientemente seguro proceder—especialmente en solo-lectura al principio.
Si no hay redundancia, “device missing” suele significar “datos perdidos”.

8) ¿Borrar errores con zpool clear ayuda en problemas de importación?

Rara vez. Borra contadores de error y puede reactivar un dispositivo tras fallos transitorios, pero no arregla timeouts, cableado,
discos fallando, duplicación de multipath o características no soportadas.

9) ¿Cuál es la mejor estrategia de rutas de dispositivo para pools ZFS en Proxmox?

Usa /dev/disk/by-id (WWN o serial NVMe) consistentemente. Evita /dev/sdX.
Si usas SAN/multipath, asegúrate de que ZFS use un conjunto canónico de dispositivos (típicamente dm-id) y nunca ambos, nodos crudos y multipath.

10) ¿Cuándo es apropiado zpool import -m?

Cuando falta un dispositivo de log separado (SLOG) y esto impide la importación. Permite importar sin ese log.
Deberás remover/reemplazar el vdev de log ausente después para evitar advertencias y comportamientos extraños repetidos.

Conclusión: próximos pasos que puedes hacer hoy

“Cannot import pool” no es un único problema. Es una familia de síntomas. La ruta más rápida es un triaje disciplinado:
verifica dispositivos, lee la queja exacta de ZFS, importa en solo-lectura cuando haya dudas, y solo escala a importaciones forzadas/degradadas con un argumento de seguridad claro.

Pasos prácticos que reducen dolor futuro:

• Estandariza en el uso de /dev/disk/by-id para todos los pools y documenta el mapeo WWN → bahía física.
• Haz “demostrar exclusividad” obligatorio antes de usar -f en cualquier almacenamiento con capacidad compartida.
• Prueba la recuperación usando un entorno moderno que pueda importar el conjunto de features de tu pool (especialmente cifrado).
• Habilita y monitoriza scrubs, y trata los informes de scrub como señales operativas, no ruido de fondo.
• Arregla el orden de arranque si dependes de iSCSI/multipath; las importaciones manuales no son un SLO.

Cuando estés en el incidente: recopila evidencia primero, luego actúa. ZFS normalmente te dirá qué está mal. Solo tienes que escucharlo más tiempo del que tu adrenalina permite.