Problema

En entornos de virtualización con Proxmox, la mayoría de las estrategias de recuperación se centran en clústeres o en la reinstalación manual del nodo. Cuando el propio hypervisor falla –por corrupción del bootloader, pérdida del rpool o daño del ESP– el proceso de volver a poner en marcha el servidor suele ser lento y propenso a errores. La falta de un método bare‑metal que capture la topología de discos, la configuración de ZFS y los ajustes de systemd-boot obliga a los administradores a reconstruir manualmente cada pieza antes de poder restaurar las máquinas virtuales.

El objetivo es disponer de un paquete de respaldo que, en caso de caída total del nodo, permita:

  1. Reinstalar el firmware mínimo (una pequeña imagen RAM) sin depender de la conectividad IPMI lenta.
  2. Re‑crear automáticamente la tabla de particiones, los ESP y los pools ZFS con sus propiedades no‑por‑defecto.
  3. Iniciar Proxmox y, a continuación, recuperar las VMs desde PBS.

El reto es que la solución debe ser reutilizable en cualquier instalación de Proxmox basada en ZFS, independientemente del número de discos o del tipo de espejo/raid‑z.

Causa

Los fallos que obligan a una restauración bare‑metal suelen originarse en:

  • Daño del ESP o del bootloader – systemd-boot y proxmox-boot-tool dependen de UUIDs exactos; cualquier cambio rompe el arranque.
  • Corruptela del rpool – ZFS detecta errores de checksum y, si el pool no está replicado, el nodo queda inoperativo.
  • Desalineación de la tabla de particiones – al añadir o remover discos, sgdisk puede dejar espacios sin definir, lo que confunde a proxmox-boot-tool.
  • Configuraciones locales de ZFS – compresión, recordsize, atime y otros atributos no se restauran con un simple zfs send del dataset raíz.
  • Dependencia de herramientas externas – scripts que asumen GRUB o MDADM fallan en instalaciones ZFS‑only.

En la práctica, la combinación de un ESP dañado y un rpool sin espejo deja al administrador sin un punto de partida fiable.

Solución

Una estrategia genérica consta de tres capas:

  1. Captura de metadatos

    • Exportar la tabla de particiones con sgdisk -p y guardarla en un archivo .pxar.
    • Listar los UUIDs de los ESP (blkid) y los atributos del pool (zpool get all, zfs get all).
    • Guardar variables de entorno que describan la topología (número de discos, tipo de RAID, nombre del pool).

  2. Imagen de arranque mínima

    • Construir una imagen Docker que incluya proxmox-backup-client-static, dhclient y un script de configuración de red.
    • Exportar la imagen como un ISO o como un archivo initramfs que pueda cargarse vía IPMI o USB.
    • La imagen debe montar temporalmente un directorio /mnt/backup y ejecutar el script de restauración.

  3. Script de restauración

    • Destruir la tabla de particiones existente (wipefs -a, sgdisk -Z).
    • Re‑crear la tabla a partir del archivo exportado (sgdisk -R).
    • Reconstruir los ESP con los UUID originales (sgdisk -U).
    • Crear el pool ZFS con la misma configuración (zpool create -o …).
    • Aplicar los atributos locales (zfs set …).
    • Importar el dataset raíz mediante zfs receive o, si se prefiere, mediante un zfs send comprimido.
    • Ejecutar proxmox-boot-tool para registrar los kernels y los ESP.

Todo el proceso puede ser orquestado por un único script que solicite al usuario los discos destino y el tipo de RAID (mirror, raidz). La lógica de decisión permite, por ejemplo, restaurar un pool espejo en un solo disco (degradado) o migrar de mirror a raidz si la infraestructura lo requiere.

Flujo resumido

  1. Boot con la imagen mínima → red → monta backup remoto.
  2. Descarga los archivos .pxar y .env.
  3. Wipe discos y recrea particiones.
  4. Recrea pool ZFS y aplica atributos.
  5. Importa dataset raíz.
  6. Actualiza bootloader con proxmox-boot-tool.
  7. Reboot y deja que PBS recupere VMs.

