La cosa più importante che questa fonte non dimostra è che ZimaOS abbia scansionato autonomamente il NAS ed eliminato una normale libreria di foto. L’utente ha segnalato che i file di Immich erano scomparsi dopo operazioni di disinstallazione/reinstallazione e ha sospettato dell’opzione “Elimina configurazioni”, ma IceWhale non ha mai riprodotto né diagnosticato l’evento esatto della cancellazione.
La configurazione pubblicata in seguito mostrava un deployment personalizzato con Docker Compose, non il pacchetto Immich dello Store di ZimaOS. Il database, la cache del machine learning e la libreria erano collegati tramite bind mount sotto /mnt/bigdrive/data/immich/.... Zima-Giorgio ha notato esplicitamente che l’app non proveniva dallo Store di ZimaOS. Pertanto, non è sicuro affermare che la normale procedura di disinstallazione dello Store abbia causato la perdita. La lezione da conservare è mantenere gli asset fotografici insostituibili e i backup del database al di fuori di qualsiasi percorso di pulizia di cui non si comprendano completamente gli effetti.
L’utente ha segnalato la scomparsa di foto insostituibili dopo la disinstallazione/reinstallazione
L’utente della fonte riteneva di aver selezionato un’opzione per eliminare la configurazione durante la rimozione di Immich. Ha inoltre descritto cicli continui di arresto e riavvio, un accesso limitato ai log durante il problema e, infine, ha abbandonato ZimaOS dopo non essere riuscito a recuperare le immagini.
Si tratta di una grave segnalazione di perdita di dati, ma sul forum non è mai stata prodotta una sequenza riproducibile che mostrasse quale azione avesse effettivamente rimosso quali file.
La prima spiegazione era una teoria della community
Una risposta della community suggeriva che gli originali potessero trovarsi in una cartella dell’app considerata dalla pulizia della disinstallazione come dati di configurazione o dell’utente. È un rischio ragionevole da segnalare, soprattutto se gli utenti mescolano configurazione, database e file multimediali originali nello stesso albero AppData.
Non è stato confermato che questa fosse la causa dello specifico incidente.
Il Compose pubblicato collegava i dati al di fuori del normale esempio AppData dello Store
L’utente ha poi pubblicato una definizione Compose con percorsi sull’host come:
/mnt/bigdrive/data/immich/postgres
/mnt/bigdrive/data/immich/cache
/mnt/bigdrive/data/immich/libraryIl server Immich collegava la cartella della libreria a /data. Si tratta di un elemento importante, perché non coincide con la semplice teoria secondo cui “tutti gli originali si trovavano sotto /DATA/AppData/immich”, proposta in precedenza.
IceWhale ha confermato che non si trattava del pacchetto Immich dello Store di ZimaOS
Zima-Giorgio ha chiesto da dove provenisse l’app dopo aver esaminato la configurazione. L’utente ha risposto che proveniva dal file Docker Compose di Immich. Giorgio ha quindi consigliato di installare le app dallo Store di ZimaOS.
Questa raccomandazione non identifica cosa abbia eliminato i file, ma stabilisce chiaramente il confine nella gestione dell’app.
Nelle versioni attuali, ZimaOS tratta il container e i dati collegati come elementi distinti
La documentazione attuale di IceWhale spiega che il container è temporaneo, mentre i dati importanti dell’applicazione risiedono nelle cartelle dell’host collegate. Raccomanda esplicitamente di eseguire il backup di tali cartelle e di conservare AppData su uno spazio di archiviazione appropriato.
Consulta il modello attuale dei dati delle app di ZimaOS prima di rimuovere un’app con stato persistente.
Immich richiede la protezione sia degli asset sia del database
Per ripristinare Immich, i file foto/video su disco rappresentano solo una delle due componenti. Album, utenti, metadati, record dei file e stato dell’applicazione risiedono in PostgreSQL. Un piano sicuro protegge sia l’albero degli asset sia un backup compatibile del database.
Non affidarti a una casella di controllo della disinstallazione come strategia di backup.
Prima di disinstallare un gestore di foto
- annota ogni mappatura dei volumi sul lato host;
- verifica il percorso effettivo degli asset fotografici/video;
- crea e testa un backup indipendente del database;
- copia gli asset insostituibili su un altro dispositivo o spazio di archiviazione;
- comprendi esattamente quali elementi interessa qualsiasi opzione come “elimina dati utente/configurazione”;
- solo a quel punto rimuovi o ricrea l’app.
Se i file scompaiono improvvisamente, riduci al minimo le ulteriori scritture
Arresta l’applicazione ed evita di installare o ricreare container o copiare nuovi dati sul file system interessato finché non ne comprendi lo stato. Ripristina prima i backup verificati. Se non esiste alcun backup e i file sono davvero scomparsi, conserva il supporto e richiedi assistenza per il recupero specifica del file system, invece di continuare a scrivervi.
La community della fonte ha menzionato strumenti di recupero, ma non si trattava di procedure IceWhale e non è garantito che siano sicuri per ogni configurazione RAID o file system.
Domande frequenti sulla perdita di dati di Immich
IceWhale ha confermato che la disinstallazione dallo Store di ZimaOS ha eliminato le foto dell’utente della fonte?
No. L’app era un deployment Compose personalizzato e il meccanismo esatto della cancellazione non è mai stato stabilito.
Il Compose pubblicato mostrava la libreria sotto /DATA/AppData/immich?
No. Mostrava bind mount della libreria, del database e della cache sotto /mnt/bigdrive/data/immich.
Qual è la prevenzione più sicura?
Esegui il backup indipendente sia degli asset fotografici/video originali sia del database di Immich prima di disinstallare, reimpostare o rimappare lo stack.
