Come ripristinare un database Immich da un backup integro noto
Un backup noto e valido del database di Immich è utile solo se lo ripristini in uno stato controllato e dimostri che il database recuperato continua a puntare ai contenuti multimediali che il server riesce effettivamente a vedere.
Considera il ripristino come una sequenza, non come un singolo comando di importazione. Conserva prima l’istanza danneggiata, identifica la versione di Immich e la data e ora del backup, avvia un database di destinazione pulito e compatibile, esegui il ripristino senza lasciare che l’applicazione scriva prima in uno schema vuoto, quindi convalida gli account, i dati della cronologia, i percorsi dei contenuti multimediali e una nuova scrittura. Se un passaggio non è chiaro, fermati prima di sostituire l’ultima copia recuperabile.
Blocca lo stato danneggiato prima di ripristinare qualsiasi elemento
Interrompi i nuovi caricamenti e le scritture in background sull’istanza di Immich interessata prima di iniziare il ripristino. Salva il file Compose attuale, i valori dell’ambiente, i percorsi montati, le versioni delle immagini, i log recenti e lo stato del database danneggiato, se lo spazio di archiviazione lo consente. Un database danneggiato può ancora contenere informazioni utili a spiegare cosa è successo e sovrascriverlo elimina tali informazioni.
Identifica esattamente quale backup intendi considerare attendibile. Registra la data e l’ora, il metodo di creazione, la dimensione del file e se sia mai stato ripristinato come test. Un dump SQL prodotto dal database è un risorsa di ripristino diversa da una copia grezza della directory dei dati PostgreSQL in uso; non trattarli come intercambiabili.
Crea la destinazione di ripristino in una directory separata o in uno stack isolato, quando possibile. La condizione di uscita da questa fase è semplice: lo stato originale danneggiato è conservato, il backup scelto è di sola lettura e sai a quale versione della distribuzione e a quali percorsi di archiviazione il ripristino deve ricollegarsi.
Verifica che il backup sia effettivamente ripristinabile
Controlla il backup prima di rieseguirlo. Un dump SQL compresso dovrebbe essere decompresso correttamente e contenere dati riconoscibili di un dump PostgreSQL, anziché essere un archivio vuoto prodotto da una pipeline non riuscita. Se disponi di checksum o risultati di verifica del repository, confrontali ora invece di scoprire la corruzione nel mezzo del ripristino.
Un dump PostgreSQL è una risorsa di ripristino più sicura di una copia occasionale di una directory del database in uso, perché viene creato tramite strumenti consapevoli del database e può essere rieseguito in una destinazione pulita. Anche il metodo di backup basato sul dump del database mantiene separati il database e la copia dei contenuti multimediali, facilitando la convalida di entrambe le parti prima del ripristino.
Verifica inoltre che i contenuti multimediali e la configurazione relativi alla finestra temporale del backup esistano ancora. Il solo ripristino del database può recuperare utenti, album, metadati e riferimenti ai file, lasciando però ogni elemento non accessibile se i percorsi della libreria a cui fanno riferimento sono mancanti. Procedi solo quando il dump e l’insieme di contenuti multimediali e configurazione appartengono a un punto di ripristino noto.
Avvia prima una destinazione di database pulita e compatibile
Adatta il metodo di ripristino alla versione che ha creato il backup. Le versioni attuali di Immich offrono il ripristino del database tramite Amministrazione > Manutenzione e tramite il flusso di configurazione iniziale di una nuova installazione, mentre i backup più vecchi possono richiedere istruzioni manuali specifiche per la versione; il flusso di ripristino è cambiato nella versione v2.5.0.
Per una nuova destinazione di ripristino, non lasciare che Immich esegua le migrazioni normali su uno schema vuoto prima che il ripristino del database sia pronto. Se il metodo di distribuzione avvia l’applicazione insieme a PostgreSQL, utilizza i controlli di ripristino appropriati per la versione, così il server non creerà uno stato concorrente prima dell’importazione.
Se il database non diventa autonomamente operativo, fermati e risolvi prima il problema. Non continuare a rieseguire lo stesso backup in una destinazione che si riavvia, ha esaurito lo spazio su disco o utilizza una struttura di archiviazione incompatibile. Una destinazione pulita e stabile è un prerequisito, non una digressione sulla risoluzione dei problemi.
Ripristina il dump una sola volta e fermati al primo errore
Ripristina il dump scelto nel database preparato e acquisisci l’output completo. Utilizza gli strumenti del database e i parametri appropriati al formato del dump, così un errore farà fallire il ripristino in modo evidente invece di lasciare uno schema importato parzialmente che continua comunque ad avviarsi.
Un insieme di migrazione utilizzabile deve includere i contenuti, lo stato PostgreSQL e la configurazione che li ricollega. Un insieme completo di backup di Immich comprende i contenuti caricati, un backup del database supportato e la configurazione della distribuzione; i test di ripristino servono a dimostrare che l’insieme funziona. Mantieni unite queste parti, così la destinazione può essere associata a un unico punto di ripristino.
Dopo un’importazione riuscita, avvia l’applicazione Immich e osserva attentamente il primo avvio. Se l’interfaccia ti chiede di creare un nuovo amministratore principale invece di accettare gli account esistenti, fermati: ciò indica fortemente che il database ripristinato non è quello utilizzato da Immich. Non iniziare a ricaricare le foto in quello stato vuoto.
Convalida lo stato del database, i percorsi dei contenuti multimediali e una nuova scrittura
Accedi con un account esistente e controlla la cronologia in diverse date, tra cui date meno recenti e recenti. Apri diversi originali, esamina album o preferiti che sai essere esistiti e conferma che l’applicazione riesca a risolvere i file sottostanti, anziché visualizzare soltanto le righe del database.
Lo stato del database, i file dell’applicazione, la configurazione e i caricamenti devono essere coerenti al momento del ripristino. Usa un backup coerente del contenitore del database come modello di accettazione, non il semplice fatto che PostgreSQL si avvii.
Infine carica una foto non importante, attendi l’elaborazione normale, verifica che sopravviva a un riavvio di Immich e a un riavvio dell’host, quindi eliminala tramite l’applicazione. Se gli account, i contenuti esistenti e la nuova scrittura funzionano normalmente, crea un nuovo backup dello stato recuperato prima di qualsiasi aggiornamento di versione. In caso contrario, torna alle prove conservate del guasto o a un backup precedente noto e valido, invece di aggravare il danno.
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...
