Como verificar uma restauração do Immich antes de desativar o servidor antigo

Não desative o servidor Immich antigo apenas porque o novo painel carrega e as fotografias aparecem. Desative-o apenas depois de o sistema restaurado comprovar utilizadores, álbuns, pessoas, pesquisa, originais selecionados, novos carregamentos, tarefas em segundo plano, reinícios e uma cópia de segurança nova, mantendo o anfitrião antigo disponível como destino de reversão.

Mantenha o servidor antigo desligado, mas inalterado, durante a validação, para que duas instâncias não aceitem carregamentos contra estados divergentes. Atribua primeiro ao anfitrião restaurado um endereço de teste controlado, registe uma linha de base do sistema antigo e compare os mesmos fluxos de trabalho domésticos, em vez de confiar na impressão visual de que a cronologia parece completa.

Mantenha o servidor antigo intacto enquanto estabelece uma linha de base da restauração

Antes da mudança, registe o número de utilizadores, o número de recursos, alguns álbuns representativos, pessoas identificadas, favoritos, itens partilhados, caminhos de bibliotecas externas e vários originais de exemplo de diferentes datas e utilizadores. Registe também as versões antigas do Immich e do PostgreSQL, bem como os artefactos de cópia de segurança utilizados na restauração. As verificações de integridade das pastas ou do armazenamento são úteis como critérios de validação, mas não substituem a verificação ao nível das relações.

O modelo de recuperação da ZimaSpace para restaurar uma biblioteca de fotografias pesquisável trata os originais, o estado do catálogo/base de dados e a configuração que define os caminhos como uma única unidade de recuperação. Essa é a linha de base correta, porque ficheiros de imagem isolados não conseguem provar que a pertença a álbuns, a propriedade, as pessoas e as relações de pesquisa sobreviveram.

Não apague os discos antigos, não reutilize permanentemente o respetivo IP nem elimine ainda a última cópia de segurança conhecida como válida. O objetivo da verificação deve ser reversível: se faltar uma relação crítica, precisa do estado antigo para determinar se o problema veio da cópia de segurança, do método de restauração, do mapeamento de caminhos ou do novo ambiente de execução.

Verifique as relações, não apenas a visibilidade das fotografias

Inicie sessão com mais do que um utilizador esperado e confirme que cada conta vê os recursos e as partilhas corretos. Abra álbuns conhecidos, pessoas identificadas, favoritos, memórias ou outras relações específicas do agregado familiar que seriam difíceis de reconstruir apenas a partir dos ficheiros. Compare um pequeno conjunto com a linha de base registada no servidor antigo.

Uma discussão sobre uma migração do Immich relacionada com álbuns em falta após uma restauração do PostgreSQL demonstra por que razão isto é importante: as fotografias podiam permanecer enquanto o estado dos álbuns desaparecia, e uma nova exportação da base de dados alterou posteriormente o resultado. Considere isto como evidência de que um início de sessão bem-sucedido ou uma cronologia visível não constituem um teste completo da restauração.

Pesquise vários recursos conhecidos utilizando metadados e quaisquer funcionalidades visuais ou de pessoas ativadas. Se os originais estiverem presentes, mas faltarem relações ou resultados de pesquisa, determine se o estado relevante deveria ter sido restaurado ou se está a ser regenerado intencionalmente. Não desative o servidor antigo enquanto essa distinção não estiver esclarecida.

Teste os caminhos de leitura, escrita, dependências e reinício

Abra diretamente fotografias e vídeos antigos a partir do armazenamento restaurado e, em seguida, carregue um novo recurso descartável a partir de um cliente móvel ou Web. Confirme que o original é escrito no caminho pretendido, que aparece para o utilizador correto e que as tarefas em segundo plano avançam. Teste as bibliotecas externas e o acesso remoto apenas depois de o caminho local de leitura/escrita estar estável.

Os testes de restauração devem validar a aplicação depois de os bytes serem copiados. Um guia atual de testes de recuperação de desastre recomenda uma validação ao nível da aplicação que inclua bases de dados, permissões, ligações de rede e serviços, em vez de terminar com uma tarefa de cópia de segurança ou restauração concluída. Reinicie a pilha do Immich duas vezes e reinicie uma vez o novo anfitrião. Após cada ciclo, confirme que as mesmas montagens, utilizadores, recursos de exemplo, base de dados, proxy ou endpoint local e comportamento das tarefas regressam. Um serviço que só funciona até ao primeiro reinício do anfitrião não concluiu a migração.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Crie uma cópia de segurança nova antes de fechar a janela de reversão

Crie uma nova cópia de segurança consistente com a base de dados e proteja o âmbito de meios/configuração exigido pelo modelo de recuperação. Restaure pelo menos um pequeno destino de validação ou inspecione a cópia de segurança utilizando o mesmo processo usado antes da mudança. Um servidor restaurado que não consiga produzir a sua própria cópia de segurança recuperável não deve tornar-se a única cópia de produção.

Submeta o novo anfitrião a um período de observação definido que inclua carregamentos normais a partir do telemóvel, navegação, pesquisa, processamento em segundo plano, cópia de segurança agendada e pelo menos um ciclo noturno. Mantenha o anfitrião antigo desligado para que não possa dividir o estado, mas conserve-o inalterado até que o novo sistema atravesse esses eventos sem diferenças inexplicadas.

A decisão de avançar exige relações críticas correspondentes, originais legíveis, novas escritas bem-sucedidas, reinícios estáveis e uma cópia de segurança nova e verificada.

Se os utilizadores desaparecerem, os números divergirem significativamente, os erros de caminho voltarem a surgir ou a base de dados comunicar problemas de consistência, desligue a nova instância e preserve ambos os lados antes de investigar. Só então deverá apagar ou reutilizar o servidor antigo.