Porque é que o Home Assistant perde o acesso aos dados persistentes após a recriação da stack?

Recriar uma stack Docker ou Compose do Home Assistant não deverá apagar a configuração quando os mesmos dados persistentes de /config são montados novamente. Quando surge o processo de integração inicial ou parecem faltar integrações após a recriação, a primeira hipótese deverá ser que o novo contentor está a ver uma perspetiva de armazenamento diferente — e não que o Home Assistant apagou o estado da casa.

Verifique a montagem efetiva, o caminho no anfitrião, o volume nomeado, os ficheiros ocultos e as permissões antes de restaurar uma cópia de segurança antiga. Um diretório vazio e incorreto pode parecer exatamente uma perda de configuração, enquanto os dados originais permanecem intactos noutro local do anfitrião.

Verifique o que está realmente montado em /config

Inspecione o contentor em execução e confirme a origem da montagem associada a /config. Compare-a com o ficheiro Compose antigo ou com o registo da implementação, em vez de confiar num nome de pasta familiar.

As montagens bind do Docker substituem a vista que o contentor tem do diretório de destino, e a atual documentação sobre montagens bind indica que montar um diretório do anfitrião sobre um caminho de contentor não vazio oculta os ficheiros que já lá se encontravam. Assim, um caminho de origem vazio ou incorreto faz com que o Home Assistant veja um /config vazio.

Não execute o processo de integração inicial nem comece a criar novas integrações até confirmar a montagem. Novas gravações no diretório incorreto tornarão a recuperação posterior mais confusa.

Distingua montagens bind de volumes nomeados

Uma stack Compose pode utilizar um caminho explícito no anfitrião ou um volume nomeado gerido pelo Docker. Recriar um projeto com um nome de projeto, nome de volume ou caminho diferente pode criar um novo armazenamento persistente vazio, enquanto o volume antigo continua a existir.

Um guia atual sobre volumes Docker explica que os volumes nomeados armazenam dados independentemente de contentores individuais e podem ser novamente associados depois de substituir um contentor. Por isso, remover um contentor é diferente de remover ou substituir o respetivo armazenamento persistente.

Liste os volumes antigos e novos, inspecione os respetivos pontos de montagem através do Docker e compare as datas de criação e os conteúdos. Evite comandos de limpeza até saber qual é o volume que contém o estado autoritativo do Home Assistant.

Os ficheiros ocultos podem fazer com que uma cópia pareça completa quando não está

O Home Assistant armazena dados importantes geridos pela interface em caminhos ocultos, como .storage. Uma cópia através da shell utilizando um padrão como *, ou um gestor de ficheiros que oculte ficheiros ocultos, pode mover ficheiros YAML e deixar silenciosamente para trás dados essenciais de registos e integrações.

Um caso de migração de Docker para Compose reproduzido em 2025 demonstrou exatamente este problema: uma operação de cópia ignorou ou tratou incorretamente o estado oculto do Home Assistant, e a migração só estabilizou depois de a árvore de configuração completa e os metadados serem copiados corretamente.

Compare listagens de diretórios que incluam ficheiros ocultos e verifique o proprietário, as marcas temporais e a presença dos diretórios ocultos esperados antes de concluir que os próprios dados estão danificados.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique as permissões antes de copiar novamente os dados

Mesmo o diretório correto pode parecer inutilizável quando o contentor recriado não tem permissão para o ler ou escrever nele. Isto é comum depois de mover os dados para um novo sistema de ficheiros, alterar o modo do Docker, restaurar a partir de outro anfitrião ou alterar os mapeamentos de UID/GID.

Um guia de resolução de problemas do Docker Engine verificado em 2026 reduz estas falhas ao caminho real no anfitrião, UID/GID do contentor, acesso ao diretório-pai, modo de montagem e limites de segurança. Uma montagem só de leitura ou uma incompatibilidade de propriedade pode impedir o Home Assistant de atualizar o estado, mesmo quando os ficheiros estão visíveis.

Corrija o problema específico de propriedade ou de montagem, em vez de aplicar permissões de escrita para todos a toda a árvore de configuração.

Recrie a stack apenas depois de confirmar o caminho persistente

Utilize a definição Compose exata que sabe estar correta, a etiqueta da imagem, o modo de rede, os dispositivos e a origem de /config. Inicie o Home Assistant e confirme que os utilizadores, painéis, integrações, automatizações e auxiliares esperados regressaram antes de permitir migrações ou novas alterações de configuração.

O fluxo de recuperação de um único contentor da ZimaSpace aplica a mesma regra: inspecione as montagens efetivas e volte a ligar dependências funcionais antes de restaurar ou substituir partes não relacionadas de uma stack.

Se os dados autoritativos estiverem realmente em falta, avance para a restauração a partir da cópia de segurança. Se estiverem presentes, mas o novo contentor não conseguir vê-los ou modificá-los, o problema pertence ao mapeamento do armazenamento ou aos limites de permissões, e não à própria configuração do Home Assistant.