Fluxo de integridade de uma biblioteca de fotografias autoalojada para originais e derivados

Uma cronologia fotográfica com bom aspeto não prova que os originais, a base de dados e as pré-visualizações geradas estejam todos intactos.

Uma galeria auto-hospedada pode continuar a apresentar miniaturas em cache depois de um original desaparecer, ou manter originais perfeitos enquanto os trabalhadores falham ao gerar novos derivados. Separe o estado necessário do estado reconstruível, verifique os bytes dos originais fora da aplicação, reconcilie os ficheiros com os registos da base de dados e regenere apenas um elemento de teste antes de testar um restauro isolado. Pare imediatamente quando os checksums mudarem, o armazenamento de origem ficar instável ou um trabalho escrever nos originais.

Defina o estado necessário e o estado regenerável

Faça o inventário dos originais, vídeos carregados, ficheiros auxiliares, base de dados, configuração, segredos, contas de utilizador, álbuns, edições e registos de partilha como estado necessário. Liste separadamente as miniaturas, os vídeos transcodificados, os embeddings faciais e os índices de pesquisa como derivados que só podem ser regenerados se os originais e o estado da aplicação permanecerem intactos.

Uma implementação auto-hospedada coloca normalmente a biblioteca num armazenamento de capacidade e a base de dados ou o caminho de trabalho num suporte mais rápido. Um guia prático sobre o armazenamento do Immich descreve a separação entre o armazenamento da biblioteca e o armazenamento do caminho de acesso frequente, razão pela qual uma verificação de integridade deve abranger todos os caminhos montados, e não apenas a pasta que os utilizadores consultam.

Registe a versão da aplicação, a imagem do contentor, as definições de montagem, o estado do esquema da base de dados, o espaço livre no armazenamento e o estado da fila de trabalhos. Pare se algum caminho necessário estiver em falta ou inesperadamente apenas de leitura; um trabalho de regeneração não deve começar enquanto a fonte de verdade for incerta.

Prove os bytes dos originais independentemente da galeria

Gere ou reutilize um manifesto de checksums fidedigno para os originais e compare-o com a árvore atual em modo apenas de leitura. Reconcilie a contagem de ficheiros, o total de bytes, os ficheiros ilegíveis, os objetos inesperados com zero bytes e os caminhos órfãos. Abra, fora da galeria, uma amostra estratificada que contenha JPEG, HEIC, RAW, vídeo, anos antigos e carregamentos recentes.

Não deduza o estado dos originais a partir das miniaturas visíveis. Uma galeria pode continuar a apresentar derivados em cache depois de um original se perder, e um original saudável pode continuar oculto quando o pipeline de pré-visualização falha. A distinção entre originais e derivados regeneráveis faz da verificação direta dos ficheiros o primeiro controlo de segurança.

Se os hashes mudarem ou as leituras falharem, pause a importação, a limpeza e a regeneração de derivados. Restaure ou crie uma imagem do armazenamento com falhas antes de alterar os registos da base de dados. A fase é aprovada quando os originais necessários são legíveis e as diferenças inexplicadas têm um responsável, uma razão e uma ação de recuperação.

Reconcilie registos, caminhos e trabalhos de derivados

Compare os registos de recursos da base de dados com os caminhos do sistema de ficheiros nas duas direções: registos sem ficheiros e ficheiros sem registos. Verifique UID e GID, montagens vinculadas, raízes de bibliotecas externas, distinção entre maiúsculas e minúsculas e diretórios renomeados antes de declarar que os recursos estão em falta. Preserve as listas de órfãos em vez de eliminar automaticamente qualquer dos lados.

Em seguida, faça uma amostragem dos trabalhos de miniaturas, pré-visualizações, transcodificação, extração de metadados e aprendizagem automática. Um artigo independente de resolução de problemas sobre originais intactos com derivados falhados ilustra como carregamentos intactos podem coexistir com mosaicos cinzentos quando o armazenamento, os trabalhadores ou os caminhos dos derivados falham.

Regenere apenas um derivado de teste depois de o original e a linha da base de dados coincidirem. Um resultado aprovado é uma nova pré-visualização com o proprietário, o caminho e a resposta do cliente esperados; um resultado falhado deve continuar limitado aos registos do trabalhador, ao descodificador, ao armazenamento de saída ou ao estado da fila. Nunca inicie uma reconstrução de toda a biblioteca até que esse elemento de teste continue correto após um reinício.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Restaure a biblioteca completa num destino isolado

Restaure os originais, a base de dados, a configuração, os segredos e os ficheiros auxiliares necessários para um ambiente descartável com portas e caminhos diferentes. Inicie as dependências pela ordem correta, verifique os utilizadores e os álbuns e permita apenas os trabalhos de derivados necessários para o conjunto de amostra. Não aponte a instância de teste para armazenamento de produção com permissões de escrita.

Teste o início de sessão, a cronologia, a pesquisa, a pertença a álbuns, a transferência dos bytes originais, uma edição, uma partilha e a reprodução de um vídeo. Compare os hashes dos ficheiros transferidos com o manifesto e verifique se um segundo reinício não perde os mapeamentos de caminhos nem recria o estado necessário com o proprietário errado.

Declare a integridade comprovada apenas quando a biblioteca ativa e o restauro isolado concordarem quanto ao estado necessário e os derivados de teste forem reconstruídos a partir dos originais. Escale as discrepâncias entre a base de dados e os ficheiros, os erros crescentes de checksum ou os trabalhos que alterem os originais; conserve os manifestos e os registos para que a reparação não se transforme numa reimportação sem documentação.