Het belangrijkste wat deze bron niet bewijst, is dat ZimaOS de NAS zelfstandig heeft gescand en een normale fotobibliotheek heeft verwijderd. De gebruiker meldde dat zijn Immich-bestanden verdwenen na activiteiten rond het verwijderen en opnieuw installeren en vermoedde dat dit kwam door de optie ‘Configuraties verwijderen’, maar het exacte verwijderingsmoment is nooit door IceWhale gereproduceerd of vastgesteld.
Uit de later gedeelde configuratie bleek dat het om een aangepaste Docker Compose-implementatie ging, niet om het Immich-pakket uit de ZimaOS Store. De database, machine-learningcache en bibliotheek waren als bind mounts gekoppeld onder /mnt/bigdrive/data/immich/.... Zima-Giorgio merkte expliciet op dat de app niet uit de ZimaOS Store kwam. Daarom is het onveilig om te beweren dat het normale verwijderingsgedrag van de Store het verlies heeft veroorzaakt. De blijvende les is dat onvervangbare foto-assets en back-ups van databases buiten elk opruimpad moeten worden bewaard dat je niet volledig begrijpt.
De gebruiker meldde dat onvervangbare foto's na verwijderen en opnieuw installeren ontbraken
De gebruiker van de bron dacht mogelijk een optie voor het verwijderen van configuratie te hebben aangevinkt tijdens het verwijderen van Immich. Ook beschreef die crashlussen, beperkte toegang tot logboeken tijdens de storing en het feit dat hij ZimaOS uiteindelijk verliet nadat hij de afbeeldingen niet kon herstellen.
Dit is een ernstig dataverliesrapport, maar op het forum werd nooit een reproduceerbare reeks handelingen vastgesteld die aantoonde welke actie precies welke bestanden had verwijderd.
De eerste verklaring was een theorie uit de community
Een reactie uit de community suggereerde dat originelen mogelijk in een appmap stonden die door de opruimactie bij het verwijderen als configuratie- of gebruikersgegevens werd beschouwd. Dat is een redelijke waarschuwing, vooral wanneer gebruikers configuratie, database en originele media in één AppData-structuur combineren.
Het is niet bevestigd dat dit de oorzaak van dit specifieke incident was.
De gedeelde Compose-configuratie koppelde gegevens buiten het normale Store-AppData-voorbeeld
De gebruiker deelde later een Compose-definitie met hostpaden zoals:
/mnt/bigdrive/data/immich/postgres
/mnt/bigdrive/data/immich/cache
/mnt/bigdrive/data/immich/libraryDe Immich-server koppelde de bibliotheekmap aan /data. Dit is belangrijk bewijs, omdat het niet overeenkomt met de eerder voorgestelde eenvoudige theorie dat alle originelen zich onder /DATA/AppData/immich bevonden.
IceWhale bevestigde dat dit niet het Immich-pakket uit de ZimaOS Store was
Zima-Giorgio vroeg waar de app vandaan kwam nadat hij de configuratie had bekeken. De gebruiker antwoordde dat de app afkomstig was uit het Docker Compose-bestand van Immich. Giorgio adviseerde vervolgens om apps uit de ZimaOS Store te installeren.
Die aanbeveling stelt niet vast wat de bestanden heeft verwijderd, maar maakt wel duidelijk waar de grens van het appbeheer lag.
In het huidige ZimaOS worden containers en gekoppelde gegevens als verschillende zaken behandeld
De huidige documentatie van IceWhale legt uit dat de container zelf vervangbaar is, terwijl belangrijke applicatiegegevens in gekoppelde hostmappen staan. Er wordt expliciet aanbevolen om een back-up van die hostmappen te maken en AppData op geschikte opslag te bewaren.
Gebruik het huidige model voor appgegevens van ZimaOS voordat je een app met blijvende gegevens verwijdert.
Immich heeft bescherming nodig voor zowel assets als de database
Foto's en video's op schijf vormen slechts de helft van een Immich-herstel. Albums, gebruikers, metagegevens, bestandsregistraties en applicatiestatus staan in PostgreSQL. Een veilig plan beschermt zowel de assetstructuur als een compatibele back-up van de database.
Vertrouw niet op een selectievakje bij het verwijderen van een app als back-upstrategie.
Voordat je een fotobeheerder verwijdert
- noteer elke volumekoppeling aan de hostzijde;
- controleer het werkelijke pad naar foto- en video-assets;
- maak een onafhankelijke back-up van de database en test deze;
- kopieer onvervangbare assets naar een ander apparaat of andere opslag;
- begrijp precies waarop elke optie als ‘gebruikersgegevens/configuratie verwijderen’ betrekking heeft;
- verwijder of maak de app pas daarna opnieuw aan.
Als bestanden plotseling verdwijnen, beperk dan verdere schrijfbewerkingen
Stop de applicatie en vermijd het installeren of opnieuw aanmaken van containers of het kopiëren van nieuwe gegevens naar het getroffen bestandssysteem totdat je de toestand begrijpt. Herstel eerst vanuit geverifieerde back-ups. Als er geen back-up is en de bestanden echt verdwenen zijn, bewaar de media dan in de huidige staat en vraag hulp bij herstel die specifiek is voor het bestandssysteem, in plaats van er herhaaldelijk nieuwe gegevens naartoe te schrijven.
De communitybron noemde herstelprogramma's, maar dat waren geen procedures van IceWhale en ze zijn niet gegarandeerd veilig voor elke RAID-configuratie of elk bestandssysteem.
Veelgestelde vragen over dataverlies in Immich
Heeft IceWhale bevestigd dat het verwijderen van de ZimaOS Store-app de foto's van de gebruiker heeft verwijderd?
Nee. De app was een aangepaste Compose-implementatie en het exacte verwijderingsmechanisme is nooit vastgesteld.
Bleek uit de gedeelde Compose-configuratie dat de bibliotheek onder /DATA/AppData/immich stond?
Nee. Er werden bind mounts voor bibliotheek, database en cache getoond onder /mnt/bigdrive/data/immich.
Wat is de veiligste preventiemaatregel?
Maak vóór het verwijderen, resetten of opnieuw koppelen van de stack afzonderlijke back-ups van zowel de originele foto- en video-assets als de Immich-database.
