I dati originali non sembravano essere andati persi. Dopo il ripristino di ZimaOS, il RAID6 esisteva ancora e directory comeinermi erano ancora presenti. caricamento, pgdata, miniature, profilo, e video codificati erano ancora presenti. Il problema era che lo stack Immich reinstallato non era collegato al vecchio stato del database/della libreria in modo da ripristinare il catalogo fotografico precedente.
Il consiglio più prudente della fonte era: non eliminare né spostare ancora le vecchie cartelle upload e pgdata. Immich non ricostruisce il catalogo completo semplicemente rilevando i file immagine sul disco. Il database contiene percorsi dei file, utenti, album, metadati e stato dell'applicazione. La documentazione attuale di Immich v3 rende esplicita questa relazione e consiglia di eseguire il backup sia dei file degli asset sia del database.
Prima conferma il percorso reale di mount del RAID
La fonte utilizzava:
ls -la /media
find /media -maxdepth 4 -type d \( -iname "immich" -o -iname "pgdata" -o -iname "upload" \)e ha trovato:
/media/photos/immich
/media/photos/immich/pgdata
/media/photos/immich/uploadQuesto ha stabilito che le vecchie cartelle di Immich esistevano ancora sul RAID.
/media/ZimaOS-HD → /DATA non dimostrava che Immich stesse utilizzando l'unità del sistema operativo
L'utente era allarmato da:
/media/ZimaOS-HD -> /DATAma la community ha spiegato correttamente che si tratta di una relazione di mount/symlink di ZimaOS. La sua presenza non indica quali percorsi host stiano effettivamente utilizzando i container Immich.
Ispezionare i mount effettivi di Docker
La discussione consigliava di verificare:
docker inspect immich-server --format '{{json .Mounts}}'
docker inspect immich-postgres --format '{{json .Mounts}}'È più affidabile che presumere che uno screenshot o un vecchio ricordo riflettano la configurazione del container in esecuzione.
Il vecchio pgdata è importante quanto i vecchi file fotografici
Se la reinstallazione ha inizializzato un database completamente nuovo invece di quello vecchio, i file possono essere ancora presenti mentre Immich appare vuoto.
L'attuale Immich utilizza UPLOAD_LOCATION e DB_DATA_LOCATION
L'attuale Compose di Immich v3 separa la posizione degli asset sull'host e la posizione di Postgres usando UPLOAD_LOCATION e DB_DATA_LOCATION. Upstream afferma esplicitamente che le condivisioni di rete non sono supportate per il percorso del database.
Usa l'attuale modello di archiviazione di Immich.
Un backup del database è più sicuro che ricollegare una vecchia directory pgdata attiva tra versioni diverse
La fonte utilizzava Immich v2.7.2. L'attuale Immich è la v3. Quando si esegue un ripristino tra versioni diverse, il flusso di lavoro upstream per il backup e il ripristino del database è più sicuro che presumere di poter semplicemente collegare una vecchia directory dati di Postgres a un'immagine di database più recente.
Vedi l'attuale procedura di backup e ripristino di Immich.
Non riorganizzare manualmente le cartelle interne delle risorse di Immich
La documentazione attuale di Immich avverte che cartelle come libreria, caricamento, miniature, profilo, e video codificati sono gestiti dall'applicazione. Spostare o eliminare singoli file alle spalle di Immich può creare risorse mancanti o non tracciate.
L'utente di origine non ha confermato un ripristino riuscito
I membri della community hanno proposto diversi approcci al mapping, incluso un singolo mount principale, ma alla fine jerlo ha accantonato il problema e ha ricominciato da capo su un altro sistema. Pertanto, il forum non convalida alcun percorso di mapping come soluzione definitiva.
Attualmente Immich preferisce una radice di caricamento gestita, anziché mappare manualmente ogni cartella secondaria
Le schermate di origine mostravano una mappatura manuale di caricamento, miniature, profilo, libreria, video codificatie i backup uno alla volta. Invece, l'attuale Compose upstream è incentrato su UPLOAD_LOCATION, con Immich che gestisce le proprie directory secondarie interne sotto quella radice.
Quando ricostruisci il sistema su una versione più recente di Immich, usa il layout attuale di Compose/storage invece di riprodurre una serie storica di mappature secondarie, a meno che il pacchetto non le richieda specificamente.
Mantieni il percorso dei dati di Postgres su uno storage locale supportato
La documentazione attuale di Immich afferma esplicitamente che le condivisioni di rete non sono supportate per DB_DATA_LOCATION. Un filesystem RAID/storage collegato localmente può essere appropriato, ma una directory del database montata tramite SMB/NFS non è il percorso supportato per il database.
Un ripristino completo di Immich richiede sia gli asset sia il database
La documentazione attuale sul backup di Immich afferma che i backup del database contengono i metadati e le informazioni degli utenti, ma non gli asset fotografici/video. La struttura degli asset deve essere sottoposta a backup separatamente e ripristinata insieme a un backup del database compatibile.
Questo spiega perché, nel caso di origine, il fatto che «i file caricati siano ancora presenti» fosse rassicurante, ma non sufficiente.
Non collegare alla leggera una vecchia directory pgdata attiva a una versione diversa di PostgreSQL/immagine
Una directory di dati PostgreSQL non elaborata dipende dalla versione. Se il vecchio ambiente e il nuovo pacchetto usano versioni diverse di PostgreSQL o Immich, è preferibile usare un dump/ripristino del database supportato o una procedura di migrazione documentata. Esegui un backup byte per byte del vecchio pgdata prima di fare esperimenti.
FAQ sul ripristino di Immich
Il ripristino di ZimaOS ha cancellato le cartelle fotografiche del RAID6 di origine?
No. L'utente ha detto che il RAID e le directory/i file esistenti sono rimasti intatti.
Il semplice collegamento dei vecchi file fotografici ripristinerà la libreria di Immich?
Non necessariamente. Immich richiede anche lo stato corrispondente del database/catalogo.
Che cosa dovrebbe essere protetto prima di fare esperimenti?
L'intero archivio degli asset, insieme al database o a un backup verificato del database.
