Come evitare la perdita della configurazione di Immich durante gli aggiornamenti

Eva Wong

IceWhale author

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.

How to Prevent Immich Configuration Loss During Upgrades - Zima Store Online

Previeni la perdita della configurazione di Immich durante gli aggiornamenti trattando il file Compose, i valori dell’ambiente, il database, la libreria degli upload e le definizioni dei mount delle librerie esterne come risorse persistenti separate, che devono essere acquisite e ripristinate insieme.

Un container è sostituibile; la configurazione che lo circonda no. Un aggiornamento può dare l’impressione di cancellare Immich quando un bind mount relativo viene risolto da una directory di progetto diversa, una modifica all’ambiente non raggiunge mai il container ricreato oppure il nuovo stack viene avviato con un database vuoto. Prima fai l’inventario della distribuzione attiva, conserva copie versionate fuori dall’host e verifica una ricreazione controllata prima del passaggio in produzione.

Acquisisci la distribuzione attiva prima di ogni aggiornamento

Esporta la configurazione Compose effettiva con i segreti oscurati, annota le versioni o i digest delle immagini e copia i file Compose e dell’ambiente in uno spazio di archiviazione versionato. Ispeziona i mount in esecuzione invece di presumere che il file aperto nell’editor abbia avviato i container attuali. Il controllo è superato quando ogni percorso runtime corrisponde a una posizione host nota.

Registra i percorsi delle librerie esterne, le impostazioni del reverse proxy, l’URL del machine learning, i valori di connessione al database, l’identità dell’utente e del gruppo, i nomi delle reti e gli eventuali dispositivi per l’accelerazione hardware. Un elemento mancante qui diventerà in seguito una differenza post-aggiornamento inspiegabile.

Le domande della community sugli aggiornamenti mostrano ripetutamente operatori che perdono traccia della generazione Compose o della struttura dell’ambiente applicabile. L’insegnamento utile di una discussione sulla configurazione dell’aggiornamento è conservare la definizione attualmente funzionante prima di tradurla.

Esegui separatamente il backup del database, dei contenuti multimediali e dei file di distribuzione

Esegui un backup nativo del database e un backup del filesystem o uno snapshot della libreria degli upload e della directory di distribuzione. Registra gli orari di inizio e completamento, le dimensioni degli archivi e i checksum. Un backup che contiene solo YAML Compose può ricostruire i container, ma non può ripristinare account, metadati, album o record degli elementi.

Usa un backup a servizi arrestati per ottenere il confine di coerenza più semplice, oppure coordina un dump del database in esecuzione e uno snapshot dello storage, documentandone la relazione. Mantieni le librerie esterne nell’inventario anche se Immich non gestisce gli originali, perché i percorsi e le regole di accesso influenzano comunque il servizio ripristinato.

Una procedura per l’aggiornamento a una versione principale mantenuta dalla community sottolinea l’importanza di preservare database, contenuti multimediali, Compose e input dell’ambiente. Considera la sequenza come esperienza degli operatori e verifica ogni passaggio rispetto alla release che distribuisci effettivamente.

Prepara l’aggiornamento con versioni bloccate

Leggi le note di rilascio per ogni versione saltata e aggiorna deliberatamente la definizione di distribuzione salvata. Blocca la release di destinazione, scaricala senza rimuovere le immagini precedenti e convalida la configurazione Compose renderizzata. Variabili sconosciute, mount vuoti o versioni miste dei servizi fanno fallire il controllo di staging.

Se la capacità lo consente, ripristina il backup in uno stack di test isolato, con porte diverse e senza accesso in scrittura alla produzione. Avvialo sulla versione di destinazione e controlla migrazioni, utenti, percorsi di archiviazione e processi in background. Il solo avvio riuscito del container non dimostra che la libreria originale sia collegata.

La guida correlata di ZimaSpace a un NAS self-hosted sicuro aiuta a collocare file di distribuzione e backup al di fuori del singolo host e del confine delle credenziali che un aggiornamento può compromettere.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Dimostra la persistenza della configurazione dopo la ricreazione

Prima del passaggio, ricrea i container di test dai file salvati invece di riavviarli sul posto. Verifica utenti, impostazioni del server, modelli di archiviazione, librerie, processi, accesso tramite proxy e valori effettivi dell’ambiente. Il controllo è superato quando la configurazione sopravvive alla sostituzione perché risiede in componenti persistenti documentati.

Dopo il passaggio in produzione, carica un elemento di test, esegui una ricerca, apri un originale ed esegui un nuovo backup del database. Riavvia lo stack e l’host, quindi ripeti le verifiche. Conserva la versione precedente, il backup e la definizione di distribuzione finché il normale carico di lavoro non rimane stabile per tutta la finestra di osservazione.

Se l’aggiornamento è già stato avviato con uno stato vuoto, arrestalo prima che l’onboarding o nuovi upload creino uno stato in conflitto. Ricollega solo un percorso persistente verificato oppure ripristina in una destinazione pulita. Esegui il rollback quando mancano gli utenti o gli elementi attesi; se l’identità rimane ambigua, chiedi supporto fornendo la configurazione Compose effettiva sanificata, i mount, le versioni e gli orari dei backup.