Problema

En muchos homelabs la combinación de máquinas virtuales, contenedores Docker y almacenamiento ZFS genera una superficie de riesgo difícil de proteger. El síntoma típico es la pérdida parcial de datos tras una caída de energía, una actualización fallida de una VM o una corrupción de pool ZFS. Los administradores terminan con backups esporádicos, copias en discos externos sin versionado y sin un plan claro de recuperación ante desastres. La falta de una arquitectura de backup coherente también dificulta la migración de servicios entre nodos o la restauración rápida después de un fallo del hardware.

Causa

  1. Separación física insuficiente – Cuando el servidor de Proxmox y el de TrueNAS comparten la misma fuente de energía o la misma red sin redundancia, una única falla afecta a ambos.
  2. Ausencia de snapshots programados – ZFS permite snapshots instantáneos, pero sin cron jobs o herramientas de gestión los snapshots se quedan en el tiempo y consumen espacio sin control.
  3. Backup de VM sin consistencia de aplicación – Copiar discos de una VM mientras está en ejecución genera imágenes corruptas, sobre todo con bases de datos o contenedores que mantienen estado.
  4. Replicación unidireccional – Un solo túnel WireGuard hacia un sitio remoto no garantiza que los datos críticos estén disponibles si el túnel falla o el nodo remoto se queda sin espacio.
  5. UPS mal dimensionado o sin monitorización – Un UPS que no cubre la carga total o que no está integrado con el software de backup impide que los jobs finalicen correctamente durante un apagón.

Solución

Una estrategia robusta se basa en tres capas: snapshots locales, replicación remota y backup de aplicación consistente. El flujo recomendado es:

  1. Snapshots ZFS automáticos

    • Configura cron o systemd-timers en TrueNAS para crear snapshots cada 15 minutos en los pools críticos (media, nextcloud).
    • Usa políticas de retención que mantengan los últimos 24 h, los últimos 7 d y los últimos 30 d.

  2. Replicación ZFS a sitio remoto

    • Establece un túnel WireGuard site‑to‑site con claves pre‑shared.
    • En el nodo remoto (puede ser un laptop con TrueNAS CORE) ejecuta zfs send | ssh para replicar los snapshots.
    • Habilita zfs receive -F para sobrescribir de forma segura y mantiene una copia de seguridad completa fuera del sitio.

  3. Backup de VMs con Proxmox Backup Server (PBS)

    • Despliega PBS como VM o contenedor en el mismo host que Proxmox.
    • Configura los jobs de backup en modo “snapshot” para que Proxmox pause el disco virtual, tome el snapshot y lo envíe a PBS sin interrumpir los servicios.
    • Activa la compresión LZ4 y la verificación de integridad (--checksum).

  4. Backup de contenedores Docker

    • Usa WUD (What’s Up Docker) o docker commit dentro de un cron para exportar imágenes y volúmenes a un dataset ZFS dedicado.
    • Después del export, dispara un snapshot del dataset para versionar el estado.

  5. Integración con UPS

    • Conecta tanto el nodo Proxmox como el TrueNAS al mismo UPS y habilita nut (Network UPS Tools).
    • Configura alertas en unbound y nginx-proxy-manager para que, al recibir señal de batería, los jobs de backup se completen y el host se apague ordenadamente.

  6. Monitoreo y alertas

    • Añade Uptime Kuma o Prometheus con exporters para PBS, ZFS y WireGuard.
    • Configura notificaciones por Telegram cuando un snapshot falle o la replicación se detenga.

Alternativas

  • Si el presupuesto no permite un segundo nodo TrueNAS, usa rsync.net como destino de replicación ZFS.
  • En entornos sin WireGuard, OpenVPN o IPsec pueden servir, siempre que el túnel sea persistente y tenga MTU ajustado para evitar fragmentación de zfs send.

Cuándo aplicar esta solución

  • Síntomas: pérdida de datos tras apagones, restauraciones que fallan, espacio de disco consumido sin control, falta de copias fuera del sitio.
  • Entorno: homelabs con Proxmox (VMs), TrueNAS (ZFS), Docker y servicios críticos (Nextcloud, Plex, bases de datos).
  • No aplica: instalaciones sin ZFS (por ejemplo, ext4) o donde no hay acceso a un segundo nodo físico o virtual para replicación. En esos casos, la solución se reduce a backups locales y copias en la nube.

Código

# 1. Cron job para snapshots cada 15 minutos
*/15 * * * * root zfs snapshot -r tank/media@$(date +\%Y-\%m-\%dT\%H-%M-%S)

# 2. Replicación incremental a sitio remoto (ejecutar cada hora)
0 * * * * root /usr/local/bin/zfs-replicate.sh

# 3. Script de replicación (zfs-replicate.sh)
#!/bin/bash
SRC_POOL="tank/media"
DST_HOST="backup.remote"
DST_POOL="backup/media"
SSH_OPTS="-i /root/.ssh/wg_key -o StrictHostKeyChecking=no"

# Obtener último snapshot enviado
LAST_SENT=$(ssh $SSH_OPTS $DST_HOST "zfs list -t snapshot -H -o name -s creation -r $DST_POOL | tail -1")
if [[ -z $LAST_SENT ]]; then
  SEND_OPTS="-R"
else
  SEND_OPTS="-i $LAST_SENT"
fi

zfs send $SEND_OPTS $SRC_POOL@$(date +\%Y-\%m-\%dT\%H-%M-%S) | \
ssh $SSH_OPTS $DST_HOST "zfs receive -F $DST_POOL"

Verificación

  1. Snapshot – Ejecuta zfs list -t snapshot -r tank/media y verifica que aparecen los snapshots con la marca de tiempo esperada.
  2. Replicación – En el nodo remoto, corre zfs list -t snapshot -r backup/media y comprueba que el último snapshot coincide con el origen.
  3. PBS – En la UI de Proxmox, revisa el historial de backups; los jobs deben mostrarse como “Success”.
  4. UPS – Simula un corte de energía con nut (upsc ups@localhost) y confirma que los servicios se apagan ordenadamente y que los jobs pendientes se completan.
  5. Alertas – Genera una falla intencional (por ejemplo, elimina un snapshot) y verifica que llega la notificación a Telegram.

Notas adicionales

  • Ajusta el compression de ZFS a lz4 para minimizar el impacto de los snapshots en el rendimiento.
  • Cuando uses zfs send -R, el primer envío copia todo el dataset; después, -i envía solo los cambios, ahorrando ancho de banda.
  • Mantén la clave SSH de WireGuard en un vault (por ejemplo, Vaultwarden) y rota cada 90 días.
  • Si el pool de medios crece rápidamente, considera habilitar dedup=on solo en datasets de archivos estáticos (imágenes, backups).
  • Documenta la arquitectura en un repositorio Git; así cualquier cambio de configuración queda versionado y auditado.