Playbook de recuperación ante desastres para Proxmox: reconstruir el clúster desde PBS, imágenes de VM y configuración

Un Disaster‑Recovery‑Playbook para Proxmox es imprescindible para cualquier responsable de operaciones: este playbook describe de forma práctica cómo reconstruir un clúster de Proxmox tras una pérdida total o una avería grave utilizando Proxmox Backup Server (PBS), imágenes de VM y archivos de configuración. Está dirigido a administradores, ingenieros de sistemas, operadores y proveedores técnicos de servicios TI y se centra en la operación, las interfaces, las comprobaciones y las estrategias de retroceso. La palabra clave foco Disaster‑Recovery‑Playbook für Proxmox se coloca deliberadamente en la introducción, porque refleja con precisión la intención de búsqueda y la utilidad práctica del artículo.

Disaster‑Recovery‑Playbook für Proxmox: Por qué un playbook y cuándo entra en acción

Un playbook aporta claridad en situaciones de estrés: define el orden, las responsabilidades, los tiempos y las comprobaciones. Se aplica cuando el clúster productivo ya no arranca, /etc/pve se ha perdido, Corosync no encuentra quórum o el almacenamiento primario ha sufrido daños irreparables. Requisito central es que disponga de backups válidos en PBS y de copias de las configuraciones del clúster (p. ej., de una rutina de exportación automatizada).

Aclaración de términos (breve)

Proxmox VE es la plataforma de virtualización. Proxmox Backup Server (PBS) es la appliance de backups dedicada para snapshots y copias con deduplicación. pmxcfs es el sistema de archivos de configuración distribuida (configuración del plano de control) de Proxmox; Corosync es la capa de comunicación/quórum del clúster. Las configuraciones de VM residen en /etc/pve/qemu-server/ (KVM) y /etc/pve/lxc/ (LXC).

Preparación: requisitos, roles y prioridades

Antes de iniciar una RESTauración, aclare estos puntos:

• RTO/RPO por categoría de VM: defina qué VMs deben reconstruirse inmediatamente y cuáles más tarde.
• Medios disponibles: acceso al repositorio PBS, copias de archivo y, en su caso, copias offsite.
• Roles: Incident Lead, Storage Operator, Network Operator, PBS‑Operator, App‑Owner.
• Comunicación: canales, mensajes de estado y reglas de change‑freeze durante la recuperación.

Priorice: comience por la RESTauración del plano de control, luego el almacenamiento, a continuación las VMs críticas y, por último, los sistemas menos críticos.

Análisis inicial: determinar el alcance

Analice de forma sistemática el alcance del fallo: hardware muerto, pmxcfs dañado, partición de red o PBS perdido. Compruebe si nodos individuales son accesibles y si los repositorios PBS son alcanzables por SSH/HTTPS. Documente el estado encontrado y abra un log de incidentes.

RESTaurar el plano de control (pmxcfs/Corosync)

El plano de control gestiona las configuraciones del clúster. Si al menos un nodo está intacto, compruebe el estado:

pvecm status
systemctl status pve-cluster
systemctl status corosync

Si no hay ningún nodo disponible, monte una nueva primera node (Seed Node). PRESTe atención exacta al hostname y al plan de IP, porque Corosync y DNS/hosts dependen de una resolución de nombres consistente. Inicialice un clúster solo si no dispone de otra fuente de pmxcfs:

pvecm create mycluster

Nota: Crear un nuevo clúster sobrescribe un pmxcfs existente. Si dispone de una copia segura de /etc/pve o de un archivo de exportación, prefiera RESTaurar esos datos en lugar de crear uno nuevo.

Reconstruir pmxcfs desde backup

Si dispone de un backup consistente de /etc/pve o de una exportación de pmxcfs, RESTaure esos archivos en la Seed‑Node. El procedimiento típico es un tar‑archivo de la estructura /etc/pve, que copia a la Seed‑Node y, a continuación, reinicia el servicio pve‑cluster:

