Cómo evitar fotos duplicadas después de migrar desde una biblioteca en la nube
Evita las fotos duplicadas importando primero una exportación canónica y activando después la copia de seguridad del teléfono, solo cuando las copias exactas y las variantes editadas estén clasificadas.
Las migraciones de bibliotecas en la nube suelen contener originales, copias editadas, descargas redimensionadas, versiones de álbumes compartidos, componentes de Live Photo, archivos sidecar de metadatos y carpetas de exportación repetidas. Una galería autoalojada puede rechazar duplicados con los mismos bytes, pero aceptar archivos visualmente idénticos cuya compresión, dimensiones, metadatos o nombres de archivo difieran. El proceso seguro prepara la migración fuera de la biblioteca activa, registra los hashes y las carpetas de origen, importa un lote controlado y verifica cómo representa la galería las variantes antes de iniciar la copia de seguridad automática del teléfono.
Haz un inventario de todas las fuentes que pueden contener la misma foto
Haz una lista de los archivos de exportación de la nube, el carrete de la cámara del teléfono, la biblioteca de fotos del ordenador, los álbumes compartidos, las carpetas de descargas, las bibliotecas de otros usuarios, las carpetas de NAS antiguas y cualquier biblioteca externa montada en la galería. Registra el intervalo de fechas y el número de archivos de cada fuente.
Los duplicados suelen aparecer al importar una copia de la nube y permitir después que el teléfono suba su original local. Una conversación de Immich describe cómo Google Photos y la copia de seguridad móvil generaban duplicados aparentes porque la versión de la nube estaba comprimida, mientras que el teléfono proporcionaba un archivo diferente en resolución completa.
Elige qué fuente será la autoridad para los originales. Mantén las demás desconectadas durante la primera importación para que una cronología llena de duplicados no se convierta en el entorno utilizado para decidir qué eliminar.
Separa los duplicados exactos de las variantes visuales
Genera hashes criptográficos de los archivos antes de importarlos. Los hashes coincidentes indican bytes idénticos, mientras que los hashes diferentes pueden representar ediciones, recomprensión, cambios de metadatos, exportaciones redimensionadas, componentes de fotos con movimiento o capturas realmente distintas.
Los usuarios que migran a Immich han creado comprobaciones de hashes previas a la importación porque las transferencias desde bibliotecas externas pueden no realizar la misma comprobación de duplicados que las cargas mediante API. La estrategia descrita consistía en comparar los hashes antes de copiar.
No elimines automáticamente archivos solo porque parezcan iguales en una miniatura. Conserva el original de mayor resolución, la edición deseada, los componentes de movimiento y los archivos sidecar de metadatos hasta haberlos comparado fuera de la galería.
Normaliza la estructura de las carpetas de exportación sin reescribir los originales
Extrae todos los archivos de la nube en un directorio de preparación e identifica los fragmentos de archivo repetidos, los sufijos «original» y «editado», los archivos sidecar JSON, los duplicados de álbumes y los archivos divididos entre varios paquetes de exportación.
Mantén sin cambios los nombres de archivo y las marcas de tiempo durante el primer inventario. Cambiar nombres, recodificar o reescribir metadatos antes de calcular los hashes puede convertir duplicados exactos en archivos con bytes diferentes que la galería ya no pueda identificar automáticamente.
Crea un manifiesto que incluya el archivo de origen, la ruta relativa original, el nombre de archivo, el hash, el tamaño, las dimensiones, la fecha de captura y la ruta del archivo sidecar. Así, cada eliminación posterior será reversible y se podrá explicar por qué dos recursos similares entraron en la biblioteca.
Importa primero un lote pequeño y representativo
Selecciona un lote que contenga un JPEG normal, una foto HEIC, una imagen editada, una Live Photo, un vídeo, una ráfaga, una copia de un álbum compartido y dos duplicados exactos. Impórtalo mediante el mismo método previsto para toda la biblioteca.
Los recursos de la nube y los locales pueden aparecer dos veces en una cronología móvil aunque uno represente la copia del servidor y el otro permanezca únicamente en el teléfono. Un informe de Immich documenta fotos mostradas con estados de nube y de nube desactivada.
Verifica si la galería rechaza hashes idénticos, agrupa los componentes de movimiento, conserva las ediciones, lee los archivos sidecar y distingue entre recursos solo locales y recursos subidos. Ajusta el método de importación antes de ampliar el proceso a toda la exportación.
No actives la copia de seguridad móvil hasta que la importación histórica sea estable
Pausa la copia de seguridad automática en todos los teléfonos que contengan parte de la biblioteca de la nube migrada. De lo contrario, el cliente móvil podría subir miles de recursos mientras el servidor todavía incorpora el mismo historial desde los archivos exportados.
La duplicación entre fuentes puede repetirse cuando un usuario conserva una copia de la biblioteca externa, pero elimina la carga, ya que el cliente móvil podría volver a subir después el mismo recurso. Una conversación de Immich describe un ciclo recurrente de duplicados entre el móvil y la biblioteca externa.
Cuando termine la importación histórica, compara el número de elementos pendientes del teléfono con el manifiesto del servidor. Activa primero la copia de seguridad de un álbum reciente pequeño y confirma que los recursos históricos conocidos se omitan o aparezcan como ya respaldados.
Gestiona deliberadamente las bibliotecas externas y las bibliotecas cargadas
Decide si los archivos migrados vivirán como cargas gestionadas por la galería o como una biblioteca externa de solo lectura. Evita presentar los mismos archivos físicos mediante ambas rutas.
Mover recursos de la biblioteca gestionada a una biblioteca externa puede generar entradas duplicadas en la cronología cuando el registro antiguo de la base de datos permanece y el nuevo escaneo externo añade otro recurso. El resultado descrito fue un registro huérfano junto con un nuevo duplicado.
Utiliza un único modelo de propiedad para cada conjunto de archivos. Si cambias de modelo, haz una copia de seguridad de la base de datos, completa la eliminación o limpieza compatible de la ruta antigua y verifica que desaparezcan los registros obsoletos antes de escanear la nueva ubicación.
Revisa los duplicados con contexto de metadatos y recuperación
Cuando la galería identifique duplicados, compara la resolución, el tamaño del archivo, el códec, la fecha de captura, el historial de edición, la asociación de la Live Photo, la pertenencia a álbumes, los favoritos, las asignaciones faciales y el origen de la copia de seguridad antes de elegir qué recurso conservar.
La detección de duplicados similares puede identificar distintas resoluciones o codificaciones de la misma escena, pero no puede saber qué versión conserva la edición preferida del usuario o el original de mayor calidad. Trata la detección automática como una cola de revisión, no como una instrucción para eliminar.
La guía de migración de datos de NAS de ZimaSpace establece la regla general: conserva la exportación de la nube y la biblioteca original hasta verificar los recuentos de archivos, los metadatos, los álbumes y restauraciones representativas.
Completa la migración con una auditoría reproducible
Compara los manifiestos de origen, el número de archivos importados, los duplicados exactos rechazados, las variantes conservadas, los archivos fallidos y los elementos pendientes del teléfono. Comprueba manualmente varios años, álbumes, ediciones, vídeos y Live Photos.
Mantén inmutable la exportación original de la nube y crea una segunda copia de seguridad de la biblioteca autoalojada antes de cancelar una suscripción o eliminar recursos de la nube. La limpieza de duplicados no es una copia de seguridad y nunca debe ser la única operación que cambie las copias.
La migración está completa cuando cada original tiene una única copia canónica intencionada, las variantes editadas siguen siendo distinguibles, los teléfonos solo suben recursos nuevos, las bibliotecas externas y gestionadas no se solapan y el manifiesto explica cada duplicado excluido o conservado.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
