Proxmox Backup Lab

Contexto y motivación

Monté este lab para practicar la parte operativa, respaldar y verificar, no solo configurar.

Ansible administra el hipervisor Proxmox por su API y define todo el ciclo de vida como código, de forma idempotente. Crea el bridge de red aislado, una plantilla cloud-init de Debian y clona tres VMs que se hablan entre sí, un DNS interno con bind9, un web con nginx y HTTPS y un fileserver con Samba.

La capa que da nombre al proyecto es la de backup y recuperación. Un job de vzdump respalda las tres VMs con retención, y un par de scripts provocan un desastre a propósito, destruyen por completo una VM y la restauran comprobando que vuelve a arrancar con su IP, sus datos y su servicio intactos.

Tecnologías

Debianbind9nginxSambavzdumpBash

Características principales

  • Hipervisor Proxmox VE gestionado por su API con Ansible, idempotente de punta a punta
  • Red interna aislada (vmbr1, 10.10.10.0/24) con NAT, creada por código
  • Plantilla cloud-init de Debian y clonado de tres VMs
  • DNS interno con bind9, web con nginx y HTTPS, y fileserver con Samba
  • Backups de VM completa con vzdump programado y retención
  • Escenario de desastre que destruye una VM y la restaura verificando IP, datos y servicio
  • Runbook con los procedimientos de recuperación documentados

Galería

Conclusión

Es un entorno de laboratorio y lo digo en el repositorio. El hipervisor corre anidado sobre VMware Workstation, hay un solo nodo y las credenciales del token de API van en un fichero de secretos fuera del control de versiones.

Lo que de verdad me llevo no es montar los servicios, sino cerrar el ciclo. Una cosa es hacer un backup y otra provocar la pérdida a propósito y demostrar, con un script que lo verifica solo, que los datos vuelven. Ese es el sello del proyecto, respaldar y verificar.

Enlaces

Ver código en GitHub