Restaura Immich después de una actualización fallida del contenedor congelando las pruebas actuales, fijando cada servicio de Immich a la última versión conocida como estable y restaurando los datos solo si una reversión coordinada no puede iniciar la pila.
Una actualización puede cambiar al mismo tiempo el código de la aplicación, las expectativas del esquema de la base de datos, las variables de entorno y las versiones de los servicios complementarios. Extraer repetidamente la versión más reciente o mezclar contenedores antiguos y nuevos dificulta determinar el límite de recuperación. Guarda el archivo de Compose, el entorno, los registros, la base de datos y las rutas de carga antes de actuar; después, elige entre revertir las imágenes o restaurar por completo la base de datos y la biblioteca.
Congela el estado fallido e identifica el límite de la actualización
Detén los reinicios automáticos y registra las imágenes o los resúmenes exactos de los servicios de servidor, aprendizaje automático, base de datos y caché. Guarda los registros de inicio y los archivos de despliegue antes de realizar otra extracción. La comprobación es satisfactoria si puedes indicar qué cambió; si no, la recuperación debe pausarse hasta identificar las versiones anteriores mediante el historial de despliegue o las imágenes locales.
Comprueba si el servidor se cierra antes de conectarse a la base de datos, durante una migración o después de quedar listo. Un error de conexión con una dependencia apunta a una reparación de red, credenciales o estado de salud; un error de migración aumenta el riesgo de restaurar solo la imagen de la aplicación, porque la base de datos podría haber cambiado ya.
Un recorrido por las actualizaciones versionadas de Immich muestra por qué son importantes el límite de la versión y los archivos de despliegue. Úsalo para inventariar la transición, pero considera tus propios registros y copias de seguridad como la autoridad para la reversión.
Prueba primero una reversión completa a la última imagen conocida como estable
Fija todas las imágenes de la aplicación Immich en la versión exacta que funcionaba anteriormente, en lugar de cambiar un solo servicio. Recrea los contenedores afectados sin modificar los volúmenes persistentes. Si la pila recupera un estado saludable y los registros no muestran incompatibilidad de esquema, esta reversión de bajo impacto es satisfactoria.
Si el servidor antiguo rechaza el esquema actual de la base de datos, detente. No alternes versiones contra la misma base de datos ni edites manualmente las tablas de migración. Este fallo indica que la actualización cruzó un límite de datos y que la recuperación debe utilizar una copia de seguridad de la base de datos cuya fecha y hora coincidan con la versión de aplicación seleccionada.
Un informe de Immich v1.135.3 documenta un fallo específico de inicio durante la migración de la base de datos después de una actualización. Su ejemplo de migración acotada justifica leer con atención el primer error fatal; no autoriza a copiar los comandos de ese caso en otra versión.
Restaura la base de datos y los medios solo cuando la reversión no pueda recuperar el sistema
Crea una copia de seguridad o una instantánea de almacenamiento del estado fallido antes de restaurar. Prepara un destino de recuperación limpio, restaura la copia de seguridad de la base de datos y después expón la biblioteca de cargas correspondiente y los archivos de despliegue necesarios. No sobrescribas la única biblioteca actual con una copia antigua solo para hacer coincidir las marcas de tiempo.
Los registros de la base de datos y los archivos de recursos deben describir la misma colección. Si la copia de seguridad es anterior a las cargas recientes, conserva esos archivos nuevos por separado para conciliarlos más adelante. La restauración es satisfactoria cuando las migraciones finalizan, aparecen los usuarios y recursos esperados y los originales seleccionados se abren sin errores generalizados de archivos ausentes.
La guía de migración de Immich de ZimaSpace ofrece un inventario útil para trasladar los componentes persistentes sin considerar que una imagen de contenedor sea la propia biblioteca de fotos.
Valida la recuperación antes de volver a intentar la actualización
Prueba el inicio de sesión, la navegación por la cronología, la descarga de originales, la generación de miniaturas, Smart Search, el procesamiento facial, una carga nueva y una copia de seguridad de la base de datos. Reinicia una vez los contenedores y el host. La comprobación es satisfactoria cuando los mismos recursos y funciones siguen disponibles después del reinicio, sin errores repetidos de migración o permisos.
Mantén los estados fallido y recuperado con etiquetas separadas hasta que termine la validación. Si la recuperación depende de una versión anterior, desactiva las extracciones automáticas de imágenes y documenta la versión fijada. Vuelve a intentar la actualización solo después de revisar todas las versiones intermedias y realizar una copia de seguridad coordinada nueva.
Vuelve al destino de recuperación conservado si desaparece una carga nueva, los originales no se abren o los trabajos se bloquean repetidamente. Escala el problema indicando las versiones de origen y destino, los resúmenes de imagen, el primer registro de error fatal, la fecha y hora de la copia de seguridad de la base de datos y la correspondencia del almacenamiento; nunca elimines la última copia conocida como estable mientras la compatibilidad de la actualización siga sin resolverse.
Soporte y Consejos
Más para leer

Cómo optimizar las conexiones de la base de datos de Immich para contenedores simultáneos
No aumentes primero max_connections. Mide las sesiones de Immich, suma la demanda total de todos los contenedores, conserva margen para la administración y ajusta...

Cómo evitar trabajos o importaciones duplicados en Immich
Separa los trabajos repetidos de los recursos duplicados. Usa una única ruta de ingesta canónica, controla los reintentos y los cambios de ruta, y...

Cómo reparar Immich después de que su volumen de base de datos se llene
Nunca elimines el WAL de PostgreSQL para liberar espacio. Detén las escrituras de Immich, conserva el estado de la base de datos, añade capacidad...