# auf Seed‑Node
rsync -av --progress /mnt/backup/etc-pve-backup/ /etc/pve/
systemctl RESTart pve-cluster
systemctl RESTart corosync

Por qué: /etc/pve es el plano de control; sus archivos definen IDs de VM, asignaciones de almacenamiento y la red. Riesgos: estados de versión inconsistentes o alias de almacenamiento ausentes pueden impedir que los nodos se unan correctamente.

Corosync, Quorum und Fencing

Los problemas de quorum son trampas habituales. Evite el Split‑Brain probando el Fencing (desconexión automática de un nodo que, desde la perspectiva del clúster, es defectuoso). Si utiliza un QDevice (dispositivo de Quorum externo), asegúrese de su accesibilidad.

Compruebe el estado del quorum:

pvecm status
# oder
corosync-cmapctl | head

Si un nodo ya no es alcanzable, elimínelo de forma ordenada o ajuste los votos esperados, pero documente cada paso y tenga preparados los comandos de reversión.

PBS: Zugriff prüfen und Repository wiederherstellen

Asegúrese de que los repositorios de PBS estén disponibles. Verifique accesibilidad, certificados y credenciales de usuario. Si PBS ha quedado destruido, reinstale PBS y sincronice los archivos del datastore (rsync o Storage‑Replica). Copie archivos solo si entiende cómo PBS utiliza sus estructuras de datos internas (chunks, indexes): una copia incompleta puede corromper los repositorios.

# Beispiel: rsync eines PBS‑Datastores (nur, wenn Storage‑Kopie valide ist)
rsync -av --progress /mnt/offsite/pbs-datastore/ /var/lib/proxmox-backup/datastore/

Validación: utilice la WebUI de PBS o la CLI para listar los datastores y snapshots antes de iniciar las RESTauraciones.

VM‑RESTore‑Strategien und detaillierte Umsetzung

Elija, según la situación, entre tres opciones:

1. qmRESTore: RESTauración directa de archivos vzdump, genera la configuración de la VM y los discos.
2. qm importdisk + qm set: Importación de imágenes de disco crudas y posterior configuración manual de la VM.
3. pct RESTore: Para contenedores LXC con comprobaciones de bind‑mounts.

qmRESTore – Empfehlung für getestete VMs

qmRESTore /backup/vzdump-qemu-101-2026_01_01.vma.zst 101 --storage local-lvm
# optional: sofort starten
qm start 101

Riesgos: qmRESTore espera Storage‑IDs coincidentes. Si el storage de destino tiene otro nombre, cree alias de almacenamiento temporales o utilice qm importdisk.

qm importdisk – flexibler bei Storage‑Mapping

qm create 101 --name RESTored-101 --memory 4096 --cores 4 --net0 virtio,bridge=vmbr0
qm importdisk 101 vm-101-disk-1.qcow2 local-lvm
qm set 101 --scsi0 local-lvm:vm-101-disk-1
qm set 101 --boot c --bootdisk scsi0

Ventaja: conserva el control sobre pools Thin/Thick y tipos de storage. Después de la importación puede faltar la configuración meta de la VM (cloud‑init, qemu‑agent). Añádala manualmente o mediante un script plantilla.

Container (LXC) – pct RESTore

pct RESTore 102 /backup/vzdump-lxc-102-2026_01_01.tar.lzo --storage local
pct set 102 --net0 name=eth0,bridge=vmbr0,ip=dhcp
pct start 102

Compruebe bind‑mounts, perfiles AppArmor y privilegios tras la RESTauración.

Datenbanken und konsistente Backups

Las VM de bases de datos requieren pasos de recuperación cuidadosamente ajustados: o bien dispone de snapshots consistentes (quiesced backups) o realiza pasos adicionales de recuperación de BD (WAL‑Replay, Replikations‑Rebuild). En PostgreSQL, por ejemplo, verifique los segmentos WAL y, si procede, ejecute pasos PITR. Para MySQL, compruebe las posiciones del Binlog y prefiera, cuando sea posible, una reinicialización de la replicación frente a una reparación compleja del Binlog.

