Come evitare foto duplicate dopo la migrazione da una libreria cloud
Previeni le foto duplicate importando prima un’unica esportazione canonica, quindi attivando il backup del telefono solo dopo aver classificato le copie esatte e le varianti modificate.
Le migrazioni delle librerie cloud contengono spesso originali, copie modificate, download ridimensionati, versioni degli album condivisi, componenti delle Live Photo, file sidecar con metadati e cartelle di esportazione ripetute. Una galleria self-hosted può rifiutare i duplicati con byte identici, ma accettare comunque file visivamente identici con compressione, dimensioni, metadati o nomi file diversi. La procedura sicura consiste nell’eseguire la migrazione fuori dalla libreria attiva, registrare gli hash e le cartelle di origine, importare un batch controllato e verificare come la galleria rappresenta le varianti prima di attivare il backup automatico del telefono.
Fai l’inventario di ogni origine che può contenere la stessa foto
Elenca gli archivi di esportazione cloud, il rullino fotografico del telefono, la libreria fotografica del desktop, gli album condivisi, le cartelle dei download, le librerie dei partner, le vecchie cartelle NAS e qualsiasi libreria esterna montata nella galleria. Registra l’intervallo di date e il numero di file per ogni origine.
I duplicati spesso derivano dall’importazione di una copia cloud seguita dall’upload dell’originale locale da parte del telefono. Una discussione su Immich descrive casi in cui Google Photos e il backup mobile producevano duplicati apparenti perché la versione cloud era compressa, mentre il telefono forniva un file diverso a piena risoluzione.
Scegli quale origine sarà autorevole per gli originali. Mantieni le altre offline durante la prima importazione, così una timeline piena di duplicati non diventa l’ambiente utilizzato per decidere cosa eliminare.
Separa i duplicati esatti dalle varianti visive
Genera hash crittografici per i file prima dell’importazione. Gli hash corrispondenti indicano byte identici, mentre hash diversi possono rappresentare modifiche, ricompressione, variazioni dei metadati, esportazioni ridimensionate, componenti di foto animate o scatti realmente diversi.
Gli utenti che migrano a Immich hanno creato controlli degli hash prima dell’importazione perché i trasferimenti da librerie esterne potrebbero non eseguire lo stesso controllo dei duplicati degli upload tramite API. La strategia descritta consisteva nel confrontare gli hash prima della copia.
Non eliminare automaticamente i file solo perché sembrano uguali in una miniatura. Conserva l’originale a risoluzione maggiore, la modifica desiderata, i componenti animati e i file sidecar con metadati finché non saranno stati confrontati fuori dalla galleria.
Normalizza la struttura delle cartelle esportate senza riscrivere gli originali
Estrai ogni archivio cloud in una directory di staging e individua i blocchi di archivio ripetuti, i suffissi “originale” e “modificato”, i file sidecar JSON, i duplicati degli album e i file suddivisi tra più pacchetti di esportazione.
Mantieni invariati nomi file e timestamp durante il primo inventario. Rinominare, ricodificare o riscrivere i metadati prima del calcolo degli hash può trasformare duplicati esatti in file con byte diversi, che la galleria non sarà più in grado di identificare automaticamente.
Crea un manifest contenente l’archivio di origine, il percorso relativo originale, il nome file, l’hash, la dimensione, le dimensioni dell’immagine, l’ora dello scatto e il percorso del sidecar. In questo modo ogni eliminazione successiva sarà reversibile e sarà possibile spiegare perché due risorse simili sono entrate nella libreria.
Importa prima un piccolo batch rappresentativo
Seleziona un batch contenente un normale JPEG, una foto HEIC, un’immagine modificata, una Live Photo, un video, una raffica, una copia di un album condiviso e due duplicati esatti. Importalo utilizzando lo stesso metodo previsto per l’intera libreria.
Le risorse cloud e locali possono apparire due volte nella timeline mobile anche quando una rappresenta la copia sul server e l’altra rimane solo sul telefono. Un report su Immich documenta foto visualizzate con entrambi gli stati cloud e cloud-off.
Verifica se la galleria rifiuta gli hash identici, raggruppa i componenti animati, conserva le modifiche, legge i sidecar e distingue le risorse solo locali da quelle caricate. Modifica il percorso di importazione prima di estenderlo all’intera esportazione.
Non attivare il backup mobile finché l’importazione storica non è stabile
Sospendi il backup automatico su ogni telefono che contiene parte della libreria cloud migrata. Altrimenti il client mobile potrebbe caricare migliaia di risorse mentre il server sta ancora importando la stessa cronologia dai file esportati.
La duplicazione tra origini può ripetersi quando l’utente conserva una copia nella libreria esterna ma elimina quella caricata, perché il client mobile potrebbe caricare nuovamente la stessa risorsa. Una discussione su Immich descrive un ciclo ricorrente di duplicati tra dispositivo mobile e libreria esterna.
Al termine dell’importazione storica, confronta il numero di elementi in attesa sul telefono con il manifest del server. Attiva prima il backup per un piccolo album recente e verifica che le risorse storiche note vengano ignorate o risultino già sottoposte a backup.
Gestisci con attenzione le librerie esterne e quelle con risorse caricate
Decidi se i file migrati risiederanno come upload gestiti dalla galleria o come libreria esterna in sola lettura. Evita di presentare gli stessi file fisici attraverso entrambi i percorsi.
Spostare le risorse dalla libreria gestita a una libreria esterna può produrre voci duplicate nella timeline quando il vecchio record del database rimane e la nuova scansione esterna aggiunge un’altra risorsa. Il risultato segnalato è stato un record orfano più un nuovo duplicato.
Usa un solo modello di gestione per ogni insieme di file. Se cambi modello, esegui il backup del database, completa la rimozione o la pulizia supportata del vecchio percorso e verifica che i record obsoleti scompaiano prima di eseguire la scansione della nuova posizione.
Esamina i duplicati considerando metadati e possibilità di recupero
Quando la galleria identifica i duplicati, confronta risoluzione, dimensione del file, codec, ora dello scatto, cronologia delle modifiche, abbinamento delle Live Photo, appartenenza agli album, preferiti, assegnazioni dei volti e origine del backup prima di scegliere quale risorsa conservare.
Il rilevamento dei quasi duplicati può identificare risoluzioni o codifiche diverse della stessa scena, ma non può sapere quale versione conserva la modifica preferita dall’utente o l’originale di qualità migliore. Considera il rilevamento automatico come una coda di revisione, non come un’istruzione per eliminare.
La guida alla migrazione dei dati NAS di ZimaSpace fornisce la regola generale: conserva l’esportazione cloud e la libreria originale finché non avrai verificato il numero di file, i metadati, gli album e alcuni ripristini rappresentativi.
Completa la migrazione con un audit riproducibile
Confronta i manifest di origine, il numero di file importati, i duplicati esatti rifiutati, le varianti conservate, i file non riusciti e il numero di elementi in attesa sul telefono. Esegui controlli a campione su diversi anni, album, modifiche, video e Live Photo.
Mantieni immutabile l’esportazione cloud originale e crea un secondo backup della libreria self-hosted prima di annullare un abbonamento o rimuovere le risorse dal cloud. La pulizia dei duplicati non è un backup e non dovrebbe mai essere l’unica operazione che modifica le copie.
La migrazione è completa quando ogni originale ha una sola copia canonica intenzionale, le varianti modificate restano distinguibili, i telefoni caricano solo le nuove risorse, le librerie esterne e gestite non si sovrappongono e il manifest spiega ogni duplicato escluso o conservato.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
