Problema

En muchos homelabs el crecimiento de datos supera rápidamente la capacidad de un único tipo de medio. Se combina NVMe para rendimiento, SSD para disponibilidad y HDD para archivo, pero la copia de seguridad suele quedar confinada al mismo rack. Esa proximidad aumenta el riesgo: una falla eléctrica, incendio o error humano puede destruir simultáneamente el origen y todas sus réplicas. El reto es diseñar una estrategia de backup que:

  1. Aproveche la velocidad del NVMe para operaciones diarias.
  2. Utilice SSD como zona de respaldo rápido y de retención corta.
  3. Reserve HDD para copias de seguridad semanales o mensuales (“cold storage”).
  4. Añada una capa fuera del sitio o un medio físico resistente (cinta LTO, nube, etc.) para recuperación ante desastres (DR).

El objetivo es crear un flujo de datos predecible, automatizado y verificable sin depender de soluciones propietarias costosas.

Causa

Los fallos más habituales en este tipo de entornos provienen de:

  • Single‑point-of‑failure del rack – todos los volúmenes están alimentados por la misma UPS y red. Cuando esa infraestructura colapsa, se pierden tanto los datos primarios como los respaldos locales.
  • Falta de separación temporal – si la copia de seguridad diaria se guarda en el mismo SSD que sirve de cache, un borrado accidental o corrupción se propaga rápidamente.
  • Inconsistencias de snapshots – al respaldar máquinas virtuales sin congelar el estado del sistema de archivos, los backups pueden quedar corruptos.
  • Plan de retención insuficiente – sin una política clara, los archivos antiguos se sobrescriben y se pierden versiones históricas.
  • Ausencia de pruebas de restauración – la mayoría de los usuarios confía en que “el backup está ahí” sin validar la integridad ni el tiempo de recuperación.

Solución

Una arquitectura de backup en tres niveles, con automatización y verificación, cubre los puntos anteriores.

1. Nivel 0 – Producción (NVMe)

  • Objetivo: Máxima IOPS y latencia mínima para VMs y bases de datos.
  • Implementación: Pool ZFS o Ceph con 128 TB NVMe, expuesto a los hipervisores vía iSCSI o NFS.
  • Buenas prácticas: Habilitar recordsize=4K para bases de datos, usar compression=lz4 solo si la carga lo permite, y crear snapshots cada hora con retención de 24 h.

2. Nivel 1 – Backup rápido (SSD)

  • Objetivo: Copia de seguridad diaria que pueda restaurarse en minutos.
  • Implementación: Servidor dedicado con 96 TB SATA SSD, ejecutando Proxmox Backup Server (PBS). PBS recibe los snapshots de nivel 0 mediante pve-backup o vzdump.
  • Política de retención: Retener 7 copias diarias y 4 semanales. PBS gestiona deduplicación a nivel de bloque, lo que reduce el espacio necesario.
  • Automatización: Jobs programados en PBS con prune-backup para aplicar la política de retención.

3. Nivel 2 – Archivo frío (HDD)

  • Objetivo: Almacén de gran capacidad para copias semanales/mensuales y datos que rara vez se acceden.
  • Implementación: NAS de 4 × 30 TB en RAID‑6, montado vía NFS en el servidor PBS. El NAS se apaga después de cada ventana de backup para ahorrar energía y reducir desgaste.
  • Ciclo de copia: Cada domingo, PBS replica los backups de nivel 1 al NAS usando rsync --archive --delete. Se conserva una rotación mensual de 12 copias.

4. Nivel 3 – Off‑site / LTO

  • Objetivo: Protección contra desastres físicos.
  • Opciones:
    • Cinta LTO‑8 – 12 TB por cartucho, escritura a 300 MB/s, vida útil de 30 años. Ideal para almacenar una instantánea mensual del NAS HDD.
    • Nube privada – bucket S3 compatible (Backblaze B2, Wasabi) con versión de objetos activada.
  • Procedimiento: Cada primer día del mes, un script copia la última instantánea del NAS a la cinta o al bucket. La cinta se guarda en una caja fuerte ignífuga fuera del sitio; el bucket se replica a una región distinta.

5. Orquestación y monitoreo

  • Cron o systemd timers para lanzar los jobs de PBS y rsync.
  • Prometheus + node_exporter para exponer métricas de espacio, latencia y éxito de backups.
  • Alertmanager envía notificaciones por Telegram o correo cuando un job falla o el espacio disponible cae bajo el 20 %.

Cuándo aplicar esta solución

  • Entornos con >50 TB de datos activos – la separación de NVMe y SSD evita cuellos de botella.
  • Necesidad de RTO < 15 min – PBS permite restaurar una VM completa en pocos minutos desde SSD.
  • Presupuesto medio – usar hardware existente (NAS HDD) y una sola cinta LTO reduce costos frente a soluciones de nube completa.
  • No aplica si el homelab solo maneja unos pocos terabytes y la complejidad de tres niveles no justifica el mantenimiento adicional.

Código

# PBS: crear job de backup diario para todas las VM
pbs-manager datastore create nvme-backup --path /mnt/ssd/pbs

# Añadir VM 101 al job
pbs-manager backup create --datastore nvme-backup --vm 101 --schedule "0 2 * * *" --retain "7d,4w"

# Prune automático según política
pbs-manager prune --datastore nvme-backup --keep-daily 7 --keep-weekly 4

# Replicar de PBS a NAS HDD cada domingo a las 03:00
rsync -a --delete /mnt/ssd/pbs/ backups@nas-hdd:/export/backups/

Verificación

  1. Comprobar integridad del snapshot

    pbs-manager backup verify --datastore nvme-backup --vm 101 --snapshot latest

    El comando debe devolver OK sin errores.

  2. Simular restauración

    pbs-manager restore --datastore nvme-backup --vm 101 --snapshot latest --dry-run

    Verifica que la VM pueda arrancar en modo prueba.

  3. Validar copia en HDD

    rsync --dry-run -a /mnt/ssd/pbs/ backups@nas-hdd:/export/backups/

    Asegúrate de que el número de archivos y tamaños coincidan.

  4. Revisar métricas
    Accede a Grafana → Dashboard “Backup Health”. Los paneles deben mostrar backup_success_total sin decrementos en los últimos 24 h.

Notas adicionales

  • Desactivar el NAS durante la copia – apaga la unidad antes de iniciar el rsync para evitar I/O conflictivo y reducir consumo energético.
  • Cifrado en reposo – habilita ZFS encryption=on en el pool SSD y HDD si manejas datos sensibles; la clave se almacena en un HSM o en un archivo protegido por chmod 600.
  • Pruebas de DR – al menos una vez al trimestre, restaura una VM completa desde la cinta LTO o el bucket S3 en un hardware diferente para validar el proceso completo.
  • Rotación de cintas – etiqueta cada cartucho con fecha y contenido; conserva al menos tres generaciones (mes actual, anterior y dos meses atrás) para cubrir errores de retención.
  • Documentación interna – mantén un README.md en el repositorio de scripts con pasos de recuperación, credenciales de acceso y contactos de soporte.

Con esta arquitectura de backup multi‑tier, el homelab gana velocidad en operaciones diarias, resiliencia frente a fallos locales y una capa de protección contra desastres que no depende exclusivamente de la infraestructura del rack. La clave está en automatizar, monitorear y, sobre todo, probar regularmente la restauración.