No retires el antiguo servidor de Immich solo porque el nuevo panel se cargue y aparezcan las fotos. Retíralo únicamente después de que el sistema restaurado demuestre que funcionan los usuarios, álbumes, personas, búsquedas, originales seleccionados, nuevas cargas, tareas en segundo plano, reinicios y una copia de seguridad nueva, mientras el host antiguo siga disponible como objetivo de reversión.
Mantén el servidor antiguo apagado pero sin modificar durante la validación, para que dos instancias no acepten cargas con estados divergentes. Asigna primero al host restaurado una dirección de prueba controlada, registra una línea base del sistema antiguo y compara los mismos flujos de trabajo del hogar en lugar de confiar en la impresión visual de que la cronología parece completa.
Mantén intacto el servidor antiguo mientras estableces una línea base de restauración
Antes del cambio, registra el número de usuarios y recursos, algunos álbumes representativos, personas identificadas, favoritos, elementos compartidos, rutas de bibliotecas externas y varios originales de muestra de distintas fechas y usuarios. Registra también las versiones antiguas de Immich y PostgreSQL, así como los artefactos de copia de seguridad utilizados para la restauración. Las comprobaciones de integridad de carpetas o almacenamiento son controles útiles, pero no sustituyen la verificación a nivel de relaciones.
El modelo de recuperación de ZimaSpace para restaurar una biblioteca de fotos consultable considera los originales, el estado del catálogo o la base de datos y la configuración que define las rutas como una sola unidad de recuperación. Esa es la línea base adecuada porque los archivos de imagen sueltos por sí solos no pueden demostrar que hayan sobrevivido las relaciones de pertenencia a álbumes, propiedad, personas y búsquedas.
No borres los discos antiguos, no reutilices permanentemente su IP ni elimines todavía la última copia de seguridad conocida como válida. El objetivo de verificación debe ser reversible: si falta una relación crítica, necesitas el estado antiguo para determinar si el problema provino de la copia de seguridad, del método de restauración, de la asignación de rutas o del nuevo entorno de ejecución.
Verifica las relaciones, no solo la visibilidad de las fotos
Inicia sesión con más de un usuario esperado y comprueba que cada cuenta vea los recursos y elementos compartidos correctos. Abre álbumes conocidos, personas identificadas, favoritos, recuerdos u otras relaciones específicas del hogar que serían difíciles de reconstruir únicamente a partir de los archivos. Compara un conjunto pequeño con la línea base registrada del servidor antiguo.
Una discusión sobre una migración de Immich con álbumes desaparecidos tras una restauración de PostgreSQL muestra por qué esto importa: las fotos podían permanecer mientras faltaba el estado de los álbumes, y una nueva exportación de la base de datos posterior cambiaba el resultado. Tómalo como evidencia de que un inicio de sesión correcto o una cronología visible no constituyen una prueba de restauración completa.
Busca varios recursos conocidos mediante metadatos y cualquier función visual o de personas habilitada. Si los originales están presentes pero faltan relaciones o resultados de búsqueda, determina si el estado correspondiente debería haberse restaurado o si se está regenerando intencionadamente. No retires el servidor antiguo mientras esa distinción siga sin resolverse.
Prueba las rutas de lectura, escritura, dependencias y reinicio
Abre directamente fotos y vídeos antiguos desde el almacenamiento restaurado y, después, carga un recurso nuevo desechable desde un cliente móvil o web. Confirma que su original se escriba en la ruta prevista, que aparezca para el usuario correcto y que sus tareas en segundo plano avancen. Prueba las bibliotecas externas y el acceso remoto solo después de estabilizar la ruta local de lectura y escritura.
Las pruebas de restauración deben validar la aplicación después de copiar los datos. Una guía actual de pruebas de recuperación ante desastres recomienda una validación a nivel de aplicación que incluya bases de datos, permisos, conexiones de red y servicios, en lugar de detenerse al completar una tarea de copia de seguridad o restauración. Reinicia la pila de Immich dos veces y reinicia una vez el nuevo host. Después de cada ciclo, confirma que vuelvan a funcionar los mismos montajes, usuarios, recursos de muestra, base de datos, proxy o punto de acceso local y comportamiento de las tareas. Un servicio que funciona solo hasta el primer reinicio del host no ha superado la migración.
Crea una copia de seguridad nueva antes de cerrar la ventana de reversión
Crea una copia de seguridad nueva y coherente con la base de datos, y protege el alcance de medios y configuración requerido por el diseño de recuperación. Restaura al menos un pequeño objetivo de validación o inspecciona la copia de seguridad con el mismo proceso utilizado antes del cambio. Un servidor restaurado que no puede producir su propia copia de seguridad recuperable no debería convertirse en la única copia de producción.
Somete el nuevo host a un periodo de observación definido que incluya cargas normales desde el teléfono, navegación, búsquedas, procesamiento en segundo plano, copias de seguridad programadas y al menos un ciclo nocturno. Mantén apagado el host antiguo para que no divida el estado, pero consérvalo sin cambios hasta que el nuevo sistema supere esos eventos sin diferencias inexplicables.
La decisión de proceder requiere que coincidan las relaciones críticas, que los originales sean legibles, que las nuevas escrituras se realicen correctamente, que los reinicios sean estables y que exista una copia de seguridad nueva y verificada.
Si desaparecen usuarios, las cantidades divergen considerablemente, reaparecen errores de rutas o la base de datos informa de problemas de coherencia, apaga la nueva instancia y conserva ambos lados antes de investigar. Solo entonces deberías borrar o reutilizar el servidor antiguo.
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...