Cifrado: encabezado LUKS y gestión de claves

Si los volúmenes de disco estaban cifrados, el encabezado LUKS y el material de claves son críticos. Guarde el encabezado LUKS por separado. Si el encabezado está dañado, el acceso a los datos suele ser imposible. Documente y pruebe los mecanismos de desbloqueo remoto (p. ej. Network‑Unlocked LUKS o servidores de claves).

Tipos de almacenamiento: LVM, ZFS, Ceph – particularidades

Cada tipo de almacenamiento tiene sus propias reglas de recuperación:

• LVM: Active las Volume‑Groups y verifique los Thin‑Pools. Utilice lvdisplay y vgchange -ay.
• ZFS: Importe los pools con zpool import -f y compruebe errores con zpool scrub.
• Ceph: Ponga primero los monitores (MON) en línea, verifique ceph -s y RESTaure los OSDs. La recuperación de un clúster Ceph puede ser compleja; planifique tiempo suficiente y siga las mejores prácticas de Ceph.

# Beispiel: LVM aktivieren
vgchange -ay
lvdisplay
# Beispiel: Ceph Status prüfen
ceph -s

Conflictos de configuración: Storage‑IDs, MACs y redes

Los problemas habituales tras un RESTore son Storage‑ID‑Mismatch y direcciones MAC duplicadas. Revise /etc/pve/qemu-server/*.conf en busca de identificadores de almacenamiento obsoletos y ajústelos. Ejemplo de una VM‑conf (extracto):

# /etc/pve/qemu-server/101.conf
boot: cdn
cores: 4
memory: 4096
scsi0: local-lvm:vm-101-disk-1,size=50G
net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0

Si las direcciones MAC causan conflictos, cámbielas antes del arranque y documente los ajustes. Use qm set para el cambio en lugar de la manipulación directa de archivos, cuando sea posible.

Validación y pruebas de humo (detalladas)

La validación no es opcional. Para cada VM RESTaurada realice al menos:

1. Revise la consola serial / el registro de arranque en busca de errores del kernel (GUI/Web o qm monitor).
2. Pruebas de red: ping, traceroute, resolución DNS y comprobaciones de puertos.
3. Chequeos de aplicaciones: estado HTTP/HTTPS, pruebas de conexión a la base de datos, comprobar tareas en segundo plano.
4. Integridad de datos: sumas de comprobación de directorios críticos o comprobaciones de la aplicación (p. ej. SELECT COUNT(*) para tablas con un valor de referencia).

# Beispiel Smoke‑Test
ssh admin@vm-ip 'systemctl is-active postgresql && curl -sfS http://localhost:8080/health'
# Prüfsummevergleich
ssh admin@vm-ip 'sha256sum /var/lib/app/data/important.db | cut -d" " -f1'

Automatización y scripts: robustos, idempotentes y auditados

Automatice tareas recurrentes, pero no las decisiones críticas. Un script Bash idempotente para RESTauración por lotes reduce errores, registra los pasos y permite una ejecución controlada. Ejemplo (extendido):

#!/bin/bash
# batch_RESTore_checked.sh
set -euo pipefail
MAPFILE=${1:-RESTore-map.csv}
LOG=/var/log/proxmox-recovery.log
exec &> >(tee -a "$LOG")
while IFS=, read -r backup vmid storage ; do
  echo "[INFO] RESToring $backup to VM $vmid on $storage"
  if [ ! -f "$backup" ]; then
    echo "[WARN] Backup $backup missing, skipping"
    continue
  fi
  # Quick storage check
  if ! pvesm status | grep -q "$storage" ; then
    echo "[ERROR] Storage $storage not present, aborting for $vmid"
    continue
  fi
  qmRESTore "$backup" "$vmid" --storage "$storage" || { echo "[ERROR] qmRESTore failed for $vmid"; continue; }
  echo "[OK] RESTore triggered for $vmid"
done < "$MAPFILE"

Estrategia de contingencia: ¿Qué ocurre si la RESTauración falla?

Tenga un plan B: si las RESTauraciones fallan, puede:

• Provisionar manualmente las VMs (instalador + importación de datos) para servicios críticos para el negocio.
• Recurrir a réplicas de solo lectura o a snapshots antiguos.
• Relajar temporalmente ajustes de red/seguridad si impiden el arranque (p. ej., reglas de firewall).

Es importante definir límites de tiempo y puntos de decisión: tras X horas de recuperación, el responsable de incidentes cambia al Plan B para cumplir el RTO global.

Sección especial Hyper‑V: lecciones transferibles

Aunque este playbook está centrado en Proxmox, algunos principios se pueden aplicar a Hyper‑V. En Hyper‑V son críticos las exportaciones VHD(X), el estado de la configuración de Hyper‑V (export/import) y los hosts Hyper‑V (failover cluster). Son importantes: exportaciones coherentes de VMs, verificar CSV/NAS/SMB mounts y el mapeo de red (vSwitch). Pruebe los flujos de trabajo de importación/attach en un entorno de preproducción antes de depender de ellos en una situación de emergencia.

Post‑Recovery: endurecimiento, lecciones aprendidas, documentación

Tras la RESTauración, realice un análisis post‑mortem, documente los cambios y ajuste backups, pruebas y responsabilidades. Adapte RTO/RPO a métricas realistas obtenidas del ejercicio y planifique ejercicios de seguimiento para evitar regresiones.

Lista de comprobación práctica (compacta)

1. Definir alcance & prioridades.
2. Reconstruir el plano de control (pmxcfs/corosync) o crear un seed‑node.
3. Comprobar / RESTaurar el repositorio PBS.
4. Integrar los storage‑targets (comprobar LVM/ZFS/Ceph).
5. RESTaurar selectivamente las VMs con qmRESTore/qm importdisk/pct RESTore.
6. Realizar la recuperación de bases de datos (WAL/Binlog/PITR).
7. Pruebas de humo (smoke tests), comprobaciones de integridad y verificaciones de aplicaciones.
8. Documentar las lecciones aprendidas y planificar el seguimiento.

Conclusión

Un playbook de recuperación ante desastres sólido para Proxmox es más que un conjunto de comandos: es un documento operativo con prioridades, roles, comprobaciones y estrategias de contingencia. Pruebe regularmente, mantenga actualizados los exports de pmxcfs y los accesos a PBS, y automatice las comprobaciones de soporte, pero no las decisiones críticas de recuperación. Así reduce el RTO y evita errores costosos en un incidente real.

Esta guía está pensada como complemento modular de su documentación operativa. Adáptela a su topología de almacenamiento, a los objetivos RTO/RPO y a los canales de comunicación internos, y realice ejercicios de RESTauración periódicos.

Integraciones, secretos y aspectos operativos

A menudo subestimadas: las integraciones de red e infraestructura determinan si una RESTauración llega a ser realmente productiva. RESTaure primero las infraestructuras centrales —DNS, DHCP, NTP y PKI— antes de arrancar las capas de aplicación. Si falta DNS, las VMs arrancan, pero no son localizables para los servicios; la ausencia de marcas temporales (NTP) puede romper la replicación de bases de datos.

Asegure el material de claves y los certificados separados del PBS y documente los procedimientos de Unseal/Unlock (p. ej. HashiCorp Vault, KMIP). Los almacenes de secretos externos deberían figurar en el Playbook con pruebas de acceso explícitas.

Nota práctica: ponga temporalmente las alarmas de monitorización en „maintenance“ para evitar avalanchas de alertas, y reregistre los hosts de forma selectiva tras Smoke‑Tests exitosos. Para aplicaciones Multi‑Tier, planifique ventanas de snapshot/RESTore coordinadas para mantener la consistencia entre base de datos y aplicación.

Audite cada paso de recuperación: registros, sumas de verificación, estados de versión y quién autoriza cambios — así el Playbook será fiable en operación y sólido desde el punto de vista organizativo.

Para este tema también son importantes la RESTauración de Vm‑Images y la recuperación de clústeres Proxmox. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en la práctica.