Problema

En muchos homelabs el objetivo es combinar bajo coste, alta disponibilidad y recuperación rápida ante fallos de hardware o errores humanos. La dificultad surge cuando se intenta cubrir tres capas de protección (fallos físicos, borrados accidentales y pérdida total del nodo) sin crear una complejidad que haga que el propio proceso de respaldo sea el punto débil.
Los administradores suelen mezclar snapshots locales, copias de seguridad de máquinas virtuales y replicación a otro host, pero terminan con huecos: la configuración del propio hypervisor queda sin respaldo, la replicación se hace sobre redes domésticas poco fiables o se generan redundancias innecesarias que consumen espacio y tiempo.

Causa

  1. Dependencia de una única fuente de datos – ZFS protege contra fallos de disco, pero los snapshots son volátiles; si el pool entero se corrompe o se pierde la clave de cifrado, todos los snapshots desaparecen.
  2. Ausencia de respaldo del host – Proxmox almacena la configuración en /etc/pve. La mayoría de los scripts de backup (vzdump, PBS) se centran en contenedores/VM, dejando la configuración sin versión.
  3. Replicación sin aislamiento de red – Ejecutar rsync o syncoid sobre una red Wi‑Fi o una única interfaz LAN aumenta la probabilidad de interrupciones y de pérdida de datos parciales.
  4. Planificación basada en horarios de encendido – Apagar el nodo antes de que finalicen los trabajos de backup genera ventanas de vulnerabilidad y obliga a sincronizar manualmente.
  5. Sobre‑snapshotting – Configurar retenciones demasiado agresivas genera consumo de espacio que obliga a recortar snapshots críticos, reduciendo la efectividad del plan.

Solución

Una estrategia de tres capas, independiente del horario de encendido y con respaldo de la configuración del host, ofrece la mejor relación entre seguridad y operatividad.

1. Capa física – ZFS RAID‑Z2 o RAID‑Z3

  • Usa al menos RAID‑Z2 para tolerar dos fallos simultáneos. En entornos con alta escritura (medios, bases de datos) considera RAID‑Z3.
  • Habilita la compresión lz4 y, si los datos son sensibles, el cifrado nativo de ZFS.
  • Reserva un dataset dedicado para cada servicio crítico (ej. zpool/media/immich, zpool/media/jellyfin). Esto permite políticas de retención diferentes y evita que un snapshot de un dataset impacte a los demás.

2. Capa lógica – Snapshots gestionados por Sanoid + Prune

  • Instala Sanoid y Syncoid. Configura políticas por dataset:
    • Datos de fotos / videos: snapshots cada hora (24 h), diarios (30 d), semanales (12 w), mensuales (12 m).
    • Servicios de streaming: snapshots diarios (7 d) y semanales (2 w).
  • Sanoid ejecuta cada 15 min y elimina automáticamente los snapshots caducados, manteniendo el espacio bajo control.

3. Capa de backup de máquinas virtuales – Proxmox Backup Server (PBS)

  • Despliega PBS en una máquina separada (puede ser un mini‑PC con NVMe + HDD).
  • Configura vzdump para que envíe los backups de CT/VM a PBS usando el modo snapshot.
  • Para respaldar la configuración del host, crea una tarea de backup de tipo “host” con pvebackup (disponible en versiones recientes) o, si no está, empaqueta /etc/pve y los archivos de red con tar y envíalo a PBS como un “custom backup”.
  • Programa la replicación de PBS a otro nodo mediante PBS‑sync (si dispones de dos PBS) o usa syncoid para replicar los datasets ZFS directamente.

4. Replicación remota – Syncoid + red dedicada

  • Conecta ambos hosts a una VLAN dedicada o a un trunk VLAN en el router. Evita mezclar tráfico de gestión con tráfico de usuarios.
  • Usa SSH key‑based authentication sin contraseña y habilita Compression=no en ssh_config para reducir la latencia.
  • Programa syncoid a las 23:30, justo antes del apagado programado del nodo principal. El comando incluye --skip-parent para evitar transferencias redundantes y --force-sync para garantizar la consistencia.

