InforSupports

Recuperar datos de un backup .vma dividido en partes (Proxmox 8/9)

Written by

Francisco

in

Se tiene un respaldo de una máquina virtual de Proxmox dividido en 14 partes de exactamente 20 GB cada una (a excepción de la última, que pesa poco más de 11 GB). El peso total combinado es de aproximadamente 291.8 GB.

Limitaciones identificadas

  • No se puede montar como un ISO: los respaldos de Proxmox usan un formato empaquetado propietario llamado .vma que Linux no entiende nativamente con el comando mount. Además, la imagen contiene una tabla de particiones interna completa, no un sistema de archivos plano.
  • Espacio en disco: para procesarlo de forma manual en una PC externa, se requiere al menos el doble de espacio (~292 GB extra para la unión, y otros ~292 GB si se extrae el disco virtual completo).

¿Qué es realmente un archivo .vma?

.vma (Virtual Machine Archive) es el formato de contenedor que usa vzdump, la herramienta de respaldo nativa de Proxmox, para empaquetar en un solo archivo: la configuración de la VM (qemu-server.conf), y el contenido crudo de cada disco virtual asociado. No es un sistema de archivos por sí mismo — es un contenedor que hay que extraer primero con la herramienta vma para llegar al disco virtual real (típicamente un .raw), que ya sí contiene una tabla de particiones montable.

Paso 1: unir las partes secuenciales

Como los archivos terminan en sufijos alfabéticos ordenados (.part-aa hasta .part-an), se utiliza el comodín de Bash para unirlos en el orden correcto dentro de un solo contenedor comprimido:

cat vzdump109.part-* > vzdump109.vma.zst

Paso 2: extraer y montar el contenido

Escenario A — Si estás en un Linux externo (sin Proxmox)

Para este método necesitas instalar herramientas de descompresión y utilidades para interactuar con sistemas de archivos virtuales (guestfs-tools):

# 1. Descomprimir el contenedor VMA de Proxmox
unzstd vzdump109.vma.zst

# 2. Extraer el disco virtual interno a una carpeta de destino
vma extract vzdump109.vma ./carpeta_destino

# 3. Montar de forma segura (solo lectura) la partición interna del disco virtual
mkdir /mnt/disco_vm
guestmount -a ./carpeta_destino/disk-drive-scsi0.raw -m /dev/sda1 --ro /mnt/disco_vm

Una vez hecho esto, los archivos de la VM quedan accesibles directamente en la ruta /mnt/disco_vm.

Escenario B — Si tienes acceso a un servidor Proxmox funcional (método rápido)

Si dispones de un nodo Proxmox funcional, la vía óptima evita el duplicado de almacenamiento en comandos manuales:

  1. Mueve el archivo final vzdump109.vma.zst al directorio de dumps del servidor (usualmente /var/lib/vz/dump/).
  2. Desde la interfaz web de Proxmox, restaura la VM asignándole un ID genérico que no esté en uso (ej. 999). No enciendas la máquina virtual.
  3. Accede por la terminal SSH de Proxmox y monta directamente el volumen lógico o archivo de disco asignado a esa VM para extraer la información de manera local, sin necesidad de ocupar espacio extra extrayendo archivos .raw.

También se puede hacer el mismo proceso por línea de comandos, sin pasar por la interfaz web, usando qmrestore directamente:

qmrestore /var/lib/vz/dump/vzdump109.vma.zst 999

¿Esto aplica igual en Proxmox 9?

Sí — Proxmox VE 9 mantiene el mismo formato .vma y las mismas herramientas (vma, qmrestore, guestmount) sin cambios en el procedimiento descrito arriba. La documentación oficial de vzdump y qmrestore para la versión actual sigue usando exactamente esta sintaxis.

Hay un caso puntual a tener en cuenta si el respaldo fue creado en un host Proxmox 8.x y se intenta restaurar directamente en un host 9.x: hay reportes en el foro oficial de un error wrong vma extent header checksum durante la restauración cruzada entre versiones. El workaround confirmado es hacer el proceso en dos etapas:

  1. Descomprimir el archivo .vma.gz o .vma.zst a un .vma plano en el host 8.x (donde la restauración funciona sin problema):
gunzip -c /path/to/backup/vzdump-qemu-VMID-DATE.vma.gz > /mnt/pve/NFS/temp_restore/vzdump-qemu-VMID-DATE.vma
  1. Mover ese .vma ya descomprimido al host 9.x y restaurarlo desde ahí con qmrestore, evitando que el 9.x tenga que descomprimir el archivo original.

Si el respaldo y la restauración se hacen ambos dentro de la misma versión (8.x con 8.x, o 9.x con 9.x), no hay ningún problema de compatibilidad — el procedimiento de este artículo aplica sin modificaciones.

Notas finales

  • El Escenario B (con un Proxmox funcional disponible) siempre es preferible: evita duplicar 292+ GB de espacio en disco de forma innecesaria.
  • Nunca enciendas la VM restaurada con un ID temporal si el único objetivo es extraer archivos — así evitas conflictos de red (IP/MAC duplicada) con la VM original si esta sigue existiendo en otro lugar.
  • guestmount siempre debe usarse con --ro (solo lectura) al inspeccionar un disco extraído manualmente, para no arriesgar corromper el sistema de archivos interno por error.

More posts