Cómo evitar trabajos o importaciones duplicados en Immich

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Evita duplicar trabajos o importaciones de Immich separando primero dos síntomas distintos: que el mismo trabajo en segundo plano parezca ejecutarse de nuevo y que la misma foto se convierta en más de un recurso. Después, identifica qué cliente, importador, análisis de biblioteca, cambio de ruta o reintento produjo el segundo evento antes de eliminar nada.

El diseño más seguro asigna a cada grupo de recursos una ruta de ingesta canónica. Un archivo histórico en la nube, una biblioteca externa y una copia de seguridad activa del teléfono pueden ser opciones válidas, pero la propiedad superpuesta de los mismos archivos puede crear registros duplicados o bucles de recarga que ninguna limpieza posterior a la importación soluciona de forma fiable.

Identifica si tienes trabajo repetido o recursos duplicados

Para los trabajos repetidos, registra el nombre de la cola, el ID del recurso, la hora de inicio, el estado de finalización o fallo y el evento que precedió al nuevo trabajo. Un trabajo posterior legítimo creado después de procesar los metadatos es distinto de que el mismo trabajo fallido se reintente indefinidamente. No borres todas las colas hasta saber qué patrón está presente.

Para los recursos duplicados, compara la biblioteca de origen, la ruta original, el comportamiento de las sumas de comprobación cuando estén disponibles, el estado de la copia de seguridad del dispositivo, la fecha de captura y el tamaño del archivo. La misma imagen visible puede existir como dos archivos diferentes después de una exportación desde la nube, ediciones de metadatos, una transcodificación o el uso de bibliotecas externas basado en rutas, mientras que también pueden existir archivos idénticos a nivel de bytes en distintas fuentes de biblioteca de Immich.

Si las cargas normales empiezan a producir errores repetidos de suma de comprobación o de restricción de unicidad, conserva la base de datos e inspecciona el estado de la migración y del esquema antes de tratar el síntoma como un problema de la fuente de importación. Los recursos duplicados entre dos tipos de fuente legítimos y un fallo de restricción de la base de datos son situaciones distintas y no deben seguir el mismo proceso de limpieza.

La guía de ZimaSpace sobre el estado de la copia de seguridad del teléfono y la programación móvil resulta útil porque un cliente móvil tiene su propia visión de lo que aún necesita copiarse. La limpieza en el servidor que ignora el estado del cliente puede hacer que la siguiente sesión del teléfono vuelva a enviar los archivos.

Usa una única ruta de ingesta canónica para cada grupo de fotos existente

Elige cómo entrarán las fotos antiguas en Immich antes de activar la copia de seguridad continua del teléfono: por ejemplo, importa el archivo histórico una sola vez, verifícalo y deja que el teléfono aporte únicamente las capturas nuevas. Si los mismos archivos históricos están montados como biblioteca externa y además se cargan mediante la biblioteca de cargas normal, no supongas que la deduplicación global reconciliará ambas fuentes.

Un informe sobre duplicados entre fuentes de Immich documenta la coexistencia de contenido idéntico cuando procede de una biblioteca externa y de la biblioteca de cargas. Trátalo como un límite del comportamiento del proyecto: la propiedad de la fuente importa, por lo que la prevención es más fiable que esperar que una herramienta de duplicados posterior deduzca qué copia prefieres.

Evita mover archivos que Immich cargó internamente a una biblioteca externa sin informarle mientras el teléfono aún los considera parte de su conjunto de copias de seguridad. Si la arquitectura de almacenamiento debe cambiar, migra mediante una ruta documentada, con copias de seguridad y un grupo de prueba pequeño; después, confirma que la aplicación móvil y el servidor coinciden antes de eliminar la copia antigua.

Controla los reintentos y el estado del cliente antes de ampliar la importación

Usa un manifiesto de preparación para una importación manual grande: registra la ruta de origen, el número de archivos, el total de bytes y una suma de comprobación estable o el resultado del importador cuando sea práctico. Si una importación se interrumpe, reanúdala con la misma herramienta y el mismo destino en lugar de iniciar un segundo importador independiente contra la misma fuente mientras el estado del primer trabajo siga sin estar claro.

Un informe reciente sobre cargas repetidas de Immich mostró que un cliente móvil reintentaba continuamente recursos que el servidor ya tenía, con errores de restricción de unicidad en el servidor. Trátalo como una evidencia limitada a esa versión: el estado de la copia de seguridad del cliente puede ser el responsable del bucle; no lo generalices como un comportamiento universal de la aplicación móvil. Los cambios de ruta siguen siendo un riesgo independiente. Mantén estables las rutas de las bibliotecas externas visibles para el contenedor durante una importación grande y, si es necesario trasladar el almacenamiento, migra primero un grupo pequeño. Si la segunda copia aparece únicamente después de un cambio de ruta, sigue la rama de identidad de la ruta en lugar de restablecer el estado de la copia de seguridad del teléfono.

-15% OFF

Prueba la interrupción, el reintento y un recurso realmente nuevo

Crea un grupo representativo pequeño que incluya fotos normales, vídeos, una imagen editada y al menos un archivo que ya exista en la ruta de destino. Impórtalo una vez, registra el número de recursos y sus ID, y después interrumpe un segundo intento controlado o vuelve a analizarlo según el flujo de trabajo que planees usar en producción.

La prueba es satisfactoria si no aparece un segundo recurso inexplicable para el mismo objeto de origen previsto, los reintentos se estabilizan sin que la cola crezca permanentemente y una foto realmente nueva se importa correctamente. También debes volver a abrir el cliente móvil después de la prueba para que su estado de copia de seguridad no discrepe silenciosamente del servidor.

Si los duplicados solo vuelven a aparecer entre las fuentes de la biblioteca de cargas y de la biblioteca externa, rediseña el límite de propiedad en lugar de fusionarlos repetidamente. Si el mismo ID de recurso recibe un trabajo fallido sin fin, aísla ese trabajo y ese archivo. Solicita asistencia incluyendo el tipo de fuente, las rutas, los hashes cuando sean pertinentes, las versiones, el estado de la copia de seguridad del cliente y el grupo reproducible más pequeño.

Soporte y Consejos

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.