O que é o estado do Immich e que partes têm de persistir?

O estado do Immich é o conjunto de dados multimédia, da base de dados, de identidade, de configuração e derivados necessário para reproduzir o comportamento pretendido da biblioteca.

Os ficheiros originais são essenciais, mas não constituem a aplicação inteira. Álbuns, utilizadores, propriedade, rostos, representações de pesquisa, mapeamentos de caminhos e segredos determinam como esses ficheiros aparecem e quem pode utilizá-los; alguns são autoritativos, enquanto outros podem ser reconstruídos a custo.

As relações entre os ficheiros multimédia originais e a base de dados formam o núcleo

As fotografias e os vídeos originais preservam o conteúdo insubstituível. A base de dados preserva a forma como o Immich interpreta esse conteúdo: utilizadores, propriedade, álbuns, identificadores de recursos, metadados e relações de processamento. Cada lado, por si só, fica incompleto quando o objetivo é restaurar o mesmo serviço doméstico, em vez de simplesmente recuperar ficheiros soltos.

O guia de cópia de segurança do Immich da ZimaSpace explica que uma proteção abrangente inclui os ficheiros multimédia carregados e a base de dados. Esta distinção fornece uma definição útil de estado: os ficheiros multimédia respondem à questão de que bytes existem, enquanto os registos da base de dados respondem à questão de como a aplicação associa, apresenta e controla esses bytes.

Mapeie a base de dados e todas as localizações dos ficheiros multimédia originais para caminhos duradouros no anfitrião ou no sistema de armazenamento. Confirme que as bibliotecas externas estão protegidas pela sua própria política. Não deduza a persistência a partir de um nome de caminho interno de um contentor; inspecione o volume efetivo ou o bind mount que sobrevive à eliminação e recriação do contentor.

A configuração e os segredos recriam os limites do serviço

As definições do Compose, as definições do ambiente, os mapeamentos de armazenamento, as regras do proxy e a configuração do fornecedor de identidade determinam como os serviços encontram os dados e uns aos outros. As palavras-passe, o material de assinatura e as credenciais de API também têm de sobreviver de forma segura. Reconstruir os ficheiros sem estas definições pode deixar a base de dados acessível com a identidade ou os caminhos errados.

Uma análise do planeamento de armazenamento do Immich separa a localização da base de dados e das miniaturas do armazenamento em massa dos originais. A sua lição é arquitetural: um único serviço lógico pode abranger várias localizações físicas, pelo que o inventário de persistência deve seguir cada montagem e dependência, e não apenas um diretório do projeto.

Armazene as definições de implementação num sistema de controlo de versões depois de remover os segredos. Mantenha os segredos numa cópia de segurança encriptada ou num gestor de segredos com um procedimento de restauro documentado. Registe o proprietário e as permissões dos bind mounts. Durante um teste, verifique o acesso do serviço à base de dados e a leitura dos ficheiros multimédia antes de expor o acesso remoto ou aceitar novos carregamentos.

Os dados derivados podem ser reconstruídos, mas são operacionalmente importantes

As miniaturas, os vídeos codificados e alguns resultados de aprendizagem automática podem ser regenerados a partir das entradas autoritativas, dependendo da versão e dos registos conservados. Excluí-los pode reduzir o tamanho das cópias de segurança. A contrapartida é o tempo, a capacidade de computação, o calor e uma menor capacidade de resposta enquanto um servidor restaurado reconstrói uma grande biblioteca familiar.

Um guia de cópia de segurança independente distingue os dados essenciais de carregamentos, biblioteca e perfil das miniaturas e dos vídeos codificados que o Immich pode regenerar. Isto não torna os dados derivados irrelevantes; dá aos operadores a possibilidade de escolher entre o tamanho da cópia de segurança e o tempo necessário para recuperar uma navegação e uma reprodução totalmente preparadas.

Meça a taxa de reconstrução de uma amostra representativa antes de excluir dados derivados. Multiplique com cautela pela composição dos recursos afetados e inclua as escritas no armazenamento e a contenção em primeiro plano. Se o atraso resultante violar o objetivo de recuperação, proteja determinados caminhos de dados derivados ou mantenha capacidade de computação suplementar para o período de reconstrução.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Comprove a persistência através de um teste de destruição de contentores

Utilize um clone descartável da implementação, nunca a produção. Registe somas de verificação de alguns ficheiros originais, de um álbum de teste, de duas contas com diferentes níveis de acesso e de uma pesquisa conhecida. Remova apenas os contentores clonados, mantendo o armazenamento persistente declarado, e recrie a stack a partir da configuração e dos segredos guardados.

Um relato comunitário sobre persistência descreve o Immich a voltar ao processo de integração após reinícios, porque o diretório da base de dados no anfitrião pretendido permanecia vazio. É um exemplo elucidativo de por que razão um caminho configurado não prova que as escritas chegam ao destino; o estado observável tem de sobreviver à operação real do ciclo de vida que se afirma suportar.

Considere o teste aprovado apenas quando ambas as contas regressarem, a pertença aos álbuns coincidir, as somas de verificação dos ficheiros originais forem iguais e a pesquisa conhecida funcionar como esperado ou entrar num estado de reconstrução documentado. Qualquer reposição inexplicada identifica uma persistência em falta. Atualize o mapa de estado antes de confiar na automatização de cópias de segurança baseada nas mesmas suposições.