5. Copia de seguridad “quick‑copy”

  • Mantén una copia directa de los datasets críticos en un disco interno (HDD de 2.5 “) mediante zfs send | zfs receive -F. Esta copia sirve para restauraciones rápidas sin involucrar la red.

Cuándo aplicar esta solución

  • Homelabs con varios servicios de medios (photos, videos, Plex, etc.) donde la pérdida de datos es inaceptable.
  • Entornos con ventanas de encendido limitadas (servidor que se apaga por la noche) pero que requieren respaldo antes del apagado.
  • Infraestructuras sin acceso a un centro de datos: la replicación a otro host dentro del mismo edificio es suficiente siempre que la red sea fiable.
  • Escenarios donde la configuración del hypervisor es tan valiosa como los datos de usuario (p. ej., configuraciones de red complejas, almacenamiento ZFS, permisos).

No es necesario cuando:

  • Solo se ejecutan contenedores ligeros sin datos críticos.
  • Se dispone de un único disco y el riesgo de pérdida total es aceptable.
  • La red doméstica es extremadamente inestable y no se puede garantizar una VLAN aislada.

Código

# 1. Crear dataset para Immich
zfs create -o compression=lz4 -o mountpoint=/mnt/media/immich zpool/media/immich

# 2. Configurar Sanoid (ejemplo de política)
cat <<EOF > /etc/sanoid.d/immich.conf
[zpool/media/immich]
use_template = default
recursion = yes
hourly = 24
daily = 30
weekly = 12
monthly = 12
EOF

# 3. Enviar backup de VM a PBS (vzdump)
vzdump 101 --mode snapshot --storage pbs-storage --compress lzo --mailto [email protected]

# 4. Respaldar configuración del host
tar -czf /tmp/pve-config.tar.gz -C /etc pve
pveam backup /tmp/pve-config.tar.gz pbs-storage:host-config/$(date +%F).tar.gz

# 5. Replicación ZFS con Syncoid
syncoid --no-sync-snap --skip-parent \
        zpool/media/immich root@mini-pc:/zpool/backup/immich \
        --ssh-options="-i /root/.ssh/id_rsa -o StrictHostKeyChecking=no"

Verificación

  1. Snapshot local – Ejecuta zfs list -t snapshot -r zpool/media/immich y verifica que los snapshots siguen la política de retención.
  2. Backup PBS – En la UI de PBS o con pbs-manager list, confirma que el ID de la VM/CT aparece y que la fecha coincide con la última ejecución de vzdump.
  3. Copia de configuración – Descomprime el archivo en otro host y compara con /etc/pve usando diff -r.
  4. Replicación Syncoid – En el host remoto, lista los snapshots con zfs list -t snapshot -r zpool/backup/immich y verifica que el último timestamp coincide con la hora programada.
  5. Prueba de restauración – Simula una falla apagando el nodo principal, monta el dataset replicado y arranca una VM desde el backup PBS para asegurarte de que los datos son consistentes.

Notas adicionales

  • Espacio de reserva: ZFS necesita al menos un 20 % de espacio libre para operaciones de escritura y para crear snapshots sin degradar el rendimiento.
  • Retención de snapshots: Ajusta los periodos según la tasa de cambio de los datos; los archivos de fotos rara vez cambian, por lo que una retención mensual de 12 copias suele ser suficiente.
  • Monitoreo: Configura alertas con zpool status y pveproxy para detectar degradaciones de RAID‑Z antes de que ocurran fallos de disco.
  • Seguridad de SSH: Cambia el puerto por defecto y habilita AllowUsers root@mini-pc para limitar el acceso.
  • Actualizaciones de Proxmox: Después de cada actualización, revisa que los scripts de backup siguen funcionando; los cambios en la API de PBS pueden requerir ajustes menores.

Con esta arquitectura de tres capas, cada nivel cubre una amenaza distinta y, al mismo tiempo, mantiene la operatividad sencilla: los snapshots son automáticos, los backups de VM/CT se gestionan con PBS y la replicación a un segundo host garantiza una copia fuera del nodo principal sin depender de la nube. La clave está en separar datos, configuración y máquinas virtuales, y en automatizar todo con horarios que respeten el ciclo de encendido del servidor.