Come impedire la duplicazione di processi o importazioni in Immich

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Previeni i processi o le importazioni duplicate di Immich separando innanzitutto due sintomi diversi: la stessa attività in background che sembra essere eseguita di nuovo e la stessa foto che diventa più di un asset. Poi identifica quale client, importatore, scansione della libreria, modifica del percorso o nuovo tentativo ha prodotto il secondo evento prima di eliminare qualsiasi elemento.

La progettazione più sicura assegna a ogni gruppo di asset un unico percorso di acquisizione canonico. Un archivio cloud storico, una libreria esterna e un backup attivo del telefono possono essere tutti validi, ma la gestione sovrapposta degli stessi file può creare record duplicati o cicli di nuova importazione che nessuna pulizia successiva riesce a correggere in modo affidabile.

Identifica se hai attività ripetute o asset duplicati

Per le attività ripetute, annota il nome della coda, l’ID dell’asset, l’ora di avvio, lo stato di completamento o errore e l’evento che ha preceduto la nuova attività. Un’attività successiva legittima, creata dopo l’elaborazione dei metadati, è diversa dallo stesso processo fallito che continua a essere ritentato. Non svuotare tutte le code finché non sai quale schema è presente.

Per gli asset duplicati, confronta la libreria di origine, il percorso originale, il comportamento dei checksum quando disponibile, lo stato del backup del dispositivo, l’ora di acquisizione e le dimensioni del file. La stessa immagine visibile può esistere come due file diversi dopo un’esportazione dal cloud, modifiche ai metadati, una transcodifica o la gestione di una libreria esterna basata sul percorso, mentre file identici a livello di byte possono esistere anche in diverse origini della libreria di Immich.

Se i normali caricamenti iniziano a produrre ripetuti errori di checksum o di vincolo di unicità, conserva il database e controlla lo stato dello schema e delle migrazioni prima di considerare il sintomo un problema dell’origine dell’importazione. Gli asset duplicati tra due tipi di origine legittimi e un errore di vincolo del database sono casi diversi e non devono essere sottoposti alla stessa procedura di pulizia.

La guida di ZimaSpace sullo stato del backup del telefono e sulla pianificazione mobile è utile perché un client mobile ha una propria visione di ciò che deve ancora essere sottoposto a backup. Una pulizia lato server che ignora lo stato del client può far sì che la sessione successiva del telefono invii nuovamente i file.

Usa un unico percorso di acquisizione canonico per ogni gruppo di foto esistente

Scegli come devono entrare in Immich le vecchie foto prima di abilitare il backup continuo del telefono: ad esempio, importa una volta l’archivio storico, verificalo e poi lascia che il telefono contribuisca solo con le nuove acquisizioni. Se gli stessi file storici sono sia montati come libreria esterna sia caricati tramite la normale libreria di caricamento, non presumere che la deduplicazione globale riconcili automaticamente le due origini.

Una segnalazione di duplicati tra origini di Immich documenta la coesistenza di contenuti identici quando provengono da una libreria esterna e dalla libreria di caricamento. Considerala un limite del comportamento del progetto: la proprietà dell’origine è importante, quindi la prevenzione è più affidabile che aspettarsi che un’utilità di deduplicazione successiva deduca quale copia preferisci.

Evita di spostare file caricati internamente da Immich in una libreria esterna senza informarlo mentre il telefono li considera ancora parte del proprio insieme di backup. Se l’architettura di archiviazione deve cambiare, esegui la migrazione seguendo un percorso documentato, con backup e un piccolo gruppo di prova, quindi verifica che l’app mobile e il server siano d’accordo prima di eliminare la vecchia copia.

Controlla i nuovi tentativi e lo stato del client prima di ampliare l’importazione

Usa un manifesto di staging per una grande importazione manuale: registra il percorso di origine, il numero di file, i byte totali e, quando possibile, un checksum stabile o il risultato dell’importatore. Se un’importazione viene interrotta, riprendila usando lo stesso strumento e la stessa destinazione invece di avviare un secondo importatore indipendente sulla stessa origine mentre lo stato del primo processo è incerto.

Una recente segnalazione di caricamenti ripetuti di Immich ha mostrato un client mobile che ritentava continuamente l’invio di asset già presenti sul server, con errori di vincolo di unicità sul server. Considerala una prova circoscritta alla versione in questione del fatto che lo stato del backup del client può essere il responsabile del ciclo; non generalizzarla come comportamento universale dell’app mobile. Le modifiche ai percorsi restano un rischio distinto. Mantieni stabili i percorsi delle librerie esterne visibili al container durante una grande importazione e, se è necessario spostare lo spazio di archiviazione, esegui prima la migrazione di un piccolo gruppo. Se la seconda copia compare solo dopo una modifica del percorso, segui il ramo relativo all’identità del percorso invece di reimpostare lo stato del backup del telefono.

-15% OFF

Verifica l’interruzione, i nuovi tentativi e un asset realmente nuovo

Crea un piccolo gruppo rappresentativo che includa foto normali, video, un’immagine modificata e almeno un file già presente nel percorso di destinazione. Importalo una volta, registra il numero e gli ID degli asset, quindi interrompi un secondo tentativo controllato o una nuova scansione secondo il flusso di lavoro che prevedi di usare in produzione.

Il test è superato se non compare un secondo asset non spiegato per lo stesso oggetto di origine previsto, i nuovi tentativi si esauriscono senza una coda che cresce permanentemente e una foto realmente nuova viene comunque importata correttamente. Dopo il test, riapri anche il client mobile in modo che il suo stato del backup non sia in disaccordo silenzioso con il server.

Se i duplicati ricompaiono solo tra le origini della libreria di caricamento e della libreria esterna, riprogetta il confine di proprietà invece di continuare a unirli. Se lo stesso ID asset riceve un processo in errore senza fine, isola quel processo e quel file. Inoltra il problema includendo il tipo di origine, i percorsi, gli hash quando pertinenti, le versioni, lo stato del backup del client e il gruppo minimo riproducibile.

Supporto e consigli

Altro da leggere

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.