Como reverter o Immich em segurança após uma versão incompatível

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

How to Roll Back Immich Safely After an Incompatible Release - Zima Store Online

Reverta o Immich apenas depois de preservar o estado atual e determinar se a versão mais recente alterou a base de dados ou a configuração de uma forma que a imagem mais antiga não consiga ler.

Uma imagem de contentor pode ser substituída, mas o estado persistente pode já ter sido migrado. Se uma atualização começar mal, pare as atualizações automáticas e as novas gravações, registe ambas as versões, proteja a base de dados e os ficheiros multimédia atuais e, em seguida, escolha entre uma simples reversão da imagem e o restauro do ponto de recuperação anterior à atualização.

Congele a Atualização Falhada Antes que Altere Mais Estado

Desative as atualizações automáticas de imagens e impeça os clientes de adicionarem novas fotografias enquanto recolhe evidências. Registe as versões ou os digestos exatos das imagens antiga e nova do Immich, a versão do PostgreSQL, os ficheiros Compose e de ambiente, os caminhos de montagem e o primeiro erro de arranque ou migração.

O guia da ZimaSpace sobre os limites da reversão de contentores estabelece a distinção essencial: os volumes persistentes sobrevivem à substituição da imagem, mas isso só é seguro quando a aplicação mais antiga continua compatível com o estado que estes contêm.

Faça uma cópia de segurança nativa da base de dados do estado atual falhado, se a base de dados puder ser lida, e preserve separadamente a cópia anterior à atualização. Não substitua nenhuma delas com experiências repetidas. A cópia atual poderá ser necessária para avançar mais tarde, mesmo que o objetivo imediato seja regressar à versão mais antiga.

Determine se a Versão Ultrapassou um Limite de Migração da Base de Dados

Analise a primeira falha após a atualização e identifique se ocorre antes ou durante a migração da base de dados, depois da migração enquanto a aplicação arranca, ou apenas durante um fluxo de trabalho do utilizador. Este momento altera o plano de reversão, porque uma imagem mais antiga pode não compreender um esquema já alterado pela versão mais recente.

Um relatório recente do Immich em que o serviço falhou após um percurso de atualização ilustra por que motivo percursos de migração não suportados ou ignorados podem tornar pouco fiável uma simples troca de versão. Trate o tópico como um estudo de caso e confirme a sequência exata de migração das suas versões.

Se a aplicação mais recente nunca tocou na base de dados e a falha se limitar à compatibilidade da imagem ou do ambiente de execução, poderá ser suficiente reverter para uma imagem fixada. Se as migrações tiverem sido concluídas, parta do princípio de que a cópia de segurança da base de dados anterior à atualização é a opção mais segura para a imagem antiga, salvo se tiver provas explícitas de compatibilidade.

Restaure uma Base de Dados e um Ambiente de Execução Compatíveis em vez de Misturar Períodos

Crie o destino da reversão a partir da última versão da aplicação conhecida como funcional, da configuração de implementação compatível e do ponto de recuperação da base de dados anterior à alteração incompatível. Mantenha intacta a árvore de ficheiros multimédia, salvo se a versão tiver alterado ficheiros multimédia de forma documentada; não volte a copiar terabytes apenas porque a imagem da aplicação mudou.

A discussão sobre a reversão compatível com a base de dados explica o perigo geral de implementar código antigo sobre um esquema que já não compreende. Esse princípio é mais importante do que saber se o próprio contentor arranca com sucesso.

Inicie a instância revertida de forma isolada, para que os clientes móveis e as tarefas agendadas não possam escrever até a validação terminar. Se a versão antiga comunicar imediatamente erros de esquema, pare. Não force manualmente a reversão de migrações na única cópia da base de dados, salvo se tiver um procedimento de recuperação específico para a versão e previamente testado.

-15% OFF

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

Single board computer zimaboard2

Fixe a Imagem Exata Conhecida como Funcional e Reproduza a sua Configuração

Utilize uma versão específica ou uma referência de imagem imutável, em vez de uma etiqueta dinâmica. Restaure o ambiente correspondente, as dependências dos serviços, os mapeamentos de dispositivos, as redes, as portas e o destino do proxy inverso da última implementação conhecida como funcional. Uma reversão que altere silenciosamente várias camadas da infraestrutura cria um segundo incidente.

Preserve a imagem e a configuração novas que falharam juntamente com as notas da reversão. Isto permite uma recuperação controlada para a versão mais recente depois de compreender a incompatibilidade. Remover imediatamente todos os artefactos novos pode dificultar a comparação entre os estados falhado e funcional ou a reprodução da atualização num ambiente de teste.

Se o serviço antigo arrancar com o estado restaurado, analise os registos antes de ativar os clientes. Confirme que não existe uma tentativa inesperada de migração, uma inicialização de instalação nova, uma montagem de armazenamento em falta ou uma reescrita de permissões. Uma simples página de início de sessão não prova que a reversão está a utilizar os dados pretendidos.

Valide a Versão Antiga com o Acionador Original e Mantenha um Caminho para Avançar

Teste utilizadores representativos, ficheiros antigos e recentes, álbuns, partilha, pesquisa, um novo carregamento controlado, tarefas em segundo plano, a criação de uma cópia de segurança da base de dados e a rota do proxy inverso. Reinicie a pilha uma vez e confirme que as mesmas montagens e a base de dados regressam sem intervenção manual.

Mantenha os novos carregamentos suspensos até estas verificações passarem; depois, reabra o acesso e acompanhe o período normal de utilização. Preserve tanto a cópia de segurança anterior à atualização como a cópia do estado falhado da versão mais recente, para poder tentar novamente a atualização mais tarde numa cópia isolada, depois de compreender o problema de compatibilidade.

A reversão falhou se a versão antiga comunicar incompatibilidade de esquema, se faltarem dados conhecidos ou se as gravações forem parar a um caminho inesperado. Pare e restaure novamente o ponto de recuperação preservado, em vez de acumular reparações. Escale o problema com as versões exatas, os registos de migração, os carimbos temporais das cópias de segurança da base de dados, a diferença do Compose e o primeiro passo de verificação que falhou.