Problema

En entornos Proxmox es frecuente cambiar el disco de arranque o añadir un pool ZFS para alojar máquinas virtuales y contenedores. Cuando los backups están almacenados en un Proxmox Backup Server (PBS) y la infraestructura original usaba LVM, la restauración directa a un pool ZFS puede colgar indefinidamente. El proceso se queda en recovering backed‑up configuration from pbs:backup… y nunca aparecen mensajes en dmesg ni en los logs de tareas. El mismo backup se restaura sin problemas si el destino sigue siendo LVM.

Este patrón ocurre cuando Proxmox intenta crear los discos de la VM/CT en un tipo de almacenamiento que no está configurado o no es compatible con el pool ZFS, provocando un deadlock interno.

Causa

  1. Almacenamiento ZFS no registrado en storage.cfg
    Proxmox solo puede escribir imágenes en storages declarados. Si el pool ZFS existe pero no está añadido como tipo zfs con los contenidos images,rootdir,backup, el backend de restauración busca un LV en LVM y espera indefinidamente.

  2. Dataset ZFS inexistente o con mountpoint=none incorrecto
    El dataset donde se guardan los discos debe estar creado con mountpoint=none y ser accesible bajo el nombre del pool. Si falta, la llamada a zfs create falla silenciosamente y la tarea se bloquea.

  3. Espacio insuficiente o cuotas activas
    ZFS puede rechazar la creación de un nuevo volumen si el pool está casi lleno o si existen cuotas que impiden la expansión. Proxmox no muestra el error hasta que el proceso supera el timeout.

  4. Formato de disco incompatibles
    Los backups pueden contener discos en formato raw mientras la política del pool ZFS está configurada para zvol o viceversa. La incongruencia obliga a Proxmox a intentar una conversión que nunca termina.

  5. Bloqueo de recursos ZFS por procesos externos
    Si otro proceso (por ejemplo, zfs send/recv en curso) mantiene un lock sobre el pool, la operación de creación de disco queda en espera.

Solución

1. Verificar salud del pool ZFS

zpool status -x
zfs list -t filesystem | grep vmdata

El pool debe estar ONLINE y sin errores.

2. Crear dataset dedicado para discos de VM/CT

zfs create -o mountpoint=none rpool/vmdata

rpool es el nombre del pool; vmdata puede ser cualquier identificador.

3. Añadir el storage a Proxmox

Edite /etc/pve/storage.cfg o use pvesh:

pvesh create /storage \
  -storage zfs-data \
  -type zfs \
  -pool rpool \
  -content images,rootdir,backup \
  -nodes $(hostname)

Confirme que la entrada aparece con pvesh get /storage.

4. Restaurar con destino explícito

Para máquinas QEMU:

qmrestore /mnt/pbs/backup/vzdump-qemu-101-2024_06_01-00_00_00.vma.zst 101 --storage zfs-data

Para contenedores LXC:

pct restore 102 /mnt/pbs/backup/vzdump-lxc-102-2024_06_01-00_00_00.tar.lzo --storage zfs-data

El flag --storage fuerza a Proxmox a crear los discos en el pool ZFS recién registrado.

5. Ajustar formato si es necesario

Si el backup contiene raw y el pool está configurado para zvol, añada --format raw o convierta el dataset:

zfs set volmode=dev rpool/vmdata

Para qcow2 use --format qcow2 en el comando de restauración.

6. Desactivar procesos que bloqueen el pool

Antes de iniciar la restauración, asegúrese de que no haya zfs send activos:

ps aux | grep zfs | grep send

Mate cualquier proceso que no sea crítico.

7. Alternativa: migrar discos con ZFS nativo

Si el backup sigue colgando, copie directamente los discos con zfs send/recv y luego registra la VM manualmente:

zfs send rpool/old/vm-101-disk-0@snap | zfs recv rpool/vmdata/vm-101-disk-0
qm set 101 --scsi0 zfs-data:vm-101-disk-0

Esta ruta evita el backend de PBS y prueba la integridad del pool.

Cuándo aplicar esta solución

  • Síntomas: la tarea de restauración se queda en recovering backed‑up configuration >30 s, sin actividad en dmesg ni en /var/log/pve/tasks/.
  • Entorno: nodo Proxmox con pool ZFS recién creado o migrado, backups en PBS, origen LVM.
  • Aplicable: cualquier versión de Proxmox que soporte ZFS (p.ej., 7.x+). No funciona si el nodo está en modo cluster y el storage ZFS está definido solo en un nodo; debe estar replicado o definido en todos los nodos que participen.
  • Exclusiones: si el backup proviene de un pool ZFS y se restaura a LVM, la causa suele ser distinta (compatibilidad de formato) y la solución aquí no es pertinente.

Código

# 1. Salud del pool
zpool status -x
# 2. Dataset para discos
zfs create -o mountpoint=none rpool/vmdata
# 3. Registro en Proxmox
pvesh create /storage -storage zfs-data -type zfs -pool rpool -content images,rootdir,backup -nodes $(hostname)
# 4. Restaurar VM
qmrestore /mnt/pbs/backup/vzdump-qemu-101-2024_06_01-00_00_00.vma.zst 101 --storage zfs-data
# 5. Restaurar LXC
pct restore 102 /mnt/pbs/backup/vzdump-lxc-102-2024_06_01-00_00_00.tar.lzo --storage zfs-data

Verificación

  1. Tarea completada: pveam status o la vista de tareas muestra OK.
  2. Disco en ZFS: zfs list -t volume | grep vm-101 debe listar los volúmenes creados.
  3. VM/CT arrancable: inicie la máquina desde la UI de Proxmox y confirme que el sistema operativo arranca sin errores.
  4. Logs: journalctl -u pvedaemon -f no debe contener mensajes de timeout o “failed to allocate volume”.

Notas adicionales

  • Cuando se usa ZFS con compression=lz4, los backups comprimidos en PBS (.zst) se descomprimen automáticamente; no es necesario habilitar compresión adicional en el dataset.
  • Si el pool está en espejo (mirror), asegúrese de que ambos discos estén en buen estado; un disco degradado puede ralentizar la creación de volúmenes y provocar timeouts.
  • En clústers, sincronice /etc/pve/storage.cfg entre nodos antes de iniciar la restauración; de lo contrario, la tarea puede quedar atrapada en un lock de configuración distribuida.
  • Evite montar el pool bajo /mnt si ya existen subdirectorios con el mismo nombre; use rutas únicas para evitar colisiones de nombres de dataset.