Problema

En muchos homelabs basados en Proxmox la configuración se construye a mano: puentes de red, entradas de DDNS, certificados, montajes NFS en /etc/fstab, scripts que esperan a que una VM de OMV esté operativa, etc. Cuando el nodo físico falla, todo ese trabajo desaparece y el proceso de volver a levantar el entorno puede tomar horas o incluso días. Los backups de máquinas virtuales (VM) y contenedores (LXC) suelen estar cubiertos, pero la capa de configuración del host queda sin protección. La pregunta recurrente es: ¿cómo mantener esa información recuperable y volver a la operatividad lo antes posible?

Causa

  1. Configuración ad‑hoc sin control de versiones – Editar archivos directamente en el nodo y confiar en copias de seguridad manuales genera desalineación y pérdida de historial.
  2. Falta de automatización – Los scripts de montaje NFS o de arranque de servicios se guardan en lugares dispersos y no se ejecutan automáticamente en un nuevo host.
  3. Dependencias externas no declaradas – Puentes, VLAN y reglas de iptables se crean con comandos puntuales; al reinstalar el nodo esas dependencias se olvidan.
  4. Documentación escasa – Sin un registro estructurado de qué cambios se hicieron y por qué, el equipo (aunque sea una sola persona) no tiene referencia para reproducir el entorno.

Estos factores aparecen con frecuencia en entornos de pruebas, laboratorios domésticos y pequeñas infraestructuras donde la prioridad es la rapidez de despliegue, no la gestión formal.

Solución

Una estrategia combinada de control de versiones, automatización declarativa y backups estructurados cubre la mayoría de los casos.

1. Centralizar la configuración en un repositorio Git

  • Agrupa todos los archivos de configuración del host bajo un mismo árbol:
    • /etc/network/interfaces.d/ (puentes)
    • /etc/fstab (montajes NFS)
    • /etc/pve/ (configuración de Proxmox)
    • Scripts personalizados en /usr/local/bin/ o /opt/scripts/
  • Usa un repositorio privado (GitLab, Gitea, o GitHub privado) y habilita GPG signing para validar cambios.
  • Cada commit representa un estado reproducible; al clonar el repo en un nuevo nodo puedes aplicar todo de una sola vez.

2. Describir la infraestructura con Ansible o Terraform (Proxmox provider)

  • Ansible: escribe playbooks que apliquen archivos de configuración, creen puentes, añadan entradas a fstab y desplieguen scripts.
  • Terraform: con el provider oficial de Proxmox puedes declarar VMs, LXC, redes y almacenamiento como código.
  • Mantén los playbooks/terraform files en el mismo repo que la configuración; así cualquier cambio queda versionado.

3. Automatizar los backups de la configuración

Aunque los archivos ya están en Git, es útil crear snapshots periódicos de /etc/pve y de los volúmenes de almacenamiento. Usa proxmox-backup-client:

proxmox-backup-client backup config --repository backup:myrepo --tag config-backup

Esto guarda una copia en el backup storage que puede restaurarse sin tocar Git.

4. Orquestar la recuperación

  1. Instala Proxmox en el nuevo hardware siguiendo la guía oficial.
  2. Clona el repo en /root/proxmox-config.
  3. Ejecuta el playbook o terraform apply.
  4. Restaura los backups de VMs/LXC con proxmox-backup-client restore.
  5. Verifica que los puentes y montajes NFS estén activos; los scripts de arranque se ejecutarán automáticamente si están declarados en systemd.

5. Documentar decisiones operativas

Mantén un README.md en el repo con:

  • Propósito de cada script.
  • Variables de entorno sensibles (ej. tokens de DDNS) y su ubicación segura (ej. HashiCorp Vault o age encrypted files).
  • Pasos de recuperación paso a paso.

Esto evita que la documentación se quede en notas sueltas.

Cuándo aplicar esta solución

  • Entornos con más de una VM/LXC donde la pérdida del nodo implica re‑creación manual de redes y montajes.
  • Homelabs que usan Proxmox como plataforma de pruebas y necesitan volver a operatividad en menos de una hora.
  • Equipos pequeños que prefieren una única fuente de verdad (Git) sobre documentos dispersos.

No es necesario si el nodo solo ejecuta contenedores efímeros y no hay configuraciones personalizadas; en ese caso los backups de máquinas pueden ser suficientes.

Código

# 1. Clonar el repositorio de configuración
git clone git@github.com:usuario/proxmox-config.git /root/proxmox-config
cd /root/proxmox-config

# 2. Aplicar la infraestructura con Ansible (ejemplo)
ansible-playbook -i inventory.ini site.yml

# 3. Restaurar backups de VMs/LXC (ejemplo para una VM)
proxmox-backup-client restore vm/101 --repository backup:myrepo --snapshot latest

# 4. Verificar puentes y montajes
ip link show br0
mount | grep nfs

Verificación

  1. Estado de red – ip a debe listar los puentes declarados (ej. br0, vmbr1).
  2. Montajes NFS – mount | grep nfs debe mostrar todas las entradas definidas en /etc/fstab.
  3. Servicios críticos – systemctl status pve-cluster y systemctl status pvedaemon deben estar activos.
  4. VM/LXC – Inicia una máquina de prueba (qm start 101 o pct start 201) y verifica que arranca sin errores.
  5. Git estado – git status dentro del repo debe estar limpio, indicando que la configuración aplicada coincide con la versión versionada.

Notas adicionales

  • Manejo de secretos: nunca almacenes contraseñas o tokens en texto plano dentro del repo. Usa git-crypt o almacenes externos como Vault y referencia los secretos mediante variables de entorno en los playbooks.
  • Backup de Git: habilita mirroring a otro servidor Git para evitar la pérdida del repositorio en caso de fallo del servidor de control de versiones.
  • Rotación de snapshots: configura políticas de retención en Proxmox Backup Server para evitar que el almacenamiento se llene; una regla típica es “keep daily for 7 days, weekly for 4 weeks, monthly for 12 months”.
  • Pruebas de recuperación: programa una fire drill mensual donde se destruye intencionalmente una VM y se restaura usando solo los backups y el repositorio Git. Esto asegura que el proceso funciona y que el personal está familiarizado con los pasos.

Con esta combinación de Git, IaC (Ansible/Terraform) y backups estructurados, la mayoría de los entornos Proxmox pueden recuperarse en minutos, manteniendo la documentación siempre actualizada y accesible.