Immich mostra dati obsoleti dopo una modifica del percorso di archiviazione
I dati obsoleti di Immich dopo una modifica del percorso di archiviazione possono avere tre cause diverse, che non vanno confuse: lo spostamento della radice dei contenuti gestiti, la modifica del percorso di importazione di una libreria esterna oppure un client che continua a mostrare uno stato memorizzato nella cache. Le versioni moderne di Immich possono riconciliare una posizione spostata dei contenuti gestiti quando la posizione configurata dei contenuti e il montaggio del volume rimangono coerenti, mentre gli spostamenti delle librerie esterne possono ancora essere trattati come nuove identità di risorse.
Conserva il vecchio percorso e il database prima di avviare una nuova scansione. Verifica innanzitutto quale percorso vede il container in esecuzione, quindi stabilisci se il record lato server di Immich è errato oppure se è obsoleto soltanto un client. Questa distinzione determina se devi correggere un montaggio, ripristinare un percorso stabile visibile al container, analizzare un sottoinsieme di prova o cancellare solo la cache del client.
Distinguere lo spostamento della radice dei contenuti gestiti da quello di una libreria esterna
Se hai modificato la posizione sull’host dei caricamenti gestiti da Immich, verifica che l’impostazione effettiva della posizione dei contenuti e il montaggio dall’host al container siano stati modificati insieme. Uno spostamento moderno dei contenuti gestiti non dovrebbe essere diagnosticato come la ridenominazione del percorso di importazione di una libreria esterna.
La mappa dello stato persistente di Immich di ZimaSpace è utile in questo caso, perché database e percorsi del filesystem costituiscono un unico confine di ripristino. Non basta che sull’host siano presenti i file corretti se il container è montato in un’altra posizione.
Se la radice dei contenuti gestiti non corrisponde, correggi prima l’ambiente e la mappatura dei volumi, quindi riavvia il servizio prima di eseguire operazioni sulla libreria. Se il percorso modificato appartiene a una libreria esterna, mantieni intatto il database e verifica separatamente questo scenario.
Mantenere stabile, quando possibile, il percorso della libreria esterna visibile al container
Per una libreria esterna, lo spostamento dell’archiviazione sull’host è più sicuro quando il percorso di importazione visibile al container può rimanere invariato. Se cambia il percorso presentato a Immich, annota un piccolo insieme di ID delle risorse, album, persone e vecchi percorsi prima di una scansione, così potrai capire se le risorse esistenti sono state ricollegate o ricreate.
Una segnalazione sulla modifica del percorso di una libreria esterna di Immich descrive file spostati trattati come nuove risorse, con rielaborazione e perdita delle relazioni esclusive di Immich. È un caso legato a una specifica versione, ma conferma la regola prudente secondo cui un percorso modificato di una libreria esterna non equivale automaticamente a una ridenominazione trasparente.
Se un sottoinsieme di prova appare come nuove risorse mentre i vecchi record diventano mancanti o cestinati, interrompi la scansione completa. Ripristina il vecchio percorso visibile al container, se pratico, oppure usa un approccio di migrazione compatibile con la versione; non riscrivere manualmente i percorsi nel database di produzione senza un backup verificato.
Non confondere questo scenario con una migrazione del modello di archiviazione per i file gestiti da Immich. Il sintomo può sembrare simile nella cronologia, ma la proprietà dei file e il percorso di migrazione supportato sono diversi.
Separare i percorsi memorizzati sul server dalla cache del client
Controlla la stessa risorsa nota dal client web e da un altro client autenticato, quindi confronta i risultati con i log del server o con il percorso visibile al server. Se le attività lato server indicano ancora il vecchio percorso, cancellare la cache del browser non può correggere il record sottostante.
Un successivo problema relativo ai metadati del vecchio percorso di Immich ha mostrato che l’elaborazione continuava a fare riferimento a un precedente percorso della libreria esterna dopo una ridenominazione. È una prova concreta della necessità di controllare i percorsi usati dalle attività prima di attribuire la colpa all’interfaccia mobile o web.
Se il percorso sul server è corretto ma una sola vista web è obsoleta, aggiorna la pagina o cancella la cache di quel client, quindi verifica nuovamente il file originale. Le miniature memorizzate nella cache e lo stato obsoleto del client possono far sembrare difettoso un server corretto, mentre un’anteprima memorizzata nella cache può anche far apparire funzionante un percorso del server non corretto.
Correggere il confine di percorso più piccolo e convalidare una scansione controllata
Apporta una sola correzione reversibile: sincronizza l’impostazione dei contenuti gestiti con il montaggio, ripristina il precedente percorso della libreria esterna visibile al container, correggi un percorso di importazione oppure cancella la cache di un singolo client. Esegui un backup del database prima di qualsiasi operazione che possa causare la nuova individuazione di una libreria di grandi dimensioni.
Esegui la scansione più piccola possibile e verifica se i record esistenti rimangono associati, se gli errori relativi al vecchio percorso cessano e se non compaiono risorse duplicate vecchie e nuove. Quindi apri alcuni originali campione, verifica le relazioni con album e persone, esegui una ricerca e riavvia lo stack.
Procedi con un’escalation se i record dei percorsi vecchi e nuovi rimangono attivi contemporaneamente, se una libreria esterna di grandi dimensioni viene rielaborata inaspettatamente oppure se le relazioni scompaiono mentre gli originali restano leggibili. Conserva la mappa esatta dei montaggi prima e dopo, la versione di Immich, gli ID delle risorse interessate, il comportamento del filesystem rispetto alle maiuscole e minuscole e il timestamp del backup del database.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...
Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...
Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...
