¿Por qué Immich pierde el acceso a los datos persistentes después de recrear la pila?

Cuando Immich parece vacío o no puede leer su biblioteca después de recrear la pila, da por hecho que los datos persistentes antiguos están desconectados o no se pueden leer antes de asumir que se eliminaron.

Recrear los contenedores puede cambiar la identidad del proyecto de Compose, el origen del montaje vinculado, la asociación del volumen con nombre, el momento de montaje de un recurso compartido de red o el UID/GID que lee los datos. Detén la instancia con aspecto nuevo antes de que escriba demasiado estado, localiza en el host las rutas antiguas de la base de datos y los archivos multimedia, y compara la pila recreada con la última asignación que funcionaba correctamente. El objetivo es volver a conectar primero el estado existente; restaura desde una copia de seguridad solo después de demostrar que ese estado realmente falta o está dañado.

Detén la instancia nueva y demuestra que los datos antiguos aún existen

Un asistente de configuración, una cronología vacía o una biblioteca externa ausente inmediatamente después de recrear la pila son señales de advertencia de persistencia. Detén Immich e inspecciona en el host las ubicaciones de la base de datos y los archivos multimedia antes de subir archivos nuevos o aceptar una configuración vacía. Las escrituras nuevas pueden dificultar las comparaciones posteriores de rutas.

Comprueba en los directorios antiguos los recuentos de archivos esperados, las fechas de modificación, los archivos de base de datos o volcados y algunas imágenes originales representativas. Si los datos están presentes en el host, el problema es de acceso o asignación, no de desaparición. Crea una instantánea o copia de seguridad de solo lectura de ese estado antes de cambiar la propiedad o mover directorios.

Si no encuentras los datos antiguos en las rutas esperadas, busca en el conjunto de almacenamiento y en el inventario de volúmenes de Docker antes de eliminar nada. La decisión es binaria: el estado existente se localiza y protege, o no está disponible de verdad y la recuperación pasa a una copia de seguridad conocida como válida en lugar de reparar los montajes.

Compara los montajes recreados con la pila anterior

Inspecciona los montajes efectivos en los contenedores recreados del servidor y la base de datos de Immich, no solo el texto de Compose que recuerdas haber editado. Una ruta de montaje vinculado relativa puede resolverse desde un directorio de proyecto diferente, y un proyecto de Compose renombrado puede asociar un volumen nuevo con nombre mientras deja el antiguo intacto, pero sin utilizar.

Un montaje fallido, cambiado o ausente puede mostrar un directorio vacío dentro de un contenedor aunque los datos esperados sigan existiendo en otro lugar del host. Usa las comprobaciones de montajes de volúmenes de Docker para comparar Source, Destination, el tipo de montaje y la identidad del volumen con nombre de cada ruta persistente de Immich. Una discrepancia aquí explica directamente que la instancia parezca recién creada.

Corrige únicamente la asignación de montaje incorrecta y, después, crea o inicia el contenedor sin eliminar volúmenes. Si los archivos esperados aparecen en la misma ruta del contenedor tras el cambio, deja los datos en su lugar. Si la lista de montajes es correcta, pero el acceso sigue fallando, conserva la asignación y pasa a comprobar la disponibilidad del almacenamiento del host y los permisos en lugar de crear otro volumen.

Verifica que el almacenamiento externo estuviera montado antes de iniciar Immich

Si los datos de Immich están en un conjunto de discos HDD, un recurso compartido NAS, una capa de unión u otro montaje externo, confirma que ese almacenamiento esté realmente montado en el host antes de que Docker inicie la pila. Una ruta como /mnt/photos puede seguir existiendo como un directorio local ordinario cuando el dispositivo real no está disponible.

Los datos persistentes de Docker sobreviven al reemplazo de contenedores solo cuando el volumen o montaje vinculado previsto se vuelve a asociar correctamente. El modelo de persistencia de volúmenes de Docker subyacente no hace que un disco del host o un recurso compartido de red ausente aparezca automáticamente, así que verifica el dispositivo de almacenamiento y un archivo conocido en el host antes de probar la misma ruta dentro de Immich.

Si descubres archivos de respaldo escritos en el punto de montaje vacío mientras el almacenamiento real estaba ausente, detén Immich antes de montar el dispositivo encima de ellos. Concilia esos archivos por separado, añade una dependencia de inicio o una comprobación de estado para el montaje de almacenamiento y solo entonces reinicia la pila. Si el almacenamiento del host es estable y la ruta del contenedor sigue sin poder leerse, continúa con la rama de permisos.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Comprueba el UID, el GID y los permisos de los directorios sin reescribirlo todo

Una pila recreada puede ejecutar un servicio con una identidad numérica, un espacio de nombres de usuario o un contexto de seguridad distintos de los anteriores. El resultado se diferencia de un montaje ausente: la ruta existe y los archivos son visibles desde el host, pero los registros de Immich muestran errores de permisos o no pueden crear los archivos esperados.

Compara la propiedad numérica y los bits de modo de los directorios afectados del host con la identidad de usuario dentro del contenedor recreado. Primero prueba una lectura inocua y, después, una escritura reversible en una ubicación desechable dentro del mismo montaje. Evita cambiar recursivamente la propiedad de todo el archivo fotográfico hasta saber qué servicio necesita acceso de escritura y qué archivos originales deben permanecer intactos.

Corrige la discrepancia mínima de directorio o identidad que explique el fallo, reinicia una vez y vuelve a revisar los registros. Si el acceso sigue fallando con montajes y permisos coincidentes, deja de hacer cambios en el sistema de archivos e inspecciona la conexión con la base de datos, la sustitución de variables de entorno o la capa de seguridad que cambió al recrear la pila.

Vuelve a conectar el estado original y valida otra recreación

Una vez conectadas y legibles las rutas antiguas de la base de datos y los archivos multimedia, inicia Immich y busca los usuarios, álbumes, personas y recursos representativos antiguos. No des por completada la reparación solo porque se cargue la página de inicio; verifica que la aplicación esté leyendo el estado original y no una base de datos recién inicializada junto a él.

El límite importante es que los contenedores pueden ser desechables, mientras que el estado de la aplicación debe permanecer en un almacenamiento estable fuera del ciclo de vida del contenedor. Documenta los nombres de montaje y las rutas del host corregidos, y utiliza roles de almacenamiento persistente en un servidor de archivos para mantener la próxima recreación de la pila conectada a los mismos datos.

Por último, recrea la pila una vez más en condiciones controladas y repite las comprobaciones originales. La solución solo queda demostrada si la misma base de datos y los mismos archivos multimedia vuelven a aparecer después de recrear la pila y de reiniciar el host. Si el estado antiguo vuelve a desaparecer o la base de datos informa de corrupción en lugar de errores de acceso, vuelve a la copia protegida y cambia a la recuperación de la base de datos o de la copia de seguridad en vez de seguir experimentando con los montajes.