Checklist sicura per la migrazione di Immich su un nuovo server domestico

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

A Safe Immich Migration Checklist for a New Home Server - Zima Store Online

Una migrazione sicura di Immich inizia dimostrando cosa deve sopravvivere prima di copiare qualsiasi elemento: i file delle foto, il database e le impostazioni di distribuzione che li ricollegano sul nuovo host.

Su un home server, il rischio di migrazione deriva solitamente dallo spostamento di questi elementi in momenti diversi o dall'avvio della destinazione con percorsi errati. Tratta il vecchio server come copia per il rollback, blocca le scritture evitabili, annota la versione corrente e le mappature dello storage, quindi sposta un unico set di dati verificato sulla nuova macchina. La checklist seguente mantiene il lavoro reversibile finché la nuova istanza non riesce ad accedere, trovare la libreria originale, elaborare i processi e superare un riavvio senza tornare a uno stato vuoto.

Blocca la sorgente e registra lo stato noto come funzionante

Inizia dal server funzionante, non da quello nuovo. Registra la versione di Immich, la definizione Compose o dell'app store, i valori dell'ambiente che controllano i percorsi del database e dello storage, la posizione della libreria fotografica, quella del database e tutti i mount delle librerie esterne. Annota anche l'URL attuale del server e l'account utente che utilizzerai per la convalida.

Lo scopo di questo inventario è impedire che una migrazione si trasformi silenziosamente in un aggiornamento, una riprogettazione dei percorsi e una modifica della rete nello stesso momento. Mantieni il più possibile stabili la versione dell'applicazione e la struttura logica dello storage finché il ripristino non è verificato; le modifiche di versione potranno essere gestite dopo aver dimostrato il corretto funzionamento della destinazione.

Prima di copiare, interrompi o metti in pausa i nuovi caricamenti, se la tua famiglia può tollerarlo. Se non è pratico, definisci una finestra di passaggio e pianifica una breve sincronizzazione finale. L'uscita da questa fase consiste in una mappa scritta della sorgente che ti permetta di rispondere a dove si trovano gli originali, dove risiede lo stato del database e quale configurazione ricrea le stesse relazioni.

Acquisisci database, risorse e configurazione come un unico set di migrazione

Tratta il database e i file multimediali come un unico set di ripristino, non come due backup indipendenti. Gli attuali backup del database di Immich contengono metadati e riferimenti ai file, ma non le foto o i video; pertanto, il backup del database deve essere trasferito insieme ai contenuti di UPLOAD_LOCATION e a tutti i dati delle librerie esterne che gestisci separatamente.

Un set di migrazione utilizzabile richiede le risorse, lo stato di PostgreSQL e la configurazione che li ricollega. Un set completo di backup di Immich include le risorse caricate, un backup del database supportato e la configurazione della distribuzione, utilizzando i test di ripristino per dimostrare che il set funziona. Mantieni insieme questi elementi affinché la destinazione possa essere associata a un unico punto di ripristino.

Verifica il set di migrazione prima di intervenire sulla destinazione. Assicurati che il dump del database non sia vuoto, campiona diversi file originali dalla libreria copiata e conserva i file Compose e dell'ambiente nella stessa cartella di migrazione o nello stesso set di documentazione. Se non riesci a verificare un componente, fermati qui e crea una nuova copia invece di compensare sul nuovo server.

Prepara il nuovo host senza creare stati concorrenti

Crea prima le directory e i mount della destinazione, quindi verifica che il nuovo host veda i dischi o le condivisioni di rete previsti esattamente nei percorsi che intendi utilizzare. Un mount NAS mancante può lasciare al suo posto una normale directory vuota, e un container potrebbe inizializzarsi senza problemi utilizzando quel percorso di ripiego.

Installa il runtime e ricrea la definizione della distribuzione, ma non lasciare che un'istanza vuota di Immich accumuli caricamenti o configurazioni prima del ripristino dello stato precedente. Mantieni allineati alla sorgente le credenziali, il nome del database, le variabili di storage e le destinazioni dei mount delle librerie esterne, a meno che il piano di migrazione non preveda esplicitamente una modifica controllata dei percorsi.

Se il nuovo server richiede percorsi diversi sul sistema host, mappali deliberatamente mantenendo coerenti i percorsi visibili dal container e le aspettative del database. La destinazione è pronta solo quando i suoi mount effettivi puntano alle posizioni dei dati copiati e puoi spiegare ogni traduzione dei percorsi prima di avviare completamente l'applicazione.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Ripristina lo stato e ricollega ogni percorso di storage

Ripristina il database utilizzando la procedura di ripristino appropriata alla versione di Immich che ha creato il backup, quindi avvia i servizi rimanenti solo dopo che il database è pronto. Non improvvisare comandi distruttivi per il database basandoti su una guida precedente quando un'installazione più recente utilizza una procedura di ripristino diversa.

Durante il passaggio, mantieni intatta la relazione tra database e storage prima di riprendere l'uso normale. Una sequenza di migrazione di Immich testata segue lo stesso principio: l'applicazione deve aprirsi con lo stato del database ripristinato e i percorsi multimediali previsti, non inizializzare una libreria nuova e obbligare a una ricostruzione da zero.

Dopo l'avvio, controlla l'accesso allo storage prima di lanciare processi in background pesanti. Apri diverse risorse meno recenti di date differenti, verifica che le miniature vengano caricate, conferma la presenza di un album e di una persona o di un risultato di ricerca esistenti prima della migrazione e assicurati che le librerie esterne siano leggibili, se le utilizzi. Una schermata di configurazione iniziale o una timeline vuota è un segnale per fermarsi: ricontrolla le mappature del database e dei mount prima di scrivere un nuovo stato.

Convalida il carico di lavoro originale prima di dismettere il vecchio server

Un primo accesso riuscito non segna la fine della migrazione. Carica una foto di prova usa e getta dal client abituale, conferma che compaia nello storage host previsto, quindi eliminala tramite Immich e verifica che la libreria rimanga integra. Questo controlla l'intero percorso di scrittura, invece di dimostrare soltanto che i vecchi dati sono leggibili.

Riavvia il nuovo home server e ripeti i controlli importanti per la tua famiglia: accesso dal browser, connessione del backup mobile, diverse foto meno recenti, ricerca, un video rappresentativo, code dei processi e accesso remoto, se fa parte della configurazione abituale. La migrazione è completa solo quando lo stesso stato sopravvive al riavvio dell'host e i mount dello storage vengono resi disponibili prima dell'avvio di Immich.

Mantieni il vecchio server spento ma invariato per una finestra di rollback, invece di cancellarlo subito. Se la nuova istanza inizia a scrivere in una cartella vuota imprevista, non riesce a riprodurre la vecchia libreria dopo il riavvio o mostra errori del database che non sai spiegare, interrompi i nuovi caricamenti e torna alla sorgente nota come funzionante mentre confronti il set di migrazione. Dismettilo solo dopo che la destinazione ha superato l'uso normale e un nuovo test di backup.