Come evitare che i backup di Immich acquisiscano uno stato incoerente
Previeni backup incoerenti di Immich trattando il database e i contenuti multimediali come un’unica unità di ripristino, il cui ordine di acquisizione e la cui attività di scrittura sono controllati deliberatamente.
Un backup può contenere ogni file che gli è stato chiesto di copiare e tuttavia ripristinarsi male se il database fa riferimento ad asset che non sono stati acquisiti oppure se la copia dei contenuti multimediali rappresenta un momento diverso da quello del catalogo. Definisci prima il confine di coerenza, scegli un metodo con servizio arrestato o coordinato durante l’esecuzione e convalida il risultato in isolamento.
Definisci l’unità di ripristino prima di pianificare il backup
Elenca il database PostgreSQL, i contenuti multimediali caricati, i dati del profilo, la configurazione della distribuzione, i valori dell’ambiente, i segreti e tutti i percorsi di archiviazione personalizzati necessari per ricreare il servizio. Indica separatamente le miniature generate, i video codificati e i file dei modelli, specificando se la tua policy di ripristino li protegge o li rigenera.
Il confronto di ZimaSpace tra backup di Immich mentre è attivo o arrestato illustra la scelta di base relativa alla coerenza. Questo flusso di prevenzione fa un passo ulteriore: qualunque metodo tu scelga deve produrre un punto documentato che possa essere ripristinato senza dover indovinare quale database corrisponda a quale copia dei contenuti multimediali.
Scrivi l’ordine di ripristino accanto all’ambito del backup. Se il piano dice “ripristinare le foto” ma non specifica quale dump del database, configurazione, credenziali e mappature di archiviazione ricolleghino quelle foto agli utenti e agli album, la definizione del backup è incompleta ancor prima dell’inizio della prima esecuzione pianificata.
Usa un’acquisizione con servizio arrestato quando è accettabile un confine più semplice
Per una famiglia che può tollerare una breve finestra di manutenzione, metti in pausa i caricamenti e arresta i servizi applicativi che scrivono lo stato della libreria. Crea il backup del database, acquisisci i contenuti multimediali e la configurazione, quindi riavvia solo dopo che lo snapshot o la copia presentano un timestamp chiaro e un risultato di completamento.
Un’applicazione arrestata non rende automaticamente corretto un percorso errato. Verifica che l’esportazione del database sia riuscita, che siano incluse le radici dei contenuti multimediali previste e che la destinazione del backup sia indipendente dai dati attivi che deve consentire di recuperare. Registra gli orari di inizio e fine, così i ripristini successivi potranno identificare la generazione esatta.
Il metodo è valido quando durante l’acquisizione non vengono eseguite scritture da parte dell’applicazione e un ripristino di prova restituisce gli utenti, il numero previsto di asset, gli album e gli originali campionati. Se il downtime supera regolarmente la soglia tollerata dalla famiglia, passa a un metodo live coordinato invece di lasciare semplicemente che i caricamenti riprendano a metà della copia di un file.
Per i backup live, acquisisci database e file in un ordine noto
Quando Immich deve rimanere disponibile, crea un dump coerente nativo del database invece di copiare la directory dati PostgreSQL attiva come normali file. Quindi acquisisci o crea uno snapshot dell’albero dei contenuti multimediali nell’ordine documentato, tenendo traccia dei caricamenti che arrivano durante la finestra del backup.
Il pratico flusso di backup del database di Immich mostra l’approccio basato sulla conoscenza del database. I comandi e i nomi dei container possono variare in base alla distribuzione, quindi il principio trasferibile consiste nel chiedere a PostgreSQL di creare un backup coerente invece di affidarsi a una copia ricorsiva live dei file del database.
Preferisci un ordine che non possa lasciare il database ripristinato a fare riferimento a contenuti multimediali mai entrati nel backup. Se la copia del file system contiene file aggiuntivi che il database non conosce ancora, questi possono essere riconciliati più facilmente rispetto ai record del database i cui originali referenziati sono assenti. Documenta tutti i caricamenti che attraversano il confine.
Coordina gli snapshot del file system con gli hook del database invece di presumere l’atomicità
Gli snapshot del file system sono preziosi perché acquisiscono rapidamente un volume, ma da soli non rendono transazionalmente coerenti due sistemi che cambiano in modo indipendente. Se database e contenuti multimediali risiedono su dataset o dispositivi diversi, definisci hook pre-snapshot e post-snapshot e rendi visibili i relativi tempi nel registro del backup.
Un esempio del 2026 che combina un software di backup con hook per snapshot Btrfs mostra perché l’orchestrazione degli snapshot richieda confini espliciti a livello di applicazione o database. Usa questa idea per coordinare le acquisizioni; non copiare ciecamente i relativi comandi del file system su una struttura diversa.
Se lo strumento per gli snapshot non è in grado di coordinare il confine temporale tra database e contenuti multimediali, torna a un dump logico del database più un backup dei contenuti multimediali invece di dichiarare di disporre di un ripristino atomico. La complessità è giustificata solo quando la prova di ripristino dimostra che l’acquisizione più rapida restituisce comunque uno stato coerente dell’applicazione.
Rendi i test di ripristino parte della pianificazione del backup
Un processo di backup completato con successo dimostra soltanto che l’acquisizione è terminata. Seleziona periodicamente una generazione recente, ripristinala sotto un hostname isolato, collega lo storage previsto e verifica utenti, originali rappresentativi, album, autorizzazioni, comportamento della ricerca e un nuovo backup del database dall’istanza ripristinata.
La panoramica sul ripristino di PostgreSQL dedicata alla pianificazione del backup e del ripristino enfatizza la convalida del ripristino e gli obiettivi di recupero, invece di considerare la creazione del dump come il traguardo finale. Applica la stessa disciplina all’unità di ripristino combinata di Immich.
Considera fallita la policy di backup se il ripristino del database riesce ma mancano file, se i contenuti multimediali si aprono senza utenti o relazioni oppure se il recupero dipende da un segreto memorizzato solo sull’host guasto. Correggi ambito, ordine, conservazione o indipendenza prima di aumentare la frequenza dei backup; più copie incoerenti non creano un punto di ripristino affidabile.
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...
