È meglio eseguire il backup di Immich Live o arrestare prima il servizio?
Arresta prima Immich quando vuoi il limite di coerenza più semplice e facile da spiegare; usa un backup a caldo solo quando puoi eseguire un dump nativo del database e coordinare l’acquisizione o lo snapshot dei file multimediali, in modo da conoscere la loro relazione al ripristino.
Immich memorizza i record degli elementi in PostgreSQL, mentre gli originali e i file derivati risiedono nello spazio di archiviazione; perciò una normale copia ricorsiva a caldo può acquisire momenti diversi. Per una piccola famiglia, una breve finestra di manutenzione è spesso più sicura di un’orchestrazione complessa. Quando i caricamenti continui sono importanti, mantieni il servizio attivo, ma usa strumenti consapevoli del database, registra l’ordine di acquisizione, proteggi gli elementi appena arrivati e valuta il backup tramite un ripristino isolato.
Definisci ogni componente che il ripristino deve ricreare
Fai l’inventario del database PostgreSQL, della libreria dei caricamenti, dei file multimediali generati necessari secondo la tua policy, delle definizioni delle librerie esterne, dei file Compose e dell’ambiente, dei segreti, delle impostazioni del proxy e delle chiavi di crittografia. Classifica quali elementi sono gestiti da Immich e quali possono essere rigenerati.
Un articolo pratico sul backup del database spiega come usare un dump PostgreSQL invece di trattare la directory del database attivo come normali file. Il suo metodo di backup consapevole del database supporta lo scenario a caldo; verifica comandi e versioni per la tua distribuzione.
Un piano fallisce se protegge gli originali ma non può ripristinare i relativi record, oppure se protegge il database omettendo i file multimediali. Scrivi l’ordine di ripristino accanto all’ordine di backup prima di decidere se il tempo di inattività è accettabile.
Scegli un backup a freddo per il limite più chiaro
Metti in pausa i caricamenti, arresta correttamente l’applicazione e i worker di Immich, quindi esegui un backup nativo del database e copia o acquisisci uno snapshot dei file multimediali e dei file di distribuzione. Mantieni PostgreSQL in esecuzione solo se necessario per il dump, oppure arrestalo correttamente prima di uno snapshot a livello di archiviazione progettato per quel servizio.
Un servizio arrestato non corregge percorsi errati o un ambito incompleto, quindi verifica i mount e le dimensioni degli archivi. Un’esecuzione corretta non presenta scritture attive di Immich durante l’acquisizione, include un backup del database riuscito, campioni di file multimediali leggibili, checksum e un orario di riavvio documentato.
La guida di ZimaSpace su verifica delle chiavi e dei ripristini dei backup ribadisce che una copia eseguita a sistema inattivo non è recuperabile finché le credenziali e il percorso di ripristino non vengono testati.
Usa un backup a caldo coordinato quando è necessaria la disponibilità
Per un piano a caldo, crea un dump coerente nativo del database e abbinalo a uno snapshot dello spazio di archiviazione o a un’acquisizione di file di cui siano noti tempi e comportamento di scrittura. Registra gli orari di inizio e completamento, conserva i nuovi caricamenti fino al backup successivo ed evita di copiare la directory del database attivo.
Una discussione della community sul backup di Immich da una distribuzione in esecuzione mostra perché gli operatori distinguono il database dai file caricati. Usa quel limite del backup a caldo come contesto pratico, non come sostituto di un test di ripristino.
Una progettazione a caldo è valida solo se lo strumento del database completa correttamente l’operazione, l’acquisizione del filesystem è atomica oppure il suo ordinamento è documentato, e i caricamenti creati durante la finestra sono considerati. In caso contrario, scegli il percorso a freddo o aumenta la frequenza dei backup per ridurre la finestra di manutenzione.
Ripristina in isolamento e fai la scelta finale
Ripristina il database e i file multimediali selezionati su una destinazione isolata usando i file di distribuzione salvati. Controlla gli utenti, il numero di elementi, alcuni originali campione, gli album, i preferiti, le ricerche, le librerie esterne e un nuovo caricamento. Riavvia la destinazione e ripeti i controlli critici.
Scegli i backup a freddo quando il loro tempo di inattività è compatibile con le esigenze della famiglia e la semplicità riduce gli errori. Scegli i backup a caldo coordinati quando la disponibilità giustifica strumenti aggiuntivi e test di ripristino ripetuti dimostrano che il processo funziona. La decisione può cambiare con l’aumento delle dimensioni della libreria e della frequenza dei caricamenti.
Interrompi il dismissionamento della produzione se il ripristino presenta errori di file mancanti o record orfani. Conserva entrambi i componenti del backup e i log, quindi confronta i timestamp e l’ambito. In caso di escalation, includi la versione del database, il metodo di dump, il metodo del filesystem, gli orari di acquisizione e il numero di discrepanze; non eliminare mai l’ultimo backup a freddo finché il metodo a caldo non ha superato una verifica indipendente.
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...
