A coisa mais importante que esta fonte não prova é que o ZimaOS tenha analisado o NAS de forma independente e eliminado uma biblioteca de fotografias normal. O utilizador relatou que os ficheiros do Immich desapareceram após atividades de desinstalação/reinstalação e suspeitou da opção «Eliminar configurações», mas o evento exato de eliminação nunca foi reproduzido nem diagnosticado pela IceWhale.
A configuração publicada posteriormente mostrou uma implementação personalizada do Docker Compose, não o pacote Immich da Loja ZimaOS. A base de dados, a cache de aprendizagem automática e a biblioteca estavam montadas através de bind mounts em /mnt/bigdrive/data/immich/.... Zima-Giorgio reparou explicitamente que a aplicação não vinha da Loja ZimaOS. Por isso, não é seguro afirmar que o comportamento normal de desinstalação da Loja tenha causado a perda. A lição duradoura é manter os ficheiros de fotografias insubstituíveis e as cópias de segurança da base de dados fora de qualquer processo de limpeza que não compreenda totalmente.
O utilizador relatou o desaparecimento de fotografias insubstituíveis após a desinstalação/reinstalação
O utilizador da fonte acreditava que poderia ter assinalado uma opção para eliminar a configuração ao remover o Immich. Também descreveu ciclos de falhas, acesso limitado aos registos durante a falha e, por fim, abandonou o ZimaOS depois de não conseguir recuperar as imagens.
Este é um relato grave de perda de dados, mas o fórum nunca apresentou uma sequência reproduzível que demonstrasse qual ação removeu efetivamente quais ficheiros.
A primeira explicação foi uma teoria da comunidade
Uma resposta da comunidade sugeriu que os originais poderiam estar numa pasta da aplicação que a limpeza da desinstalação considerava dados de configuração/utilizador. É um risco razoável a assinalar, sobretudo se os utilizadores misturarem a configuração, a base de dados e os ficheiros multimédia originais numa única árvore AppData.
Não foi confirmado que essa tenha sido a causa deste incidente específico.
O Compose publicado mapeava os dados para fora do exemplo normal de AppData da Loja
Mais tarde, o utilizador publicou uma definição Compose com caminhos no anfitrião, como:
/mnt/bigdrive/data/immich/postgres
/mnt/bigdrive/data/immich/cache
/mnt/bigdrive/data/immich/libraryO servidor Immich mapeava a pasta da biblioteca para /data. Esta é uma evidência importante, porque não corresponde à teoria simples, apresentada anteriormente, de que todos os originais estavam em /DATA/AppData/immich.
A IceWhale confirmou que não era o pacote Immich da Loja ZimaOS
Zima-Giorgio perguntou de onde vinha a aplicação depois de analisar a configuração. O utilizador respondeu que a aplicação vinha do ficheiro Docker Compose do Immich. Giorgio recomendou então instalar aplicações a partir da Loja ZimaOS.
Essa recomendação não identifica o que eliminou os ficheiros, mas estabelece claramente o limite de gestão da aplicação.
O ZimaOS atual trata o contentor e os dados mapeados como elementos diferentes
A documentação atual da IceWhale explica que o próprio contentor é descartável, enquanto os dados importantes da aplicação ficam em pastas mapeadas no anfitrião. Recomenda explicitamente fazer cópias de segurança dessas pastas no anfitrião e manter o AppData num armazenamento adequado.
Consulte o modelo atual de dados das aplicações do ZimaOS antes de remover uma aplicação com estado.
O Immich precisa de proteção tanto dos ficheiros multimédia como da base de dados
As fotografias e os vídeos no disco são apenas metade de uma recuperação do Immich. Os álbuns, utilizadores, metadados, registos de ficheiros e o estado da aplicação ficam no PostgreSQL. Um plano seguro protege tanto a árvore de ficheiros multimédia como uma cópia de segurança compatível da base de dados.
Não dependa de uma caixa de seleção de desinstalação da aplicação como estratégia de cópia de segurança.
Antes de desinstalar um gestor de fotografias
- registe todos os mapeamentos de volumes no anfitrião;
- verifique o caminho real dos ficheiros de fotografias/vídeos;
- crie e teste uma cópia de segurança independente da base de dados;
- copie os ficheiros insubstituíveis para outro dispositivo/armazenamento;
- compreenda exatamente o que qualquer opção «eliminar dados do utilizador/configuração» visa;
- só depois remova/recrie a aplicação.
Se os ficheiros desaparecerem subitamente, minimize novas gravações
Pare a aplicação e evite instalar/recriar contentores ou copiar novos dados para o sistema de ficheiros afetado até compreender o estado. Restaure primeiro a partir de cópias de segurança verificadas. Se não existir uma cópia de segurança e os ficheiros tiverem realmente desaparecido, preserve o suporte e procure ajuda de recuperação específica para o sistema de ficheiros, em vez de continuar a escrever nele.
A comunidade da fonte mencionou ferramentas de recuperação, mas estas não eram procedimentos da IceWhale e não são garantidamente seguras para todos os sistemas RAID/sistemas de ficheiros.
Perguntas frequentes sobre perda de dados do Immich
A IceWhale confirmou que a desinstalação do Immich da Loja ZimaOS eliminou as fotografias do utilizador da fonte?
Não. A aplicação era uma implementação Compose personalizada e o mecanismo exato de eliminação nunca foi estabelecido.
O Compose publicado mostrava a biblioteca em /DATA/AppData/immich?
Não. Mostrava bind mounts da biblioteca/base de dados/cache em /mnt/bigdrive/data/immich.
Qual é a prevenção mais segura?
Faça cópias de segurança independentes tanto dos ficheiros originais de fotografias/vídeos como da base de dados do Immich antes de desinstalar, repor ou remapear a stack.
