How to Prevent Duplicate Photos After Migrating From a Cloud Library
Prevent duplicate photos by importing one canonical export first, then enabling phone backup only after exact copies and edited variants are classified.
Cloud-library migrations often contain originals, edited copies, resized downloads, shared-album versions, Live Photo components, metadata sidecars, and repeated export folders. A self-hosted gallery may reject exact-byte duplicates but still accept visually identical files whose compression, dimensions, metadata, or filenames differ. The safe process stages the migration outside the live library, records hashes and source folders, imports one controlled batch, and verifies how the gallery represents variants before automatic phone backup begins.
Inventory Every Source That Can Contain the Same Photo
List the cloud export archives, phone camera roll, desktop photo library, shared albums, download folders, partner libraries, old NAS folders, and any external library mounted into the gallery. Record the date range and file count for each source.
Duplicates often come from importing a cloud copy and then letting the phone upload its local original. An Immich discussion describes Google Photos and mobile backup producing apparent duplicates because the cloud version was compressed while the phone supplied a different full-resolution file.
Choose which source is authoritative for originals. Keep the others offline during the first import so a timeline filled with duplicates does not become the environment used to decide what to delete.
Separate Exact Duplicates From Visual Variants
Generate cryptographic hashes for files before import. Matching hashes indicate identical bytes, while different hashes may represent edits, recompression, metadata changes, resized exports, motion-photo components, or genuinely different captures.
Immich migration users have built pre-import hash checks because external-library transfers may not perform the same duplicate checking as API uploads. The reported strategy was to compare hashes before copying.
Do not automatically delete files merely because they look alike in a thumbnail. Preserve the higher-resolution original, the intended edit, motion components, and metadata sidecars until they have been compared outside the gallery.
Normalize Export Folder Structure Without Rewriting Originals
Extract every cloud archive into a staging directory and identify repeated archive chunks, “original” and “edited” suffixes, JSON sidecars, album duplicates, and files split across export packages.
Keep filenames and timestamps unchanged during the first inventory. Renaming, re-encoding, or rewriting metadata before hashing can convert exact duplicates into different-byte files that the gallery can no longer identify automatically.
Create a manifest containing source archive, original relative path, filename, hash, size, dimensions, capture time, and sidecar path. This makes every later deletion reversible and explains why two similar assets entered the library.
Import a Small Representative Batch First
Select a batch containing an ordinary JPEG, HEIC photo, edited image, Live Photo, video, burst, shared-album copy, and two exact duplicates. Import it through the same method planned for the full library.
Cloud and local assets can appear twice in a mobile timeline even when one represents the server copy and another remains only on the phone. An Immich report documents photos shown with both cloud and cloud-off states.
Verify whether the gallery rejects identical hashes, groups motion components, preserves edits, reads sidecars, and distinguishes local-only from uploaded assets. Adjust the import path before scaling to the full export.
Do Not Enable Mobile Backup Until Historical Import Is Stable
Pause automatic backup on every phone that contains part of the migrated cloud library. Otherwise the mobile client may upload thousands of assets while the server is still ingesting the same history from exported files.
Cross-source duplication can recur after a user keeps an external-library copy but deletes the upload, because the mobile client may later upload the same asset again. An Immich discussion describes a recurring mobile and external-library duplicate loop.
After the historical import finishes, compare the phone’s pending count with the server manifest. Enable backup for a small recent album first and confirm that known historical assets are skipped or represented as already backed up.
Handle External Libraries and Uploaded Libraries Deliberately
Decide whether migrated files will live as gallery-managed uploads or as an external read-only library. Avoid presenting the same physical files through both paths.
Moving assets from the managed library into an external library can produce duplicate timeline entries when the old database record remains and the new external scan adds another asset. The reported result was an orphaned record plus a new duplicate.
Use one ownership model per file set. If switching models, back up the database, complete the supported removal or cleanup of the old path, and verify that stale records disappear before scanning the new location.
Review Duplicates With Metadata and Recovery Context
When the gallery identifies duplicates, compare resolution, file size, codec, capture time, edit history, Live Photo pairing, album membership, favorites, face assignments, and backup source before choosing which asset to keep.
Near-duplicate detection can identify different resolutions or encodings of the same scene, but it cannot know which version preserves the user’s preferred edit or highest-quality original. Treat automated detection as a review queue rather than an instruction to delete.
The ZimaSpace NAS data migration guide provides the surrounding rule: keep the cloud export and original library until file counts, metadata, albums, and representative restores are verified.
Complete the Migration With a Reproducible Audit
Compare source manifests, imported file counts, rejected exact duplicates, retained variants, failed files, and phone pending counts. Spot-check several years, albums, edits, videos, and Live Photos.
Keep the original cloud export immutable and create a second backup of the self-hosted library before canceling a subscription or removing cloud assets. Duplicate cleanup is not a backup and should never be the only copy-changing operation.
The migration is complete when each original has one intentional canonical copy, edited variants remain distinguishable, phones upload only new assets, external and managed libraries do not overlap, and the manifest explains every excluded or retained duplicate.
Recommended products
Support & Tips
More to Read
Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes?
A volume-restore diagnosis covering xattr inventory, tar and Rsync options, namespaces, destination support, privileges, labels, app metadata, and tests.
Why Does a Running Container Keep Its Old Memory Limit After the Compose File Changes?
A memory-limit diagnosis covering live cgroups, restart versus recreation, Compose fields, hard and soft limits, parent scopes, swap, and runtime heaps.
Why Does Restarting a Reverse Proxy Invalidate Every Session for One Self-Hosted App?
A session-loss diagnosis covering restart scope, cookie ownership, secret rotation, cache-backed sessions, sticky routing, auth gateways, and recovery.
