Come eseguire il rollback di Immich in sicurezza dopo una release incompatibile
Esegui il rollback di Immich solo dopo aver preservato lo stato attuale e aver determinato se la versione più recente ha modificato il database o la configurazione in modo che l’immagine precedente non possa leggerli.
L’immagine di un container può essere sostituita, ma i dati persistenti potrebbero essere già stati migrati. Se un aggiornamento inizia con problemi, interrompi gli aggiornamenti automatici e le nuove scritture, annota entrambe le versioni, proteggi il database e i contenuti multimediali correnti, quindi scegli tra un semplice rollback dell’immagine e il ripristino del punto di recupero precedente all’aggiornamento.
Blocca l’aggiornamento non riuscito prima che modifichi altri dati
Disabilita gli aggiornamenti automatici delle immagini e impedisci ai client di aggiungere nuove foto mentre raccogli le informazioni. Annota le versioni o i digest esatti delle immagini Immich precedente e nuova, la versione di PostgreSQL, i file Compose e dell’ambiente, i percorsi dei mount e il primo errore di avvio o migrazione.
La guida di ZimaSpace sui limiti del rollback dei container evidenzia la distinzione fondamentale: i volumi persistenti sopravvivono alla sostituzione dell’immagine, ma ciò è sicuro solo quando l’applicazione precedente rimane compatibile con lo stato in essi contenuto.
Esegui un backup nativo del database nello stato attuale non riuscito, se il database è leggibile, e conserva separatamente il backup precedente all’aggiornamento. Non sovrascrivere nessuno dei due con esperimenti ripetuti. La copia attuale potrebbe servire per procedere in seguito, anche se l’obiettivo immediato è tornare alla versione precedente.
Determina se la versione ha superato un limite di migrazione del database
Esamina il primo errore dopo l’aggiornamento e determina se si verifica prima o durante la migrazione del database, dopo la migrazione durante l’avvio dell’applicazione oppure solo durante un flusso di lavoro dell’utente. Questa tempistica modifica il piano di rollback, perché un’immagine precedente potrebbe non comprendere uno schema già modificato dalla nuova versione.
Un recente resoconto di Immich in cui il servizio non è riuscito ad avviarsi dopo un percorso di aggiornamento mostra perché percorsi di migrazione non supportati o saltati possano rendere inaffidabile una semplice sostituzione della versione. Considera la discussione un caso di studio e verifica la sequenza di migrazione esatta per le tue versioni.
Se la nuova applicazione non ha mai modificato il database e il problema è limitato alla compatibilità dell’immagine o dell’ambiente di esecuzione, può bastare il rollback a un’immagine fissata. Se le migrazioni sono state completate, considera il backup del database precedente all’aggiornamento il partner più sicuro per la versione precedente, salvo prove esplicite di compatibilità.
Ripristina un database e un ambiente di esecuzione compatibili invece di mescolare versioni diverse
Costruisci il target del rollback partendo dall’ultima versione dell’applicazione sicuramente funzionante, dalla relativa configurazione di distribuzione compatibile e dal punto di recupero del database precedente alla modifica incompatibile. Mantieni intatto l’albero dei contenuti multimediali, salvo che la versione abbia modificato i file in modo documentato; non ricopiare terabyte di dati solo perché è cambiata l’immagine dell’applicazione.
La discussione sul rollback del database compatibile spiega il pericolo generale di distribuire codice precedente su uno schema che non comprende più. Questo principio è più importante del fatto che il container riesca o meno ad avviarsi.
Avvia l’istanza di rollback in isolamento, in modo che i client mobili e i processi pianificati non possano scrivere fino al completamento della convalida. Se la versione precedente segnala immediatamente errori dello schema, arrestala. Non forzare manualmente il rollback delle migrazioni sull’unica copia del database, a meno che tu non disponga di una procedura di ripristino specifica per la versione e già testata.
Fissa l’immagine esatta sicuramente funzionante e riproduci la relativa configurazione
Usa una versione specifica o un riferimento immutabile all’immagine, invece di un tag soggetto a variazioni. Ripristina l’ambiente, le dipendenze dei servizi, le mappature dei dispositivi, le reti, le porte e la destinazione del reverse proxy corrispondenti alla distribuzione sicuramente funzionante. Un rollback che modifica silenziosamente diversi livelli dell’infrastruttura crea un secondo incidente.
Conserva la nuova immagine e la configurazione non riuscite accanto alle note sul rollback. Ciò consente un ripristino controllato in avanti dopo aver compreso l’incompatibilità. Rimuovere immediatamente ogni nuovo artefatto può rendere più difficile confrontare gli stati non riuscito e funzionante o riprodurre l’aggiornamento in un ambiente di test.
Se il servizio precedente si avvia sullo stato ripristinato, esamina i log prima di riabilitare i client. Verifica che non ci siano tentativi di migrazione imprevisti, inizializzazione di una nuova installazione, mount dello storage mancanti o modifiche ai permessi. Una semplice pagina di accesso non dimostra che il rollback stia utilizzando i dati previsti.
Convalida la versione precedente usando il trigger originale e mantieni un percorso per procedere
Prova utenti rappresentativi, contenuti vecchi e recenti, album, condivisione, ricerca, un nuovo caricamento controllato, processi in background, la creazione di un backup del database e il percorso del reverse proxy. Riavvia lo stack una volta e verifica che gli stessi mount e il database tornino disponibili senza interventi manuali.
Mantieni sospesi i nuovi caricamenti fino al superamento di questi controlli, quindi riapri l’accesso e osserva il normale intervallo di attività. Conserva sia il backup precedente all’aggiornamento sia il backup dello stato più recente non riuscito, così potrai riprovare l’aggiornamento in seguito in una copia isolata, dopo aver compreso il problema di compatibilità.
Il rollback non è riuscito se la versione precedente segnala un’incompatibilità dello schema, mancano dati noti oppure le scritture finiscono in un percorso imprevisto. Arresta tutto e ripristina nuovamente il punto di recupero conservato, invece di stratificare correzioni. Per l’escalation, fornisci le versioni esatte, i log di migrazione, i timestamp dei backup del database, il confronto dei file Compose e il primo passaggio di verifica che non va a buon fine.
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...