Cuándo aplicar esta solución

  • Entornos de producción con un solo nodo donde la alta disponibilidad se logra mediante backups externos y no mediante clústeres.
  • Instalaciones ZFS‑only que usan systemd-boot y proxmox-boot-tool.
  • IPMI limitado o conexiones de red inestables que hacen inviable una instalación completa desde ISO remota.
  • Política de recuperación rápida (menos de 30 min) después de un fallo total del nodo.

No es adecuada cuando:

  • El nodo usa MDADM, LVM o GRUB como bootloader.
  • Se necesita restaurar sub‑datasets específicos que no forman parte del rpool/ROOT.
  • La infraestructura depende de hardware propietario que impide el arranque desde USB o ISO personalizada.

Código

# 1. Exportar tabla de particiones y UUIDs
sgdisk -p /dev/sda > /tmp/partition_table.pxar
blkid -s UUID -o value /dev/sda1 > /tmp/esp_uuid.txt

# 2. Guardar atributos ZFS
zpool get all rpool > /tmp/rpool_props.txt
zfs get all rpool/ROOT > /tmp/root_props.txt

# 3. Generar .env con topología
cat <<EOF > /tmp/restore.env
DISKS="/dev/sda /dev/sdb"
POOL_NAME="rpool"
RAID_TYPE="mirror"
ESP_UUID=$(cat /tmp/esp_uuid.txt)
EOF

# 4. Script de restauración (simplificado)
#!/usr/bin/env bash
set -euo pipefail
source /tmp/restore.env

# Wipe y recrea tabla
wipefs -a $DISKS
sgdisk -Z $DISKS
sgdisk -R /dev/sda /tmp/partition_table.pxar
sgdisk -U 1:$ESP_UUID /dev/sda

# Crear pool con atributos guardados
zpool create -f -o ashift=12 -O compression=lz4 $POOL_NAME mirror ${DISKS// / } 
while read -r line; do
  prop=$(echo $line | awk '{print $1}')
  val=$(echo $line | awk '{print $3}')
  zpool set $prop=$val $POOL_NAME
done < /tmp/rpool_props.txt

# Recibir dataset raíz
zfs receive -F $POOL_NAME/ROOT < /mnt/backup/root_send.dat

# Registrar bootloader
proxmox-boot-tool refresh

reboot

Verificación

  1. Arranque exitoso – La máquina debe iniciar en el kernel recién registrado y mostrar el prompt de login de Proxmox.
  2. Comprobación del pool – zpool status debe listar el pool con el RAID deseado y sin errores.
  3. Validar atributos – zfs get all rpool/ROOT debe coincidir con los valores guardados en root_props.txt.
  4. ESP correcto – blkid debe mostrar el UUID almacenado en ESP_UUID.
  5. Acceso a PBS – Desde la UI de Proxmox, verifica que los backups de VMs aparecen y pueden ser restaurados.

Si alguna de estas pruebas falla, revisa los logs de proxmox-boot-tool (journalctl -u proxmox-boot-tool) y los mensajes de zpool import -a.

Notas adicionales

  • Deduplicación de backup – Guardar /var/lib/vz como archivo .pxar permite que pbzip2 o zstd eliminen duplicados antes de enviarlos a PBS.
  • Compatibilidad con versiones futuras – El script usa comandos genéricos (zpool create, zfs receive) que siguen siendo válidos en las próximas versiones de ZFS.
  • Recuperación parcial – Si sólo se necesita el dataset raíz, omite la recreación de los discos no involucrados; zpool import -d /dev/disk/by-id permite seleccionar discos específicos.
  • Seguridad – Almacena los archivos .pxar y .env en un bucket cifrado de PBS; el script los descarga mediante proxmox-backup-client con token de API de solo lectura.
  • Pruebas regulares – Programa una restauración de prueba mensual en hardware de laboratorio; los fallos inesperados suelen aparecer en la fase de proxmox-boot-tool refresh.

Con esta metodología, la restauración bare‑metal de un nodo Proxmox pasa de ser una operación manual de horas a un proceso automatizado que se puede ejecutar desde una pequeña imagen RAM, reduciendo significativamente el tiempo de inactividad.