Come spostare i dati di Immich senza perdere utenti, cronologia o impostazioni
Sposta Immich come migrazione dello stato dell’applicazione, non come semplice copia di una cartella: conserva il database, l’albero dei contenuti multimediali, la configurazione, i segreti e i percorsi che li collegano.
Una migrazione può sembrare riuscita perché ogni JPEG esiste sul nuovo disco, mentre account, album, persone, condivisioni, preferiti o relazioni storiche sono andati persi. Crea prima un punto di ripristino, acquisisci uno stato sorgente coerente, copialo senza modificare gli identificatori, ripristinalo su una destinazione isolata ed esegui il passaggio solo dopo aver verificato che i flussi di lavoro domestici corrispondano.
Fai l’inventario dello stato da trasferire insieme
Elenca il database PostgreSQL, i contenuti multimediali caricati, i dati generati che intendi conservare, le definizioni delle librerie esterne, la configurazione di Compose o dell’app, i valori dell’ambiente, i segreti, i nomi di rete e le mappature di archiviazione attuali. Indica quale elemento è autorevole e quale può essere rigenerato dopo il ripristino.
Una discussione del 2026 su come preservare gli utenti di Immich durante uno spostamento ribadisce il punto centrale: lo stato degli utenti e delle librerie è legato al database e ai percorsi montati, non all’immagine del container. Considera i comandi della community come esempi e adattali alla versione esatta distribuita.
Prima dello spostamento, prepara un piccolo insieme di verifica: due utenti, diversi album, preferiti, elementi condivisi, una persona o un risultato di ricerca, contenuti vecchi e recenti e un percorso di libreria esterna, se utilizzato. Questi record noti renderanno la convalida post-migrazione molto più solida del semplice confronto delle dimensioni totali dei file.
Crea un punto di ripristino coerente prima della copia
Sospendi i nuovi caricamenti o pianifica una finestra di manutenzione, in modo che la sorgente smetta di cambiare mentre acquisisci lo stato della migrazione. Esegui un backup nativo del database e proteggi i contenuti multimediali e la configurazione della sorgente. Dopo l’acquisizione, mantieni intatta l’istanza originale finché la destinazione non avrà superato la verifica.
La guida al ripristino di ZimaSpace su come ripristinare insieme i componenti di una libreria fotografica spiega perché gli originali, lo stato del catalogo e la configurazione che definisce i percorsi devono rappresentare un punto di ripristino compatibile. Questo è lo stesso confine necessario per una migrazione.
Non usare la directory del database di produzione attivo come destinazione per una normale copia di file mentre il database cambia. Se il downtime deve essere breve, utilizza un dump consapevole del database e un metodo di archiviazione di cui conosci l’ordine di acquisizione. Una migrazione è ripristinabile solo quanto il punto che puoi ripristinare, non in base al numero di file copiati.
Copia i contenuti multimediali mantenendo intatti percorsi e permessi
Copia l’albero dei contenuti multimediali nella destinazione senza riorganizzare le cartelle durante la migrazione. Mantieni proprietari, permessi, date e qualsiasi funzionalità del file system da cui dipende la tua distribuzione. Se il percorso visibile al container deve rimanere invariato, modifica la sorgente del bind sul sistema host mantenendo stabile la mappatura interna al container.
L’attuale flusso di lavoro di migrazione con rsync evidenzia la modalità archivio, le simulazioni, i trasferimenti riprendibili e i rischi delle opzioni di mirror distruttive. Esegui un confronto a secco prima di qualsiasi eliminazione e verifica la destinazione, invece di presumere che un comando completato equivalga a una migrazione completa dell’applicazione.
Confronta il numero e le dimensioni dei file, quindi verifica un campione rappresentativo di checksum tra foto vecchie, foto nuove, video e file di grandi dimensioni. Se compaiono errori di copia o file “scomparsi” perché la sorgente è cambiata, interrompi i caricamenti e ripeti il passaggio differenziale invece di eliminare la sorgente per ottenere una destinazione dall’aspetto pulito.
Ripristina database e configurazione su una destinazione isolata
Avvia la destinazione con un hostname temporaneo o su una rete isolata, così i client mobili non potranno caricarvi contenuti durante la convalida. Collega i contenuti multimediali copiati ai percorsi previsti nel container, ripristina il database corrispondente e ricrea l’ambiente, i segreti, le reti e le impostazioni proxy richieste da quella versione.
Un resoconto separato del 2026 sulla migrazione graduale di un server mostra perché gli operatori testano il nuovo host prima di dismettere quello vecchio. Usa questi resoconti per individuare possibili problemi, ma lascia che siano i tuoi record noti a stabilire se la migrazione ha davvero preservato lo stato.
Fermati se la destinazione si apre come una nuova installazione, segnala spazio di archiviazione mancante o propone un’inizializzazione distruttiva. Questi sintomi indicano di solito che il database o i mount non sono quelli previsti. Correggi prima il percorso o la destinazione del ripristino; non caricare nuovi file in un’istanza dall’aspetto vuoto creando due cronologie concorrenti.
Esegui il passaggio solo dopo aver verificato utenti, cronologia e nuove scritture
Accedi con ciascun utente di riferimento e verifica l’appartenenza agli album, i preferiti, le condivisioni, lo stato della ricerca o delle persone, alcuni originali rappresentativi, le date e il numero previsto di elementi nella libreria. Quindi carica una nuova foto di prova e conferma che venga visualizzata, elaborata e conservata dopo il riavvio del container.
Modifica la destinazione DNS o proxy di produzione solo dopo il superamento del test isolato. Mantieni l’istanza precedente arrestata ma ripristinabile, così i due sistemi non potranno accettare scritture contemporaneamente. Conserva il backup del database precedente alla migrazione e i contenuti multimediali della sorgente finché il nuovo host non avrà completato i normali backup e almeno un test di ripristino.
Esegui il rollback se i conteggi divergono, le relazioni note scompaiono, i nuovi caricamenti vengono scritti sul disco sbagliato o la destinazione non funziona dopo il riavvio. In caso di escalation, includi le versioni della sorgente e della destinazione, il timestamp del backup del database, le mappe dei mount, i log della copia, le differenze nei permessi e il primo elemento di verifica che non ha superato il test.
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...
