Problema

Los entornos self‑hosted que combinan hipervisores, contenedores y aplicaciones de medios tienden a volverse frágiles cuando crecen en complejidad. Un fallo en el almacenamiento, una actualización inesperada de un contenedor o una pérdida de conectividad de red pueden detener servicios críticos como Plex, Sonarr o los backups. El reto común es mantener la disponibilidad mientras se sigue añadiendo hardware (GPU passthrough, 10 GbE) y software (monitoring, backup, VPN). La pregunta recurrente es: ¿cómo estructurar el stack para que los fallos sean detectados y mitigados sin intervención manual constante?

Causa

  1. Dependencias implícitas entre VMs y contenedores
    Cuando una VM aloja varios contenedores que a su vez consumen recursos de una pool NFS, la caída del host o del NFS bloquea todo el flujo de medios.

  2. Falta de separación de datos y metadatos
    Al mezclar discos de datos (RAIDZ) con discos de sistema (NVMe) sin una capa de abstracción, una degradación del RAIDZ afecta a los backups y a los índices de Plex simultáneamente.

  3. Actualizaciones automáticas sin pruebas de regresión
    Herramientas como Watchtower pueden actualizar imágenes Docker que rompen scripts de extracción (Unpackerr, Pinchflat) o cambian la API de un indexador.

  4. Monitorización fragmentada
    Tener Grafana/Loki en un nodo y Uptime Kuma en otro dificulta correlacionar eventos. Los logs se pierden si el nodo que los envía se reinicia.

  5. Redundancia de red insuficiente
    Un único enlace de 10 GbE, aunque bonded, puede colapsar bajo tráfico de backups o transcodificación, provocando timeouts en qBittorrent o en la sincronización de Syncthing.

Solución

1. Arquitectura de capas

  • Capa de hipervisor: Proxmox VE con discos de arranque en espejo NVMe. Mantener los discos de datos en pools ZFS separadas (RAIDZ1/Z2) y exponerlos vía iSCSI o NFS a los VMs que lo necesiten.
  • Capa de contenedores: Docker dentro de VMs dedicadas a servicios de medios. Cada VM tiene su propio bridge de red y su propio storage pool (bind‑mount a NFS).
  • Capa de backup: Proxmox Backup Server (PBS) con datastore local (iSCSI) y remoto (Backblaze B2). Configurar snapshots automáticos y retención basada en políticas de negocio.

2. Gestión de actualizaciones controlada

  • Desactivar Watchtower para los contenedores críticos (Plex, Sonarr, Radarr).
  • Implementar un pipeline CI con Ansible que:
    1. Descargue la nueva imagen.
    2. Realice un docker compose up -d --no-deps --build en un entorno de pruebas.
    3. Ejecuta pruebas de salud (curl a /health, verificación de logs).
    4. Si pasa, despliega a producción.

3. Monitorización unificada

  • Configurar Prometheus Node Exporter en cada VM y en el host Proxmox.
  • Exportar métricas de Docker mediante cAdvisor.
  • Centralizar logs con Grafana Loki y crear alertas en Grafana Alerting para:
    • Uso de CPU > 85 % en GPU passthrough.
    • Latencia NFS > 200 ms.
    • Fallos de backup en PBS (status != OK).

4. Redundancia de red

  • Mantener dos enlaces de 10 GbE en LACP (bond mode 802.3ad).
  • Configurar VLANs separadas para tráfico de gestión, medios y laboratorio.
  • Añadir un failover static route que redirija tráfico de backup a la segunda interfaz si la primaria supera un umbral de pérdida de paquetes.

5. Automatización de pruebas de integridad

  • Programar PixelProbe o similar para escanear la biblioteca Plex cada 24 h y generar un reporte en Trilium.
  • Usar Healthchecks.io (auto‑hosted) para validar que los cron de Sonarr, Radarr y Unpackerr se ejecutan.
  • Configurar Dozzle como visor rápido de logs y enlazarlo a alertas de Grafana para inspección inmediata.

6. Estrategia de backup coherente

  1. Snapshots de VM: Proxmox crea snapshots antes de cualquier actualización del kernel o del firmware.
  2. Backup de contenedores: docker export a un archivo tar y subirlo a PBS mediante script.
  3. Sincronización de datos: Syncthing replicado a NAS QNAP y luego a B2.
  4. Retención: 30 días de backups diarios, 12 meses de semanales, 5 años de mensuales.

Cuándo aplicar esta solución

  • Síntomas: caídas intermitentes de Plex, backups fallidos sin razón aparente, alertas de alta latencia NFS, contenedores que se reinician tras una actualización automática.
  • Entorno: al menos un hipervisor Proxmox, varios contenedores Docker críticos y una capa de almacenamiento ZFS.
  • No aplica: infraestructuras pequeñas (una sola VM sin contenedores) donde la sobrecarga de monitorización y CI no justifica el beneficio.

Código

# Script básico para crear un backup de un contenedor Docker y enviarlo a PBS
CONTAINER=plex
BACKUP_NAME="${CONTAINER}_$(date +%Y%m%d%H%M).tar"
docker export "$CONTAINER" -o "/tmp/$BACKUP_NAME"
# Subir a PBS (asume que pbs-client está configurado)
pbs-client backup create \
  --datastore local \
  --file "/tmp/$BACKUP_NAME" \
  --description "Backup automático de $CONTAINER"
# Limpiar archivo temporal
rm "/tmp/$BACKUP_NAME"

Verificación

  1. Ejecutar el script manualmente y confirmar que el archivo aparece en el datastore de PBS.
  2. Verificar en la UI de Grafana que la métrica container_cpu_usage_seconds_total para el contenedor está dentro de los rangos esperados.
  3. Revisar en Healthchecks que el endpoint /health del contenedor responde 200 OK después del backup.
  4. Simular una caída de la interfaz primaria (ifdown eth0) y comprobar que el tráfico de backup se redirige a la segunda interfaz sin pérdida de paquetes (ping continuo).

Notas adicionales

  • GPU passthrough: siempre asignar la GPU a una VM dedicada; compartirla entre contenedores genera conflictos de driver y reinicios inesperados.
  • RAIDZ vs RAIDZ2: para volúmenes de medios críticos (≥ 150 TB) RAIDZ2 ofrece mejor tolerancia a fallos sin impactar significativamente el rendimiento de lectura.
  • Backblaze B2: habilitar la opción de “Lifecycle Rules” para mover objetos a “Glacier” después de 90 días y reducir costos.
  • Tailscale: usarlo solo para acceso administrativo; no exponer servicios internos a través de él para evitar latencias innecesarias.
  • Actualizaciones de firmware: aplicar primero en un nodo de prueba antes de propagarlas a los nodos de producción; los controladores de red de 10 GbE son sensibles a versiones específicas del BIOS.