Det viktigaste som den här källan inte bevisar är att ZimaOS självständigt skannade NAS-enheten och raderade ett vanligt fotobibliotek. Användaren rapporterade att Immich-filerna försvann efter avinstallation/ominstallation och misstänkte alternativet ”Radera konfigurationer”, men den exakta raderingshändelsen återskapades eller diagnostiserades aldrig av IceWhale.
Den konfiguration som publicerades senare visade en anpassad Docker Compose-distribution, inte Immich-paketet från ZimaOS Store. Databasen, cacheminnet för maskininlärning och biblioteket var bind-monterade under /mnt/bigdrive/data/immich/.... Zima-Giorgio noterade uttryckligen att appen inte kom från ZimaOS Store. Därför är det osäkert att hävda att Stores normala avinstallationsbeteende orsakade förlusten. Den bestående lärdomen är att förvara oersättliga fotoresurser och databassäkerhetskopior utanför alla rensningsvägar som du inte förstår helt.
Användaren rapporterade att oersättliga foton saknades efter avinstallation/ominstallation
Källans användare trodde att hen kan ha markerat ett alternativ för att radera konfigurationen när Immich togs bort. Hen beskrev också omstartsloopar, begränsad åtkomst till loggar under felet och lämnade till slut ZimaOS efter att inte ha kunnat återställa bilderna.
Detta är en allvarlig rapport om dataförlust, men forumet tog aldrig fram ett reproducerbart förlopp som visade vilken åtgärd som faktiskt tog bort vilka filer.
Den första förklaringen var en teori från communityn
Ett svar från communityn föreslog att originalen kan ha legat i en appmapp som avinstallationens rensning betraktade som konfigurations-/användardata. Det är en rimlig risk att varna för, särskilt om användare blandar konfiguration, databas och originalmedier i samma AppData-träd.
Det bekräftades inte som orsaken till just denna incident.
Den publicerade Compose-konfigurationen mappade data utanför det normala exemplet för Store-AppData
Användaren publicerade senare en Compose-definition med värdsökvägar som:
/mnt/bigdrive/data/immich/postgres
/mnt/bigdrive/data/immich/cache
/mnt/bigdrive/data/immich/libraryImmich-servern mappade biblioteksmappen till /data. Detta är viktiga bevis eftersom det inte stämmer med den enkla teorin att ”alla original låg under /DATA/AppData/immich” som föreslogs tidigare.
IceWhale bekräftade att det inte var Immich-paketet från ZimaOS Store
Zima-Giorgio frågade varifrån appen kom efter att ha granskat konfigurationen. Användaren svarade att den kom från Immichs Docker Compose-fil. Giorgio rekommenderade därefter att installera appar från ZimaOS Store.
Den rekommendationen visar inte vad som raderade filerna, men den fastställer tydligt gränsen för apphanteringen.
I nuvarande ZimaOS behandlas containern och mappade data som olika saker
Aktuell dokumentation från IceWhale förklarar att själva containern kan tas bort medan viktiga appdata finns i mappade värdmappar. Den rekommenderar uttryckligen att säkerhetskopiera dessa värdmappar och förvara AppData på lämplig lagring.
Använd den aktuella modellen för appdata i ZimaOS innan du tar bort en app som lagrar tillstånd.
Immich behöver skydd för både mediefiler och databas
Foton och videor på disken är bara ena halvan av en återställning av Immich. Album, användare, metadata, filposter och apptillstånd finns i PostgreSQL. En säker plan skyddar både medieträdet och en kompatibel databassäkerhetskopia.
Förlita dig inte på en kryssruta vid appavinstallation som strategi för säkerhetskopiering.
Innan du avinstallerar en fotoapp
- notera alla volymmappningar på värden;
- verifiera den faktiska sökvägen till foto- och videofilerna;
- skapa och testa en oberoende databassäkerhetskopia;
- kopiera oersättliga filer till en annan enhet eller lagring;
- förstå exakt vad alternativet ”radera användardata/konfiguration” riktar sig mot;
- ta först därefter bort eller återskapa appen.
Om filer plötsligt försvinner bör du minimera ytterligare skrivningar
Stoppa appen och undvik att installera eller återskapa containrar eller kopiera nya data till det berörda filsystemet tills du förstår situationen. Återställ först från verifierade säkerhetskopior. Om det inte finns någon säkerhetskopia och filerna verkligen är borta bör du bevara mediet och söka hjälp med filsystemsspecifik återställning i stället för att upprepade gånger skriva till det.
Communityn nämnde återställningsverktyg, men dessa var inte IceWhales procedurer och kan inte garanteras vara säkra för alla RAID-konfigurationer eller filsystem.
Vanliga frågor om dataförlust i Immich
Bekräftade IceWhale att avinstallationen från ZimaOS Store raderade källanvändarens foton?
Nej. Appen var en anpassad Compose-distribution och den exakta raderingsmekanismen fastställdes aldrig.
Visade den publicerade Compose-konfigurationen att biblioteket låg under /DATA/AppData/immich?
Nej. Den visade bind-monteringar för bibliotek, databas och cache under /mnt/bigdrive/data/immich.
Vad är det säkraste sättet att förebygga detta?
Säkerhetskopiera både de ursprungliga foto- och videofilerna samt Immich-databasen separat innan du avinstallerar, återställer eller mappar om stacken.
