Cómo mover los datos de Immich sin perder usuarios, historial ni configuración

Mueve Immich como una migración del estado de la aplicación, no como una simple copia de carpetas: conserva la base de datos, el árbol multimedia, la configuración, los secretos y las rutas que los conectan.

Una migración puede parecer exitosa porque todas las imágenes JPEG existen en el disco nuevo, mientras faltan las cuentas, los álbumes, las personas, los elementos compartidos, los favoritos o las relaciones históricas. Crea primero un punto de reversión, captura un estado de origen coherente, cópialo sin cambiar los identificadores, restáuralo en un destino aislado y cambia al nuevo sistema solo después de comprobar que los flujos de trabajo del hogar coinciden.

Haz un inventario del estado que debe migrarse conjuntamente

Enumera la base de datos PostgreSQL, los archivos multimedia subidos, los datos generados que quieras conservar, las definiciones de bibliotecas externas, la configuración de Compose o de la aplicación, los valores de entorno, los secretos, los nombres de red y las asignaciones de almacenamiento actuales. Marca qué elemento es la fuente autorizada y cuál puede regenerarse después de la recuperación.

Una discusión de 2026 sobre cómo conservar los usuarios de Immich durante una migración refuerza el punto central: el estado de los usuarios y de la biblioteca está vinculado a la base de datos y a las rutas montadas, no a la imagen del contenedor. Trata los comandos de la comunidad como ejemplos y adáptalos a la versión exacta implementada.

Anota un pequeño conjunto de verificación antes de la migración: dos usuarios, varios álbumes, favoritos, elementos compartidos, una persona o resultado de búsqueda, archivos antiguos y recientes, y una ruta de biblioteca externa si se utiliza. Esos registros conocidos harán que la validación posterior sea mucho más sólida que comparar únicamente el tamaño total de los archivos.

Crea un punto de recuperación coherente antes de copiar

Pausa las nuevas cargas o programa una ventana de mantenimiento para que el origen deje de cambiar mientras capturas el estado de migración. Haz una copia de seguridad nativa de la base de datos y protege los archivos multimedia y la configuración del origen. Mantén intacta la instancia original después de la captura hasta que el destino haya superado la verificación.

La guía de recuperación de ZimaSpace sobre cómo restaurar conjuntamente los componentes de una biblioteca de fotos explica por qué los originales, el estado del catálogo y la configuración que define las rutas deben representar un punto de recuperación compatible. Ese es el mismo límite que necesita una migración.

No uses el directorio de la base de datos de producción activa como destino de una copia de archivos normal mientras esté cambiando. Si el tiempo de inactividad debe ser breve, utiliza un volcado compatible con la base de datos y un método de almacenamiento cuyo orden de captura comprendas. Una migración solo es recuperable en la medida en que puedas restaurar el punto capturado, no según el número de archivos copiados.

Copia los archivos multimedia conservando rutas y permisos

Copia el árbol multimedia al destino sin reorganizar las carpetas durante la migración. Conserva el propietario, los permisos, las marcas de tiempo y cualquier función del sistema de archivos de la que dependa tu implementación. Si se supone que la ruta visible dentro del contenedor debe mantenerse igual, cambia el origen del montaje en el host, pero conserva estable la asignación dentro del contenedor.

El flujo de trabajo actual de migración con rsync destaca el modo de archivo, las ejecuciones de prueba, las transferencias reanudables y el peligro de las opciones de espejo destructivas. Ejecuta una comparación de prueba antes de eliminar nada y verifica el destino en lugar de asumir que un comando completado equivale a una migración completa de la aplicación.

Compara el número y el tamaño de los archivos y verifica después una muestra representativa de sumas de comprobación que incluya fotos antiguas, fotos nuevas, vídeos y archivos grandes. Si aparecen errores de copia o archivos «desaparecidos» porque el origen cambió, deja de aceptar cargas y repite la pasada diferencial en lugar de eliminar el origen para obtener un destino que solo parezca limpio.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Restaura la base de datos y la configuración en un destino aislado

Inicia el destino con un nombre de host temporal o en una red aislada para que los clientes móviles no puedan cargar archivos durante la validación. Conecta los archivos multimedia copiados en las rutas esperadas dentro del contenedor, restaura la base de datos correspondiente y reproduce el entorno, los secretos, las redes y la configuración del proxy necesarios para esa versión.

Otro informe independiente de 2026 sobre una migración de servidor por etapas muestra por qué los operadores prueban el nuevo host antes de retirar el antiguo. Usa esos informes para identificar posibles fallos, pero deja que tus registros conocidos determinen si la migración realmente conservó el estado.

Detente si el destino se abre como una instalación nueva, informa de almacenamiento ausente o propone una inicialización destructiva. Esos síntomas suelen indicar que la base de datos o los montajes no son los esperados. Corrige primero la ruta o el destino de restauración; no cargues archivos nuevos en una instancia que parece vacía ni crees dos historiales en conflicto.

Cambia al nuevo sistema solo después de comprobar los usuarios, el historial y las nuevas escrituras

Inicia sesión con cada usuario de referencia y verifica la pertenencia a álbumes, los favoritos, los elementos compartidos, el estado de búsqueda o de personas, los archivos originales representativos, las marcas de tiempo y el número esperado de elementos de la biblioteca. Después, carga una foto de prueba nueva y confirma que aparece, se procesa y sigue disponible tras reiniciar el contenedor.

Cambia el destino de producción del DNS o del proxy solo después de superar la prueba aislada. Mantén la instancia antigua detenida, pero recuperable, para que ambos sistemas no puedan aceptar escrituras simultáneamente. Conserva la copia de seguridad de la base de datos previa a la migración y los archivos multimedia del origen hasta que el nuevo host haya completado las copias de seguridad habituales y al menos una prueba de restauración.

Revierte la migración si los recuentos no coinciden, desaparecen relaciones conocidas, las nuevas cargas se escriben en el disco equivocado o el destino falla después de reiniciarse. Al escalar el problema, incluye las versiones de origen y destino, la marca de tiempo de la copia de seguridad de la base de datos, los mapas de montajes, los registros de copia, las diferencias de permisos y el primer elemento de verificación que haya fallado.