Cómo revertir Immich de forma segura después de una versión incompatible

Revierte Immich solo después de preservar el estado actual y determinar si la versión más reciente modificó la base de datos o la configuración de una forma que la imagen anterior no pueda leer.

Una imagen de contenedor se puede reemplazar, pero es posible que su estado persistente ya se haya migrado. Si una actualización empieza a fallar, detén las actualizaciones automáticas y las nuevas escrituras, registra ambas versiones, protege la base de datos y los archivos multimedia actuales y, después, elige entre una simple reversión de imagen y la restauración del punto de recuperación previo a la actualización.

Congela la actualización fallida antes de que cambie más el estado

Desactiva las actualizaciones automáticas de imágenes y evita que los clientes añadan nuevas fotos mientras recopilas pruebas. Registra las versiones o los resúmenes exactos de las imágenes antiguas y nuevas de Immich, la versión de PostgreSQL, los archivos de Compose y de entorno, las rutas de montaje y el primer error de inicio o migración.

La guía de ZimaSpace sobre los límites de la reversión de contenedores establece una distinción fundamental: los volúmenes persistentes sobreviven al reemplazo de una imagen, pero esto solo es seguro cuando la aplicación anterior sigue siendo compatible con el estado que contienen.

Haz una copia de seguridad nativa de la base de datos del estado fallido actual si la base de datos se puede leer y conserva por separado la copia de seguridad previa a la actualización. No sobrescribas ninguna de las dos con experimentos repetidos. La copia actual podría ser necesaria para avanzar más adelante, aunque el objetivo inmediato sea volver a la versión anterior.

Determina si la versión cruzó un límite de migración de la base de datos

Examina el primer fallo posterior a la actualización y determina si ocurre antes o durante la migración de la base de datos, después de la migración mientras se inicia la aplicación o únicamente durante un flujo de trabajo del usuario. Este momento cambia el plan de reversión, porque es posible que una imagen anterior no entienda un esquema que la versión nueva ya modificó.

Un informe reciente de Immich en el que el servicio falló después de una ruta de actualización demuestra por qué las rutas de migración no compatibles o omitidas pueden hacer poco fiable un simple cambio de versión. Considera el hilo un caso práctico y verifica la secuencia exacta de migración de tus versiones.

Si la aplicación nueva nunca tocó la base de datos y el fallo se limita a la compatibilidad de la imagen o del entorno de ejecución, puede bastar con revertir a una imagen fijada. Si las migraciones se completaron, considera que la copia de seguridad de la base de datos previa a la actualización es la compañera más segura para la imagen antigua, a menos que tengas pruebas explícitas de compatibilidad.

Restaura una base de datos y un entorno de ejecución compatibles en lugar de mezclar épocas

Construye el objetivo de la reversión a partir de la última versión de la aplicación que funcionaba correctamente, su configuración de implementación compatible y el punto de recuperación de la base de datos anterior al cambio incompatible. Mantén intacto el árbol de archivos multimedia, salvo que la versión haya cambiado los archivos multimedia de una forma documentada; no vuelvas a copiar terabytes solo porque haya cambiado la imagen de la aplicación.

El debate sobre la reversión de bases de datos en la planificación de reversiones compatibles con bases de datos explica el peligro general de implementar código antiguo contra un esquema que ya no comprende. Ese principio es más importante que el hecho de que el contenedor se inicie correctamente.

Inicia la instancia revertida de forma aislada para que los clientes móviles y las tareas programadas no puedan escribir hasta que termine la validación. Si la versión antigua informa inmediatamente de errores de esquema, detente. No fuerces manualmente las migraciones hacia atrás en la única copia de la base de datos, a menos que tengas un procedimiento de recuperación probado y específico para cada versión.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Fija la imagen exacta que funcionaba correctamente y reproduce su configuración

Usa una versión específica o una referencia de imagen inmutable en lugar de una etiqueta cambiante. Restaura el entorno, las dependencias de servicio, las asignaciones de dispositivos, las redes, los puertos y el destino del proxy inverso que correspondan a la última implementación estable. Una reversión que cambia silenciosamente varias capas de la infraestructura crea un segundo incidente.

Conserva la imagen y la configuración nuevas que fallaron junto con las notas de la reversión. Esto permite una recuperación hacia adelante controlada después de comprender la incompatibilidad. Eliminar inmediatamente todos los artefactos nuevos puede dificultar la comparación de los estados fallido y funcional o la reproducción de la actualización en un entorno de prueba.

Si el servicio antiguo se inicia con el estado restaurado, revisa los registros antes de habilitar los clientes. Confirma que no haya un intento de migración inesperado, una inicialización de instalación nueva, un montaje de almacenamiento ausente ni una reescritura de permisos. Una simple página de inicio de sesión no demuestra que la reversión esté utilizando los datos previstos.

Valida la versión antigua con el desencadenante original y conserva una vía de avance

Prueba usuarios representativos, archivos antiguos y recientes, álbumes, uso compartido, búsqueda, una nueva carga controlada, tareas en segundo plano, la creación de una copia de seguridad de la base de datos y la ruta del proxy inverso. Reinicia la pila una vez y confirma que los mismos montajes y la base de datos vuelvan a estar disponibles sin intervención manual.

Mantén pausadas las nuevas cargas hasta que estas comprobaciones finalicen correctamente; después, vuelve a abrir el acceso y observa el periodo de carga normal. Conserva tanto la copia de seguridad previa a la actualización como la copia de seguridad del estado fallido de la versión nueva para poder reintentar la actualización más adelante en una copia aislada, una vez comprendido el problema de compatibilidad.

La reversión ha fallado si la versión antigua informa de incompatibilidad de esquema, faltan datos conocidos o las escrituras terminan en una ruta inesperada. Detente y restaura de nuevo el punto de recuperación conservado en lugar de superponer reparaciones. Solicita asistencia con las versiones exactas, los registros de migración, las marcas de tiempo de las copias de seguridad de la base de datos, la diferencia de Compose y el primer paso de verificación que falle.