Problema

En muchos homelabs la arquitectura de discos se reparte entre un SSD pequeño para el sistema base, un NVMe rápido para máquinas virtuales y un HDD tradicional para copias de seguridad y archivos ISO. Esa distribución funciona, pero a medida que se añaden VMs, plantillas y snapshots, aparecen cuellos de botella, pérdida de espacio inesperada y copias de seguridad que tardan demasiado. El reto es mantener una configuración de storage que sea sencilla, segura y que permita escalar sin sacrificar la disponibilidad del host.

Causa

Los problemas habituales provienen de tres áreas:

  1. Fragmentación de storage y mezcla de tipos de datos – Cuando los discos de sistema, VM y backup comparten el mismo pool, Proxmox puede colocar snapshots o plantillas en el disco equivocado, agotando espacio crítico.
  2. Política de backup insuficiente – Ejecutar backups completos en el mismo disco donde viven las VMs genera I/O intensivo y riesgo de corrupción si el disco falla.
  3. Red sin aislamiento – Usar un único bridge (vmbr0) para tráfico interno y externo obliga a que todas las VMs dependan del mismo segmento LAN, lo que complica la gestión de IP y la separación de tráfico de gestión.

Solución

1. Segmentar los storage pools

  • local-lvm (SSD 250 GB) – Reserva exclusivamente para el sistema operativo de Proxmox, paquetes y contenedores ligeros. Desactiva la creación automática de discos de VM en este pool.
  • nvme-data (NVMe 1 TB) – Crea un pool ZFS o LVM‑thin dedicado a discos de VM. Usa thin para que el espacio se asigne dinámicamente y evita sobresaturar el SSD.
  • hdd-backup (HDD 1 TB) – Monta como un directorio de backup (backup-hdd). Configura vzdump para que escriba allí y habilita compresión (gzip) para reducir I/O.

2. Definir una política de backup basada en frecuencia y tipo

Tipo Frecuencia Qué se respalda Comentario
Snapshot rápido Cada 4 h (VM en ejecución) Estado de la VM (snapshot) Almacénalo en nvme-data porque es rápido.
Backup incremental Diario Cambios desde el último backup completo Usa vzdump --mode snapshot --compress gzip --storage hdd-backup.
Backup completo Semanal Imagen completa de la VM Ejecuta fuera de horas pico; guarda en hdd-backup.

3. Automatizar con cron y systemd timers

Crea un timer que lance vzdump con los parámetros adecuados. Un ejemplo de unidad:

# /etc/systemd/system/proxmox-backup.timer
[Unit]
Description=Timer para backups de Proxmox

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/proxmox-backup.service
[Unit]
Description=Ejecuta vzdump para backups diarios

[Service]
Type=oneshot
ExecStart=/usr/sbin/vzdump --mode snapshot --compress gzip --storage hdd-backup --all

Activa con systemctl enable --now proxmox-backup.timer.

4. Añadir un bridge dedicado para gestión

Mantén vmbr0 para tráfico LAN de las VMs. Crea vmbr1 conectado a una VLAN o a una interfaz física separada para la gestión del host (SSH, GUI, API). Así, una caída de la red de usuarios no afecta al acceso al nodo Proxmox.

# /etc/network/interfaces.d/50-proxmox.cfg
auto vmbr1
iface vmbr1 inet static
    address 192.168.100.10/24
    bridge_ports none
    bridge_stp off
    bridge_fd 0

5. Monitorear espacio y salud de los discos

Instala smartmontools y zfs-auto-snapshot (si usas ZFS). Configura alertas por correo cuando el uso de cualquier pool supere el 80 %.

apt-get install smartmontools zfs-auto-snapshot
smartctl -a /dev/nvme0n1

Cuándo aplicar esta solución

  • Escenarios con varios discos de distinta velocidad – Si tu homelab combina SSD, NVMe y HDD, la segmentación evita que una VM agote el SSD.
  • Entornos donde la disponibilidad es crítica – Cuando necesitas que el host siga accesible aunque una VM falle o un backup se corra.
  • Cualquier configuración que use snapshots – Los snapshots en discos lentos generan latencia; moverlos al NVMe mejora la experiencia.

No es necesario si solo ejecutas una o dos VMs y el almacenamiento está en un único disco; la complejidad añadida superaría el beneficio.

Código

# Crear pool LVM thin en el NVMe
pvcreate /dev/nvme0n1
vgcreate vg-nvme /dev/nvme0n1
lvcreate -L 900G -T vg-nvme/nvme-thin

# Montar HDD como storage de backup
mkdir -p /mnt/backup-hdd
mount /dev/sdb1 /mnt/backup-hdd
pvesm add dir backup-hdd --path /mnt/backup-hdd --content backup

# Configurar vzdump para backup incremental diario
vzdump --mode snapshot --compress gzip --storage backup-hdd --all --maxfiles 7

Verificación

  1. Espacio disponible – Ejecuta pvesh get /storage y verifica que cada pool muestra la capacidad esperada.
  2. Backup exitoso – Revisa el log de vzdump en /var/log/vzdump/*.log. Busca la línea Backup finished sin errores.
  3. Restauración de prueba – Selecciona una VM backup y ejecuta qmrestore /mnt/backup-hdd/vzdump-qemu-101-2024_09_20-00_00_00.vma.gz 105. Asegúrate de que la VM arranca.
  4. Bridge de gestión – Conéctate a la IP de vmbr1 vía SSH. Si la conexión funciona mientras la red LAN está caída, el aislamiento está correcto.

Notas adicionales

  • Evita snapshots anidados: crear un snapshot dentro de otro snapshot complica la cadena de revertir y consume espacio rápidamente.
  • Compresión vs CPU: gzip reduce I/O pero aumenta carga de CPU. En un host con CPU limitada, considera lzo o zstd.
  • Plan de recuperación física: guarda al menos una copia de los backups en un medio externo (USB) desconectado semanalmente. El HDD interno sigue siendo vulnerable a fallos simultáneos.
  • Actualizaciones de firmware NVMe: verifica que el firmware esté al día; algunos modelos presentan pérdida de rendimiento bajo carga sostenida.
  • Documenta la asignación de IP: usa un archivo hosts interno o una hoja de cálculo para mapear MAC → IP → VM. Evita depender solo de reservas DHCP que pueden cambiar sin aviso.