Perché Immich perde l’accesso ai dati persistenti dopo la ricreazione dello stack?

Quando Immich appare vuoto o non riesce a leggere la propria libreria dopo la ricreazione dello stack, presupponi che i vecchi dati persistenti siano scollegati o illeggibili prima di supporre che siano stati eliminati.

La ricreazione dei container può modificare l’identità del progetto Compose, l’origine di un bind mount, l’associazione di un volume denominato, i tempi di disponibilità di una condivisione di rete o l’UID/GID utilizzato per leggere i dati. Arresta l’istanza appena ricreata prima che scriva molti nuovi dati, individua sull’host i vecchi percorsi del database e dei file multimediali e confronta lo stack ricreato con l’ultima configurazione sicuramente funzionante. L’obiettivo è prima ricollegare lo stato esistente; ripristina da un backup solo dopo aver dimostrato che quello stato è effettivamente mancante o danneggiato.

Arresta l’istanza appena creata e dimostra che i vecchi dati esistono ancora

Una procedura guidata di configurazione, una timeline vuota o una libreria esterna mancante subito dopo la ricreazione sono segnali di un problema di persistenza. Arresta Immich e controlla sull’host i percorsi del database e dei file multimediali prima di caricare nuovi file o accettare una nuova configurazione vuota. Le nuove scritture possono rendere più difficili i confronti successivi dei percorsi.

Controlla nelle vecchie directory il numero previsto di file, le date di modifica, i file del database o i dump e alcune immagini originali rappresentative. Se i dati sono presenti sull’host, il problema riguarda l’accesso o la mappatura, non la scomparsa dei dati. Crea uno snapshot o un backup in sola lettura di quello stato prima di modificare la proprietà o spostare le directory.

Se non riesci a trovare i vecchi dati nei percorsi previsti, cerca nel pool di archiviazione e nell’inventario dei volumi Docker prima di eliminare qualsiasi cosa. La decisione è binaria: lo stato esistente è stato individuato e protetto, oppure è realmente indisponibile e il percorso di ripristino passa a un backup sicuramente valido invece che alla riparazione dei mount.

Confronta i mount ricreati con quelli dello stack precedente

Controlla i mount effettivi nei container del server e del database di Immich ricreati, non solo il testo Compose che ricordi di aver modificato. Un percorso bind relativo può essere risolto a partire da una directory di progetto diversa e un progetto Compose rinominato può collegare un nuovo volume denominato, lasciando intatto ma inutilizzato quello precedente.

Un mount non riuscito, modificato o mancante può mostrare all’interno di un container una directory vuota anche quando i dati previsti esistono ancora altrove sull’host. Usa i controlli dei mount dei volumi Docker per confrontare Source, Destination, tipo di mount e identità del volume denominato per ogni percorso persistente di Immich. Una differenza qui spiega direttamente l’aspetto di un’istanza appena inizializzata.

Correggi solo la mappatura del mount errata, quindi crea o avvia il container senza rimuovere i volumi. Se i file previsti compaiono nello stesso percorso del container dopo la modifica, lascia i dati dove si trovano. Se l’elenco dei mount è corretto ma l’accesso continua a non funzionare, mantieni la mappatura e passa a verificare la disponibilità dello spazio di archiviazione dell’host e i permessi, invece di creare un altro volume.

Verifica che lo spazio di archiviazione esterno fosse montato prima dell’avvio di Immich

Se i dati di Immich risiedono in un pool HDD, una condivisione NAS, un livello di fusione o un altro mount esterno, conferma che tale spazio sia effettivamente montato sull’host prima che Docker avvii lo stack. Un percorso come /mnt/photos può continuare a esistere come normale directory locale anche quando il dispositivo reale è assente.

I dati Docker persistenti sopravvivono alla sostituzione dei container solo quando il volume o il bind mount previsto viene ricollegato correttamente. Il modello di persistenza dei volumi Docker sottostante non fa comparire automaticamente un disco host o una condivisione di rete mancanti; verifica quindi il dispositivo di archiviazione e un file noto sull’host prima di testare lo stesso percorso all’interno di Immich.

Se scopri che sono stati scritti file di ripiego nel punto di mount vuoto mentre lo spazio di archiviazione reale era assente, arresta Immich prima di montare il dispositivo sopra di essi. Gestisci separatamente quei file, aggiungi una dipendenza di avvio o un controllo di integrità per il mount dello spazio di archiviazione e solo dopo riavvia lo stack. Se lo spazio di archiviazione dell’host è stabile e il percorso del container è ancora illeggibile, passa al ramo dei permessi.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controlla UID, GID e permessi delle directory senza riscrivere tutto

Uno stack ricreato può eseguire un servizio con un’identità numerica, uno spazio dei nomi utente o un contesto di sicurezza diverso da quello precedente. Il risultato appare diverso da un mount mancante: il percorso esiste e i file sono visibili dall’host, ma i log di Immich mostrano errori di permesso o l’applicazione non riesce a creare i file previsti.

Confronta la proprietà numerica e i bit dei permessi nelle directory interessate dell’host con l’identità utente all’interno del container ricreato. Esegui prima una lettura innocua, quindi una scrittura reversibile in una posizione temporanea sotto lo stesso mount. Evita di modificare ricorsivamente la proprietà dell’intero archivio fotografico finché non sai quale servizio necessita dell’accesso in scrittura e quali file originali devono rimanere intatti.

Correggi la minima differenza tra directory e identità che spiega il problema, riavvia una sola volta e ricontrolla i log. Se l’accesso continua a non funzionare con mount e permessi corrispondenti, interrompi le modifiche al filesystem e controlla la connessione al database, la sostituzione delle variabili d’ambiente o il livello di sicurezza modificato durante la ricreazione.

Ricollega lo stato originale e convalida un’altra ricreazione

Quando i vecchi percorsi del database e dei file multimediali sono collegati e leggibili, avvia Immich e verifica la presenza dei vecchi utenti, album, persone e risorse rappresentative. Non considerare completata la riparazione solo perché la home page viene caricata; verifica che l’applicazione stia leggendo lo stato originale e non un database appena inizializzato accanto a quello precedente.

Il principio utile è che i container possono essere usa e getta, mentre lo stato dell’applicazione deve rimanere su uno spazio di archiviazione stabile, esterno al ciclo di vita dei container. Documenta i nomi dei mount e i percorsi dell’host corretti e usa i ruoli di archiviazione persistente del file server per mantenere il prossimo stack ricreato collegato agli stessi dati.

Infine, ricrea ancora una volta lo stack in condizioni controllate e ripeti i controlli iniziali. La correzione è dimostrata solo se lo stesso database e gli stessi file multimediali ricompaiono dopo la ricreazione e dopo il riavvio dell’host. Se il vecchio stato scompare di nuovo o il database segnala una corruzione invece di errori di accesso, torna alla copia protetta e passa al ripristino del database o del backup invece di continuare a sperimentare con i mount.