Actualizar el sistema del NAS da miedo con razón: ahí viven Immich, Home Assistant, Vaultwarden y el resto del stack. Un DSM mal parado o un TrueNAS que reinicia a medias puede dejarte media tarde reconstruyendo contenedores. No es magia negra: es checklist, snapshots y no tener prisa.

Esta guía vale para Synology DSM (Container Manager / Docker) y TrueNAS Scale (Apps / Kubernetes-ish). La idea es la misma: protege datos y configs, para servicios en orden, actualiza, comprueba, y solo entonces te relajas. Si aún no tienes una estrategia de copias, lee antes la regla 3-2-1.

El NAS no es un móvil: no pulses «actualizar ahora» a las 23:55 porque el banner molesta. Reserva una mañana, un café y un plan B.

Por qué las actualizaciones rompen Docker

Tres causas típicas:

  • Reinicio a lo bruto mientras bases de datos escriben (Postgres de Immich, MariaDB, etc.).
  • Cambios de runtime: Container Manager, drivers, red o cgroup tras un major de DSM/TrueNAS.
  • Volúmenes mal montados tras un scrub o un pool que tarda en importar: el contenedor arranca «vacío» y regenera configs.

Casi nunca es «Docker se borra solo». Suele ser: datos intactos + contenedor que no arranca, o arranque con rutas rotas. Por eso importan los snapshots antes y la verificación después.

Checklist pre-actualización

Elige ventana y avisa en casa
1–2 horas sin streaming, sin cámaras críticas y sin que alguien suba fotos a Immich. Si tienes SAI, mejor: un corte a mitad de update es el escenario de película de terror. Guía: SAI para NAS.
Anota el inventario Docker
Lista de contenedores, puertos, rutas de volumen y compose. Captura de pantalla de Container Manager / TrueNAS Apps. Si algo no vuelve, sabrás qué faltaba.
Confirma backup reciente de datos críticos
Fotos, vault, nextcloud, configs HA. No «creo que Hyper Backup corrió». Verifica la última tarea OK y, si puedes, un restore de prueba de un archivo. Más en regla 3-2-1.
Lee las notas de la versión
Breaking changes en Docker, Python, OpenSSL, o apps oficiales. En TrueNAS, mira si tu app chart cambia de versión mayor.
Desactiva actualizaciones automáticas de contenedores
No quieres que Watchtower o un update de imagen coincida con el reboot del host. Actualiza el SO; las imágenes, otro día.

Snapshots y copias (lo que te salva)

Antes de parar nada:

  • Synology: Snapshot Replication (o Btrfs snapshots) del volumen/carpetas docker, Immich, configs. Hyper Backup a disco externo o B2 si ya lo tienes.
  • TrueNAS: snapshot de los datasets que montan los apps (ix-applications / datasets de datos). Exporta la config del sistema (System → General → Download).

Un snapshot local no sustituye copia offsite, pero sí te deja volver atrás en minutos si el update deja el pool raro. La estrategia completa sigue siendo 3-2-1.

Inventario rápido (SSH, opcional)
# Synology / Linux con docker CLI docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' docker compose ls # Guarda también: # - rutas de volúmenes (-v) # - ficheros compose.yaml de cada proyecto

Orden de parada de contenedores

No apagues el NAS con todo en verde. Para servicios en orden inverso a la dependencia:

Frontales y workers
Immich microservices, n8n, Home Assistant, Jellyfin, Open WebUI… todo lo que habla con una base de datos.
Bases de datos y colas
Postgres, MariaDB, Redis, Mosquitto. Así cierran limpio y no dejas WAL a medias.
Proxies y VPN al final (o al inicio del arranque)
Nginx Proxy Manager, Tailscale/sidecar: según cómo entres al NAS. Si actualizas por IP local, puedes parar el proxy sin miedo.
Espera 30–60 segundos y reinicia / actualiza
En Container Manager: Stop en el proyecto. En compose: docker compose stop. Luego lanza el update del SO desde el panel.

Actualizar DSM o TrueNAS

Synology DSM

  1. Panel de control → Actualización y restauración → Descarga la actualización.
  2. Con contenedores parados, aplica e inicia el reinicio.
  3. No cierres la pestaña a lo loco; espera al login de DSM.
  4. Comprueba Storage Manager (volúmenes healthy) antes de arrancar Docker.

TrueNAS Scale

  1. System → Update → elige tren estable (no «latest» por deporte).
  2. Download + Apply. El sistema reiniciará.
  3. Espera a que los pools estén ONLINE y las apps en estado razonable.
  4. Si usas compose custom fuera de Apps, arráncalos tú a mano tras verificar datasets.

Qué revisar cuando vuelva

Comprobación OK si… Si falla
Volúmenes / pools Healthy / Online No arranques contenedores; revisa discos primero
Container Manager / Apps Servicio activo Reinstala runtime; no borres carpetas de datos
Proyectos compose Up, mismos puertos Recrea desde compose; montajes intactos
Apps críticas Login Immich, HA, Vaultwarden Logs del contenedor; restore snapshot de config
Red / Tailscale IP LAN y cola OK Reinicia cliente Tailscale; no abras puertos «por mientras»

Orden de arranque recomendado: bases de datos → apps que las usan → frontales. Espera a que Postgres esté healthy antes de levantar Immich completo.

Rollback si sale mal

No borres volúmenes «para reinstalar limpio»
Los datos suelen estar bien. Borra solo el contenedor/imagen y vuelve a crear desde el mismo compose apuntando a las mismas rutas.
Synology: restauración del sistema
Si el DSM quedó inusable y tienes configuración/backup de sistema, restaura. Snapshots Btrfs de carpetas docker te devuelven configs de hace una hora.
TrueNAS: boot environments
System → Boot: activa el entorno anterior y reinicia. Es una de las mejores características de TrueNAS para no sudar en major updates.
Restore desde copia 3-2-1
Si el dataset está tocado, toca backup externo. Por eso la regla 3-2-1 no es teoría: es el plan B el día que el snapshot local no basta.

Errores habituales

Lo que más se repite

  • Actualizar a las tantas «porque sale el aviso» sin snapshot.
  • Dejar Immich/HA corriendo durante el reboot del host.
  • Actualizar el SO y todas las imágenes Docker el mismo día.
  • Asumir que «docker ps vacío» significa datos borrados (casi nunca).
  • No tener SAI y sufrir un corte a mitad de apply update.

Resumen rápido

  • Inventario + backup verificado + snapshot antes de tocar nada.
  • Para contenedores: apps → bases de datos → update del SO.
  • Tras el reboot: pools OK, luego runtime, luego compose, luego login a cada servicio.
  • Rollback: recrear contenedores, boot environment (TrueNAS) o snapshot; offsite si hace falta.
  • Si estás eligiendo caja nueva, compara opciones en Synology vs QNAP.