Como restaurar o Home Assistant após uma atualização do contentor falhada

Uma atualização falhada do contentor do Home Assistant deve normalmente ser tratada como um problema de substituição do runtime, e não como motivo para criar uma nova instalação. Se o diretório /config montado a partir do anfitrião estiver intacto, o caminho de recuperação mais seguro consiste em preservar esse estado, verificar o mapeamento do volume, iniciar uma imagem conhecida como funcional e testar a instalação existente antes de restaurar uma cópia de segurança mais antiga.

A medida perigosa é permitir que um novo contentor seja iniciado com um caminho do anfitrião incorreto ou vazio. O Home Assistant pode então apresentar o processo de configuração inicial como se a configuração tivesse desaparecido, quando o estado original continua a existir noutro local do disco. Impeça primeiro novas alterações, identifique o diretório de configuração autoritativo e não elimine o contentor ou diretório antigo até a instância recuperada passar nos testes.

Pare as novas gravações e encontre o caminho real de /config

Pare o contentor que falhou e inspecione a definição de runtime que o criou. Confirme qual o diretório do anfitrião ou volume nomeado que está mapeado para /config e, em seguida, inspecione essa localização à procura dos seus ficheiros YAML, de .storage, dos componentes personalizados, dos segredos e da base de dados.

Num caso de recuperação da comunidade após uma atualização do Docker, descobriu-se que uma instância do Home Assistant “completamente nova” era, na realidade, causada por o contentor apontar para a pasta de configuração errada. Os dados persistentes não tinham sido apagados; o runtime substituto simplesmente não os estava a montar corretamente.

Copie ou crie um instantâneo do diretório de configuração atual antes de alterar permissões, caminhos ou ficheiros da base de dados. Mesmo um estado parcialmente danificado é uma evidência valiosa e pode conter automatizações ou credenciais mais recentes do que a última cópia de segurança.

Recrie o runtime sem recriar a instalação

Utilize o mesmo modo de rede, fuso horário, mapeamentos de dispositivos, acesso a rádios USB, privilégios ou capacidades e montagem do /config do anfitrião que o contentor funcional utilizava antes da atualização. A imagem pode ser substituída; são estas entradas do runtime e os dados persistentes que determinam se o serviço regressa como a mesma instância do Home Assistant.

A persistência do contentor depende da montagem do anfitrião, e não do sistema de ficheiros do contentor. Um exemplo de contentor do Home Assistant monta um volume persistente do anfitrião diretamente em /config, pelo que recriar o runtime não recria a configuração da casa. Se esse mapeamento mudar durante uma atualização, um contentor substituto pode parecer novo, enquanto o estado original continua a existir noutro local.

Não copie o sistema de ficheiros do contentor antigo para a nova imagem. Recrie a implementação a partir de uma definição documentada do Compose ou do comando de execução e volte a ligar explicitamente o estado persistente.

Faça o downgrade da imagem antes de restaurar um estado mais antigo

Se a montagem da configuração estiver correta, mas a nova versão do Home Assistant não iniciar ou interromper uma integração crítica, teste a imagem anterior conhecida como funcional com o mesmo /config preservado. Isto permite distinguir entre “o novo runtime é incompatível com o estado atual” e “o próprio estado está danificado”.

O fluxo de trabalho atual do Home Assistant Container separa explicitamente a imagem do estado persistente: faça primeiro uma cópia de segurança, obtenha a imagem pretendida, recrie o contentor e utilize uma etiqueta específica de uma imagem mais antiga quando for necessário fazer downgrade. Esse é o limite de recuperação a preservar: substitua o runtime mantendo intacto o caminho de configuração autoritativo.

Ao fazer o rollback, lembre-se de que algumas atualizações migram estruturas de dados. Utilize uma cópia de segurança criada antes de uma migração se a versão mais antiga não conseguir ler em segurança um estado já atualizado pela versão mais recente. Não alterne repetidamente entre versões utilizando a única cópia dos dados persistentes.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Restaure uma cópia de segurança apenas quando o estado atual não for fiável

Utilize uma cópia de segurança quando a configuração persistente estiver em falta, corrompida, parcialmente substituída ou já não for compatível com a versão que consegue executar em segurança. Sempre que possível, restaure-a num destino isolado ou limpo, para poder comparar o estado recuperado com a cópia danificada.

Guarde a palavra-passe de encriptação ou o kit de emergência necessário para abrir a cópia de segurança fora do anfitrião que falhou. Uma cópia de segurança que exista apenas no mesmo disco ou que não possa ser desencriptada não oferece um caminho de recuperação.

O exemplo da ZimaSpace de separar a recuperação do Home Assistant do próprio anfitrião de armazenamento reforça a mesma regra: o estado da aplicação precisa de um caminho de restauro independente, e não apenas de um disco ativo espelhado.

Valide o contentor recuperado antes de eliminar qualquer coisa

• Confirme que os utilizadores, painéis, integrações, automatizações, auxiliares e áreas esperados estão presentes.
• Verifique um caminho de dispositivo local e um caminho baseado em rádio se utilizar Zigbee, Z-Wave ou Bluetooth.
• Verifique se existem erros da base de dados ou de migração no Recorder.
• Reinicie o contentor recuperado e confirme que o mesmo estado regressa.
• Mantenha a etiqueta da imagem antiga, uma cópia da configuração e a última cópia de segurança conhecida como funcional até este segundo arranque passar.

Se a imagem antiga funcionar com a configuração original, a atualização falhada foi sobretudo um problema de runtime/versão. Se todas as imagens falharem com o mesmo estado, avance para a reparação da configuração ou para o restauro de uma cópia de segurança. Se um contentor limpo funcionar apenas com um /config vazio, não aceite a nova configuração como “resolvida” até compreender o que, no estado persistente, está a impedir a recuperação.

Perguntas frequentes

Devo eliminar o contentor do Home Assistant que falhou antes de investigar?

Não. Pare-o primeiro e preserve a respetiva definição de runtime e o caminho da configuração montada. Pode criar um contentor substituto sem eliminar o que falhou, mantendo assim disponíveis as informações necessárias para o rollback enquanto testa o novo runtime.

Porque é que o Home Assistant apresenta o processo de configuração inicial depois de uma atualização?

A razão mais comum, específica dos contentores, é que o runtime substituto não está a ver o caminho original de /config. Verifique a montagem do anfitrião antes de presumir que a configuração foi apagada ou de restaurar uma cópia de segurança mais antiga sobre um estado mais recente.