Problema

En entornos de virtualización con Proxmox es frecuente que el host falle o que la capa de almacenamiento quede dañada. Cuando el pool de ZFS, los volúmenes LVM o los archivos de disco en un directorio Ext4/XFS presentan pérdida parcial de datos, la máquina virtual puede quedar inarrancable, pero los bloques que aún existen pueden contener información valiosa. El reto consiste en reconstruir la pila de almacenamiento lo suficiente como para extraer archivos, incluso si la configuración original no se puede importar o los snapshots están corruptos.

Causa

Las causas más habituales son:

  • Fallo de hardware: discos caídos en un RAIDZ o en un conjunto LVM, cables sueltos o controlador dañado. En RAIDZ la pérdida de uno o más discos supera la capacidad de paridad y evita la importación automática.
  • Corrupción de metadatos: daño en la tabla de volúmenes LVM, en el superblock de ZFS o en la tabla de inodos del host (Ext4/XFS). Suele aparecer tras apagados bruscos o actualizaciones del kernel que interrumpen la escritura.
  • Eliminación accidental de discos virtuales: borrado de archivos .raw, .qcow2 o .vmdk, o eliminación de snapshots dentro de Proxmox.
  • Daño parcial del disco virtual: sectores defectuosos que impiden que QEMU monte el archivo completo, aunque partes del sistema de archivos invitado sigan intactas.

Solución

Una estrategia basada en tres capas permite abordar la mayoría de los escenarios:

  1. Reconstruir la capa de almacenamiento del host

    • ZFS/RAIDZ: conectar los discos disponibles a otro servidor, usar zpool import -d /dev/disk/by-id -f -R /mnt/recovery <pool> para forzar la importación. Si faltan discos pero la paridad lo permite, ZFS seguirá funcionando en modo degradado.
    • LVM/LVM‑Thin: ejecutar vgscan --mknodes y vgchange -ay <vg> para activar volúmenes detectados. En caso de metadatos rotos, vgcfgrestore -f /etc/lvm/archive/<vg>_<timestamp>.vg <vg> puede revertir a una copia de seguridad interna.
    • Directory (Ext4/XFS): montar la partición con opciones de solo lectura y noload (mount -o ro,noload /dev/sdX1 /mnt/hostfs) para evitar que el journal intente reparar estructuras ya dañadas.

  2. Exponer los discos virtuales como dispositivos de bloque

    • ZVOL y LVM LV: ya aparecen como /dev/mapper/<name> y pueden ser inspeccionados directamente.
    • Archivos de disco: usar losetup --find --show -r /path/to/disk.qcow2 para crear un loop device, luego kpartx -a /dev/loopX para mapear particiones internas.

  3. Analizar el sistema de archivos invitado

    • Ejecutar testdisk o photorec contra el dispositivo de bloque para buscar estructuras NTFS, Ext4, XFS, etc.
    • Si el FS está parcialmente montable, montar con -o ro y usar extundelete (Ext4) o xfs_db -c "inode <num>" para recuperar inodos sueltos.
    • En snapshots de LVM‑Thin, montar cada snapshot por separado (mount /dev/vg/snap1 /mnt/snap1) permite extraer versiones anteriores sin revertir la VM completa.

Flujo resumido

Physical disks → host storage layer (ZFS/LVM/Ext4/XFS) → expose VM disk (ZVOL/LV/loop) → guest FS analysis → extract files

Cuándo aplicar esta solución

Aplicable cuando:

  • El host Proxmox no arranca o la configuración de almacenamiento está corrupta.
  • Al menos un disco del pool está disponible y la paridad permite reconstruir la matriz.
  • Los discos virtuales aparecen como archivos o volúmenes, aunque QEMU no los abra.
  • Necesitas recuperar archivos específicos o versiones anteriores sin restaurar toda la VM.

No aplicable si:

  • Todos los discos físicos están fallados y la pérdida supera la paridad (p.ej., RAIDZ2 con tres discos muertos).
  • El hardware del controlador está dañado y no permite leer bloques físicos.
  • Se ha sobrescrito intensivamente el almacenamiento después del incidente, reduciendo drásticamente la probabilidad de recuperación.

Código

# 1. Importar pool ZFS degradado
zpool import -d /dev/disk/by-id -f -R /mnt/recovery mypool

# 2. Activar volúmenes LVM (incluye thin)
vgscan --mknodes
vgchange -ay vg_proxmox

# 3. Montar partición host (Ext4/XFS) solo lectura
mount -o ro,noload /dev/sdb1 /mnt/hostfs

# 4. Crear loop device para archivo QCOW2
LOOPDEV=$(losetup --find --show -r /mnt/hostfs/vm-101-disk-0.qcow2)
kpartx -a $LOOPDEV

# 5. Analizar con testdisk (ejemplo NTFS)
testdisk /dev/mapper/loop0p1

# 6. Recuperar archivos borrados en Ext4
extundelete /dev/mapper/loop0p1 --restore-all

Verificación

  1. Comprobar que el pool o VG está activo: zpool status -v mypool o lvs -a.
  2. Listar dispositivos expuestos: lsblk debe mostrar los ZVOL/LV o los dispositivos loop con sus particiones.
  3. Montar temporalmente (solo lectura) y listar directorios: mount -o ro /dev/mapper/loop0p1 /mnt/guest && ls -l /mnt/guest. Si aparecen los archivos esperados, la capa de bloque está correcta.
  4. Ejecutar una recuperación de prueba: copiar un archivo recuperado a /tmp y abrirlo para validar integridad.

Notas adicionales

  • Detener escrituras inmediatamente: montar siempre en modo solo lectura y evitar cualquier operación que pueda sobrescribir bloques libres.
  • Copias de seguridad de metadatos LVM: el directorio /etc/lvm/archive guarda snapshots de la configuración; restaurarlos suele ser la forma más rápida de volver a un estado coherente.
  • Paridad y número de discos: en RAIDZ la regla es “n‑1 discos fallados para RAIDZ, n‑2 para RAIDZ2, n‑3 para RAIDZ3”. Superar ese límite implica pérdida total de datos.
  • Herramientas de bajo nivel: ddrescue puede clonar discos dañados antes de intentar la recuperación, preservando sectores defectuosos en un archivo de log para reintentos.
  • Snapshots ZFS: los snapshots son instantáneas de los ZVOL; pueden exportarse con zfs send <pool>/<zvol>@<snap> | zfs receive -F <dest> y montar el ZVOL resultante para inspección.
  • Thin provisioning: en discos QCOW2 o VMDK la ausencia de bloques asignados significa que los datos nunca existieron; la recuperación depende de que los bloques relevantes estén todavía presentes en el host.

Con este enfoque modular puedes abordar la mayoría de los incidentes de pérdida de storage en Proxmox sin necesidad de restaurar la máquina completa, centrándote en los datos que realmente importan.