Quando Deve Reconstruir em Vez de Reparar uma Instalação do Immich?

Repare o Immich quando a falha estiver localizada e os dados persistentes estiverem comprovadamente intactos; reconstrua o ambiente de execução quando a deriva de configuração for generalizada, mas uma base de dados verificada, uma biblioteca multimédia, uma definição de implementação e uma cópia de reversão puderem recriar o serviço em segurança.

Reconstruir não é o mesmo que apagar tudo. Os contentores e as redes são descartáveis, enquanto a base de dados e os originais constituem o registo da biblioteca. Comece por classificar a integridade, o âmbito e a reprodutibilidade. Se a única base de dados ou a única cópia das fotografias puder estar danificada, preserve-a e pare—começar de novo com base nessa evidência pode transformar um incidente diagnosticável numa perda permanente.

Repare Quando a Falha Estiver Localizada e for Reversível

Prefira a reparação quando uma montagem, permissão, valor de ambiente, dependência, tarefa ou imagem fixada explicar a falha e o sistema tiver funcionado normalmente antes de uma alteração conhecida. Recolha os registos, faça uma cópia de segurança, altere apenas essa camada e repita o acionamento.

Uma reparação bem-sucedida restabelece a função afetada sem criar recursos em falta, erros na base de dados ou novos avisos no arranque. Se a mesma falha regressar após a recriação, a causa poderá estar na definição de implementação ou no estado persistente; nesse caso, substituir repetidamente o contentor já não constitui uma reparação baseada em evidências.

Uma discussão sobre corrupção da base de dados ilustra a rapidez com que as opções de recuperação se tornam arriscadas quando a base de dados é a camada suspeita. Use a lição de preservar antes de reparar, e não qualquer comando destrutivo não verificado.

Reconstrua o Ambiente de Execução Quando a Deriva for Incontrolável

Escolha uma reconstrução limpa do ambiente de execução quando as versões das imagens, as redes, os valores de ambiente, as montagens e as alterações manuais aos contentores já não puderem ser reproduzidos, mas os componentes persistentes verificados continuarem intactos. Construa ao lado da instância antiga, com versões fixadas e portas isoladas, em vez de a apagar.

Uma reconstrução também é adequada após o comprometimento do anfitrião ou quando uma instalação não suportada acumula alterações desconhecidas, pois restaurar entradas de implementação fidedignas cria um novo limite de auditoria. Altere as credenciais expostas e inspecione as cópias de segurança antes de as associar ao destino limpo.

A visão geral da ZimaSpace sobre a implementação de aplicações autoalojadas fornece um contexto mais amplo sobre a pilha de serviços; o Immich continua a exigir que a relação entre a base de dados e os conteúdos multimédia seja validada de forma independente.

Não Reconstrua Sobre Dados Persistentes Incertos

Pare quando a base de dados e a biblioteca de carregamentos puderem estar dessincronizadas, quando a única cópia de segurança não tiver sido testada ou quando não for clara a cópia autoritativa. Crie um instantâneo ou clone todos os candidatos e registe as marcas temporais antes de tentar recuperar a base de dados ou reconciliar os conteúdos multimédia.

Uma discussão sobre recuperação no Unraid demonstra a dificuldade operacional de restaurar o Immich quando os componentes das cópias de segurança e as versões não coincidem. A sua discussão sobre os limites do restauro apoia os testes em isolamento, em vez de substituir os caminhos de produção.

Se os originais estiverem intactos, mas a base de dados não puder ser recuperada, preserve ambos e documente as consequências antes de considerar uma nova importação da biblioteca. Essa é uma decisão de reconstrução de dados, não uma reparação de rotina, e poderá causar a perda de álbuns, estado de partilha, rostos, favoritos ou metadados históricos.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valide os Dados Persistentes num Destino Limpo

Restaure ou associe os dados persistentes copiados ao destino limpo e, em seguida, teste os utilizadores, as contagens da cronologia, os originais selecionados, os álbuns, a pesquisa, os dados faciais, as bibliotecas externas, um novo carregamento, as tarefas, e uma nova cópia de segurança da base de dados. Compare os resultados com as evidências preservadas da origem.

Compare as contagens de recursos da base de dados com ficheiros selecionados em várias datas, utilizadores e tipos de multimédia. Confirme os caminhos das bibliotecas externas, as tarefas derivadas e uma nova exportação da base de dados antes de atribuir o endereço de produção. Um simples ecrã de início de sessão não comprova a integridade dos dados.

Reinicie os contentores e o anfitrião duas vezes. Para passar, são necessárias montagens estáveis, uma configuração reproduzível, ausência de ciclos de migração e a carga de trabalho original. Se o destino limpo reproduzir o mesmo erro da base de dados ou dos ficheiros, a deriva do ambiente de execução não foi a causa e a recuperação especializada dos dados continua a ser a opção mais segura.

Faça a Mudança com um Limite de Reversão

Transfira o endereço de produção apenas depois de os testes isolados serem concluídos com sucesso e mantenha o sistema antigo desligado, mas recuperável, durante um período de observação acordado. Impeça que ambas as instâncias aceitem carregamentos ou executem simultaneamente a mesma automatização.

Após a mudança, execute o fluxo normal de carregamento, navegação, pesquisa, partilha e cópia de segurança da família. Uma passagem bem-sucedida preserva as contagens e os originais após o reinício seguinte; uma discrepância encaminha o tráfego de volta para o destino preservado sem substituir nenhum dos conjuntos de dados.

Regresse à reparação ou à recuperação especializada se o destino limpo reproduzir os mesmos erros da base de dados ou dos ficheiros; o ambiente de execução não foi a causa. Reverta a mudança se as contagens ou os originais forem diferentes. Escale o caso com as versões, somas de verificação, marcas temporais das cópias de segurança, o primeiro erro e o limite exato entre o estado copiado e o estado recém-criado.