¿Puede Immich ejecutarse de forma fiable con sus datos en un recurso compartido de red?
Immich puede usar de forma fiable un recurso compartido de red para los archivos multimedia o una biblioteca externa cuando el montaje, los permisos, la latencia y el comportamiento ante interrupciones se han diseñado y probado correctamente, pero su directorio de datos de PostgreSQL debe permanecer en un almacenamiento compatible y de baja latencia, no en un recurso compartido SMB o NFS genérico.
La palabra «datos» oculta diferentes cargas de trabajo: los originales son archivos grandes y duraderos, las miniaturas generan muchas operaciones pequeñas, las bibliotecas externas pueden ser de solo lectura y PostgreSQL requiere una semántica de sistema de archivos propia de las bases de datos. Decide la ruta por separado, monta el recurso compartido antes de iniciar los contenedores, evita que un directorio local vacío suplante al NAS y demuestra el comportamiento mediante un reinicio del host y una interrupción controlada del recurso compartido.
Clasifica cada ruta de Immich antes de moverla
Enumera por separado la biblioteca de cargas, las miniaturas o los archivos multimedia codificados, las bibliotecas externas, el directorio de la base de datos, la caché de modelos y las copias de seguridad. Indica quién escribe en cada ruta y cuál sería el impacto de su pérdida. Un recurso compartido para archivos multimedia puede ser viable; tratar todos los volúmenes como intercambiables hace que el diseño no supere el criterio de validación.
Un tutorial práctico de NFS demuestra cómo asignar una biblioteca externa de Immich desde un almacenamiento compartido. Su patrón de montaje de biblioteca externa resulta útil para planificar rutas y permisos, pero no demuestra que la base de datos deba usar NFS.
Mantén PostgreSQL en un almacenamiento recomendado para bases de datos y protégelo con volcados nativos y copias de seguridad. Si el almacenamiento local activo es limitado, mueve solo la ruta de archivos multimedia cuyo consumo de capacidad hayas medido y documenta el límite, en lugar de trasladar todo el estado de la aplicación.
Haz determinista el orden de los montajes remotos
Monta el recurso compartido en el host con credenciales o reglas de exportación explícitas, una dirección estable y el modo de lectura y escritura previsto. Verifica la identidad del sistema de archivos esperado y un archivo marcador conocido antes de iniciar Immich. Vincula la ruta del host ya montada a los contenedores.
Configura el gestor de servicios para que Immich espere al montaje remoto y no se inicie sobre un directorio alternativo vacío. Un arranque solo es válido cuando el marcador aparece dentro del contenedor y un archivo de prueba recibe el propietario esperado; un directorio vacío o un archivo propiedad de root son motivos suficientes para detenerse.
Reinicia una vez con el recurso compartido disponible y otra vez con él deliberadamente no disponible durante una ventana de mantenimiento. La primera prueba solo es válida cuando el marcador aparece antes de que se inicie Immich; la segunda, cuando Immich se detiene o falla de forma visible en lugar de escribir en el punto de montaje local sin montar.
Demuestra la identidad del contenedor y los permisos del recurso compartido
Haz coincidir las identidades numéricas de usuario y grupo en el servidor, el cliente y el contenedor; después, prueba la creación, el cambio de nombre, la lectura y la eliminación en una carpeta desechable específica. No resuelvas una discrepancia con permisos de escritura globales que expongan la biblioteca familiar.
Repite la prueba con el archivo desechable desde dentro del contenedor del servidor de Immich, no solo desde el host. Confirma que el NAS ve el propietario numérico previsto y que Immich puede volver a abrir el archivo después de recrear el contenedor. Una prueba satisfactoria únicamente en el host no demuestra que la ruta del contenedor funcione.
Si la identidad o el comportamiento de creación y cambio de nombre difieren, detente y corrige la exportación, el montaje o la asignación del contenedor de forma específica. Vuelve a probar antes de escanear una biblioteca real; los cambios amplios de permisos pueden ocultar la discrepancia y, al mismo tiempo, exponer todas las fotos familiares a servicios no relacionados.
Mide la latencia y prueba una interrupción del recurso compartido
Ejecuta una carga representativa, la generación de miniaturas, la navegación por la cronología, la descarga de un original y un escaneo de la biblioteca externa mientras mides la latencia del servidor y el progreso de los trabajos. Para superar la prueba se requiere una interacción aceptable y que la cola no crezca de forma persistente; la velocidad bruta del enlace por sí sola no demuestra un rendimiento adecuado de los metadatos.
Un problema de Immich informa de incoherencias entre la base de datos y los archivos en una implementación con NFS inestable. El caso acotado de fallo de NFS respalda considerar las desconexiones durante las escrituras como un riesgo de recuperación, sin asumir que NFS siempre corrompa Immich.
Durante una ventana de mantenimiento y con las copias de seguridad completadas, interrumpe el recurso compartido de archivos multimedia mientras haya una prueba no crítica activa. Immich debería fallar de forma visible en lugar de escribir en el punto de montaje local sin montar. Restaura el recurso compartido y confirma que el archivo de prueba y el registro de la base de datos vuelven a concordar sin entrar en un ciclo de reinicios.
Decide si proceder o no después de las pruebas de reinicio
Reinicia los contenedores y el host por separado. Confirma que el recurso compartido correcto se monta primero, que los originales antiguos y nuevos se abren, que los escaneos externos no duplican archivos y que una nueva carga sobrevive a otro reinicio. La comparación entre DAS y NAS de ZimaSpace plantea el equilibrio entre latencia y dominio de fallo.
Usa el recurso compartido cuando estas pruebas sean satisfactorias y la supervisión pueda alertar sobre su ausencia, la latencia, el espacio y la presión de inodos. Elige almacenamiento local o conectado directamente cuando la red o el NAS no puedan cumplir la disponibilidad requerida, o cuando no sea posible impedir el comportamiento de montaje alternativo.
Vuelve a la ruta local anterior si Immich se inicia vacío, crea archivos propiedad de root o genera errores de archivos faltantes después de una interrupción. Incluye en la incidencia el protocolo, las opciones de montaje, las identidades, las asignaciones de rutas, la latencia y el orden de arranque; nunca vuelvas a escanear de forma destructiva hasta conocer el estado de los originales autorizados y de la base de datos.
Productos recomendados
Soporte y Consejos
Más para leer
Cómo adaptar las políticas de reinicio de Docker a bases de datos, trabajadores y aplicaciones web
Adapta la política de reinicio al ciclo de vida y a la semántica de salida del servicio. Combínala con comprobaciones de salud y disponibilidad;...
Cómo configurar los identificadores de usuario de los contenedores en varios recursos compartidos de NAS
Asigna el UID/GID de cada contenedor a sus recursos compartidos del NAS, usa grupos compartidos o ACL cuando sea necesario y considera PUID/PGID específicos...
Cómo configurar perfiles de Docker Compose para servicios opcionales del servidor doméstico
Deja los servicios necesarios sin perfil y usa perfiles para las herramientas opcionales. Prueba los objetivos directos y las dependencias en lugar de asumir...
