Porque é que o Immich perde o acesso aos dados persistentes após a recriação da stack?

Quando o Immich parece vazio ou não consegue ler a biblioteca após a recriação da stack, parta do princípio de que os dados persistentes antigos estão desligados ou ilegíveis antes de assumir que foram eliminados.

A recriação dos contentores pode alterar a identidade do projeto Compose, a origem de um bind mount, a associação de um volume nomeado, o momento de montagem de uma partilha de rede ou o UID/GID que lê os dados. Pare a instância que parece nova antes de esta gravar muito estado novo, localize no anfitrião os caminhos da base de dados e dos ficheiros multimédia antigos e compare a stack recriada com o mapeamento da última versão funcional conhecida. O objetivo é voltar a ligar primeiro o estado existente; só recorra a uma cópia de segurança depois de provar que esse estado está realmente em falta ou danificado.

Pare a Instância Nova e Prove que os Dados Antigos Ainda Existem

Um assistente de configuração, uma linha temporal vazia ou uma biblioteca externa em falta imediatamente após a recriação são sinais de alerta de persistência. Pare o Immich e inspecione as localizações da base de dados e dos ficheiros multimédia no anfitrião antes de carregar novos ficheiros ou aceitar uma nova configuração vazia. As novas gravações podem dificultar comparações posteriores dos caminhos.

Verifique os diretórios antigos quanto ao número esperado de ficheiros, datas de modificação, ficheiros ou cópias da base de dados e imagens originais representativas. Se os dados estiverem presentes no anfitrião, o problema é de acesso ou mapeamento, não de desaparecimento. Crie um instantâneo ou uma cópia de segurança só de leitura desse estado antes de alterar proprietários ou mover diretórios.

Se os dados antigos não forem encontrados nos caminhos esperados, pesquise o conjunto de armazenamento e o inventário de volumes do Docker antes de eliminar qualquer coisa. A decisão é binária: o estado existente foi localizado e protegido, ou está genuinamente indisponível e o processo de recuperação passa a utilizar uma cópia de segurança conhecida como válida, em vez de reparar a montagem.

Compare as Montagens Recriadas com a Stack Anterior

Inspecione as montagens efetivas nos contentores do servidor e da base de dados do Immich recriados, não apenas o texto do Compose que se lembra de ter editado. Um caminho de bind relativo pode ser resolvido a partir de um diretório de projeto diferente, e um projeto Compose renomeado pode associar um novo volume nomeado, deixando o antigo intacto mas sem utilização.

Uma montagem falhada, alterada ou em falta pode apresentar um diretório vazio dentro de um contentor, mesmo quando os dados esperados continuam a existir noutro local do anfitrião. Utilize as verificações de montagem de volumes Docker para comparar Source, Destination, o tipo de montagem e a identidade do volume nomeado em todos os caminhos persistentes do Immich. Uma incompatibilidade neste ponto explica diretamente uma instância com aparência nova.

Corrija apenas o mapeamento de montagem incorreto e, em seguida, crie ou inicie o contentor sem remover volumes. Se os ficheiros esperados aparecerem no mesmo caminho dentro do contentor após a alteração, deixe os dados no local. Se a lista de montagens estiver correta mas o acesso continuar a falhar, preserve o mapeamento e passe à disponibilidade do armazenamento do anfitrião e às permissões, em vez de criar outro volume.

Verifique se o Armazenamento Externo Foi Montado Antes de o Immich Iniciar

Se os dados do Immich estiverem num conjunto de discos HDD, numa partilha NAS, numa camada de agregação ou noutra montagem externa, confirme que esse armazenamento está realmente montado no anfitrião antes de o Docker iniciar a stack. Um caminho como /mnt/photos pode continuar a existir como um diretório local normal quando o dispositivo real está ausente.

Os dados persistentes do Docker sobrevivem à substituição de contentores apenas quando o volume pretendido ou o bind mount é novamente associado corretamente. O modelo de persistência dos volumes Docker subjacente não faz com que um disco do anfitrião ou uma partilha de rede em falta apareça automaticamente. Por isso, verifique o dispositivo de armazenamento e um ficheiro conhecido no anfitrião antes de testar o mesmo caminho dentro do Immich.

Se descobrir ficheiros de recurso gravados no ponto de montagem vazio enquanto o armazenamento real estava ausente, pare o Immich antes de montar o dispositivo sobre esses ficheiros. Reconcilie esses ficheiros separadamente, adicione uma dependência de arranque ou uma verificação de estado para a montagem do armazenamento e só depois reinicie a stack. Se o armazenamento do anfitrião estiver estável e o caminho dentro do contentor continuar ilegível, avance para o ramo das permissões.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifique UID, GID e Permissões dos Diretórios sem Reescrever Tudo

Uma stack recriada pode executar um serviço com uma identidade numérica, um espaço de nomes de utilizadores ou um contexto de segurança diferente do anterior. O resultado distingue-se de uma montagem em falta: o caminho existe e os ficheiros estão visíveis a partir do anfitrião, mas os registos do Immich mostram erros de permissão ou o serviço não consegue criar os ficheiros esperados.

Compare o proprietário numérico e os bits de modo nos diretórios afetados do anfitrião com a identidade do utilizador dentro do contentor recriado. Comece por testar uma leitura inofensiva e, em seguida, uma escrita reversível numa localização descartável sob a mesma montagem. Evite alterar recursivamente o proprietário de todo o arquivo de fotografias até saber qual o serviço que precisa de acesso de escrita e quais os ficheiros originais que devem permanecer intocados.

Corrija a menor incompatibilidade de diretório ou identidade que explique a falha, reinicie uma vez e volte a verificar os registos. Se o acesso continuar a falhar com montagens e permissões correspondentes, pare de fazer alterações ao sistema de ficheiros e inspecione a ligação à base de dados, a substituição de variáveis de ambiente ou a camada de segurança que mudou com a recriação.

Volte a Ligar o Estado Original e Valide Outra Recriação

Quando os caminhos antigos da base de dados e dos ficheiros multimédia estiverem associados e legíveis, inicie o Immich e procure os utilizadores, álbuns, pessoas e ficheiros representativos antigos. Não considere a reparação concluída apenas porque a página inicial carrega; verifique se a aplicação está a ler o estado original, em vez de uma base de dados recém-inicializada ao lado deste.

A distinção importante é que os contentores podem ser descartáveis, enquanto o estado da aplicação tem de permanecer num armazenamento estável fora do ciclo de vida dos contentores. Documente os nomes das montagens e os caminhos do anfitrião corrigidos e utilize funções persistentes de armazenamento num servidor de ficheiros para manter a próxima recriação da stack associada aos mesmos dados.

Por fim, recrie novamente a stack em condições controladas e repita as verificações originais. A correção só fica comprovada se a mesma base de dados e os mesmos ficheiros multimédia reaparecerem após a recriação e depois de reiniciar o anfitrião. Se o estado antigo voltar a desaparecer, ou se a base de dados indicar corrupção em vez de erros de acesso, reverta para a cópia protegida e passe à recuperação da base de dados ou da cópia de segurança, em vez de continuar a experimentar montagens.