Ripristina gli originali, il database del catalogo e la configurazione che definisce i percorsi come un'unità di recupero unica.
Per una libreria NAS domestica come Immich, Lightroom, PhotoPrism o simili, i file immagine da soli possono riaprirsi ma perdere persone, album, valutazioni, modifiche, posizioni e risultati di ricerca. Un recupero ricercabile deve allineare i file multimediali con il database o catalogo che li descrive, la configurazione che mappa i loro percorsi e eventuali segreti o versioni dell'applicazione necessari per leggere quello stato.
Definire la Ricercabilità come Più di Semplicemente Aprire i File Originali
Una libreria fotografica è ricercabile quando l'applicazione può collegare ogni originale al suo record nel database, ai metadati, all'appartenenza agli album, alle assegnazioni delle persone e al percorso. Essere in grado di aprire un JPEG dimostra il recupero del file, non il recupero della libreria.
Una discussione sul recupero di Immich mostra che il database contiene le posizioni dei file e i metadati della libreria mentre le foto effettive rimangono nelle cartelle di upload. Ripristinare solo un lato può produrre miniature o record che puntano a originali assenti.
Scrivi l'esito richiesto prima del ripristino: gli originali si aprono, le date della timeline sono corrette, gli album appaiono, la ricerca delle persone funziona, le modifiche o le valutazioni ritornano e gli utenti mantengono l'accesso. Questo esito definisce quali componenti appartengono all'unità di recupero.
Ripristina Originali e Catalogo dallo Stesso Confine Temporale
L'albero multimediale e il suo catalogo dovrebbero rappresentare lo stesso punto di recupero. Un database più recente può fare riferimento a file mancanti in una copia multimediale più vecchia, mentre un catalogo più vecchio può ignorare foto che esistono sul disco.
Un caso di recupero Lightroom ha richiesto un ripristino in due fasi: prima la cartella delle foto, poi un backup del catalogo corrispondente precedente all'incidente. La stessa dipendenza si applica alle librerie self-hosted che memorizzano modifiche, valutazioni, persone o album al di fuori degli originali.
Seleziona il timestamp comune più vicino tra il backup multimediale, il dump del database e la copia della configurazione. Se non esiste un punto comune, ripristina in un'istanza isolata e riconcilia la differenza prima di esporre la libreria agli utenti.
Preserva Percorsi, Identificatori e Configurazione che Uniscono i Pezzi
Un catalogo può essere integro e mostrare comunque risorse mancanti quando il percorso ripristinato, il nome del mount, l'identificatore del volume o la radice della libreria differiscono dal riferimento memorizzato. La coerenza del percorso è quindi parte del recupero, non un compito cosmetico post-ripristino.
Gli utenti Lightroom segnalano che i file ripristinati devono mantenere gli stessi nomi e la struttura delle cartelle. Per le app container, l'equivalente può essere un percorso bind-mount, una variabile d'ambiente, un URL del database o la radice dello storage.
Ripristina il file Compose o la configurazione dell'app, le variabili d'ambiente, i segreti, gli ID utente e le definizioni di mount accanto al database. Non effettuare bulk-relink o rescansioni finché non hai confermato quali identificatori l'applicazione si aspetta.
Separa lo Stato Richiesto dagli Asset di Ricerca Rigenerabili
Originali, record del database, dati utente, relazioni degli album, modifiche e configurazione sono normalmente richiesti. Miniature, modelli in cache e alcune embedding di machine learning possono essere rigenerabili, ma la libreria può rimanere lenta o parzialmente non ricercabile finché questi processi non terminano.
Una guida attuale al deployment di Immich descrive servizi separati per il server, il machine learning e la coda di job in background, e nota la programmazione integrata del backup del database. Questi componenti spiegano perché la ricerca e il riconoscimento delle persone possono dipendere da più della directory multimediale visibile.
Documenta quali asset generati possono essere ricostruiti e quanto tempo richiede la rigenerazione. Se la ricostruzione richiederebbe giorni di tempo CPU o lo stato originale del modello non può essere riprodotto, proteggi quell'asset come parte dell'unità di recupero pratica anche se l'applicazione può tecnicamente ricrearlo.
Abbina lo Stato Ripristinato a una Versione Compatibile dell'Applicazione
Un catalogo o database può richiedere la versione dell'applicazione che lo ha creato o migrato. Avviare un servizio più vecchio su uno stato più recente, o viceversa, può fallire prima che i media vengano valutati.
Gli utenti di librerie fotografiche hanno incontrato incompatibilità di versione del catalogo. Conserva il tag dell'immagine distribuita, le note di migrazione e la versione del database in modo che l'ambiente di test possa riprodurre il percorso di aggiornamento previsto.
Avvia la libreria ripristinata offline o con un nome temporaneo. Conferma le migrazioni del database, il login utente e la risoluzione dei percorsi prima di permettere ai client mobili o ai job in background di modificare lo stato ripristinato.
Valida Ricerca, Album e Persone Prima del Passaggio
Usa un test di ripristino isolato che includa foto vecchie e nuove rappresentative, elementi modificati, più utenti, album condivisi, metadati di posizione e persone note. Cerca record il cui risultato atteso è già documentato.
Il piano di backup famiglia Immich esistente di ZimaSpace fornisce il contesto di pianificazione adiacente; questo test di ripristino deve ora dimostrare che quei componenti ritornano insieme.
Effettua il passaggio solo quando gli originali si aprono, i conteggi corrispondono, album e permessi ritornano, i risultati di ricerca sono plausibili e un nuovo upload viene indicizzato correttamente. Mantieni l'istanza precedente e i file di recupero invariati finché la libreria di test non ha superato un riavvio e un nuovo backup.
Supporto e consigli
Altro da leggere

Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...

Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...

Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...

