Quais são as funções dos dados persistentes do Home Assistant e porque são importantes?

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.

What Are Home Assistant Persistent Data Roles, and Why Do They Matter?

Os dados persistentes do Home Assistant são mais fáceis de gerir quando divididos por função, em vez de serem tratados como uma “configuração” indiferenciada. Alguns estados definem a identidade e o comportamento da casa inteligente, outros armazenam observações históricas, alguns contêm credenciais e outros existem apenas para reconstruir o ambiente de execução do Home Assistant.

Estas funções são importantes porque têm diferentes valores de recuperação. Perder um mês de histórico não é o mesmo que perder o registo de entidades, e recriar uma imagem Docker não é o mesmo que recriar mapeamentos de dispositivos, segredos ou a configuração que fornece à casa as suas automações.

A Configuração e o Estado dos Registos Definem a Instalação

A árvore de configuração persistente contém YAML, armazenamento gerido pela interface, configuração de integrações, painéis, auxiliares, registos de dispositivos e entidades, componentes personalizados e outros ficheiros que distinguem uma instância do Home Assistant de uma instalação limpa.

A persistência dos contentores depende do armazenamento do estado fora da camada de escrita do contentor. A orientação atual de armazenamento do Docker explica que os volumes e os bind mounts mantêm os dados da aplicação persistentes, independentemente do ciclo de vida do contentor. A imagem pode ser recriada; não se pode presumir que o estado específico da casa reapareça.

Esta função requer cópias de segurança conservadoras, migração controlada e um processo de restauro conhecido. Não deve partilhar uma política de limpeza com a cache ou com camadas descartáveis de contentores.

O Histórico do Recorder É um Dado Valioso, mas Não É o Mesmo que a Configuração

O Recorder armazena estados históricos, eventos e estatísticas utilizados pelo Histórico, Livro de registos, painéis e análises. Estes dados podem ser importantes, especialmente para energia, tendências ambientais ou resolução de problemas, mas o Home Assistant continua a conseguir representar o estado atual sem manter um histórico bruto ilimitado.

Separar o histórico da identidade altera as decisões de recuperação. Uma base de dados do Recorder corrompida ou demasiado grande pode justificar a reparação, o restauro ou até a recriação do histórico, sem eliminar automações saudáveis nem a configuração das integrações.

Os dados históricos precisam do seu próprio ciclo de vida: a frequência de amostragem, a retenção, os agregados, os índices e as gerações de cópias de segurança determinam o crescimento do armazenamento, independentemente do número de regras de automação. Trate essas decisões de retenção separadamente do estado de configuração e dos registos que definem a instalação.

Os Segredos e as Chaves de Recuperação Têm um Contrato de Falha Diferente

Credenciais, tokens, certificados, chaves de encriptação e materiais de emergência para cópias de segurança podem ocupar poucos bytes, mas ter um elevado valor de recuperação. Uma cópia de segurança que não possa ser desencriptada ou uma integração restaurada sem credenciais válidas pode deixar o sistema parcialmente inutilizável.

A estratégia de cópia de segurança do Home Assistant recomenda explicitamente manter cópias de recuperação encriptadas em diferentes suportes e numa localização externa. Esta proteção só é útil se a chave necessária para restaurar a cópia de segurança também estiver disponível após a perda do anfitrião.

Não coloque todos os segredos num repositório Git público apenas porque a configuração é versionada. Armazene o material secreto através de um mecanismo protegido e documente o local onde pode ser recuperado.

-15% OFF

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

Single board computer zimaboard2

A Definição do Ambiente de Execução Reconstrói o Ambiente em Torno do Estado

Uma árvore de configuração restaurada pode continuar a falhar se o anfitrião de substituição não reproduzir o mapeamento do rádio USB, o modo de rede, as portas, os caminhos do anfitrião, o serviço de base de dados, o broker MQTT, as variáveis de ambiente, o fuso horário ou as permissões esperadas pela implementação original.

A documentação do Home Assistant Container separa as atualizações do estado persistente e pressupõe que o ambiente de execução seja recriado a partir de parâmetros Docker conhecidos. O atual fluxo de trabalho do Container mantém a cópia de segurança e a substituição da imagem como operações distintas, que é a mesma separação que um plano de recuperação deve preservar.

Guarde os ficheiros Compose ou definições de implementação equivalentes juntamente com a documentação dos serviços externos. A configuração do ambiente de execução não é a base de dados do Home Assistant, mas faz parte da reprodução de um serviço funcional.

As Cópias de Segurança São Cópias de Recuperação, Não Outra Função de Dados Ativos

Uma cópia de segurança deve sobreviver à falha da qual se destina a recuperar. Se todas as cópias de segurança estiverem no mesmo SSD do sistema que a configuração ativa e a base de dados do Recorder, uma única falha de armazenamento pode eliminar as três funções ao mesmo tempo.

As cópias de recuperação também devem sobreviver à perda do anfitrião do Home Assistant. O modelo de cópia de segurança 3-2-1 mantém várias cópias em diferentes suportes, com pelo menos uma cópia fora do local. No caso de cópias de segurança encriptadas do Home Assistant, o kit de emergência ou a chave correspondente também deve permanecer disponível fora do sistema que falhou.

Configuração e registos: restaurar ou reparar cuidadosamente, pois definem a identidade e o comportamento das automações.
Recorder e estatísticas: reparar, restaurar ou reconstruir de forma independente quando o histórico for a única camada danificada.
Segredos e chaves: recuperar a partir de um armazenamento protegido fora do anfitrião que falhou.
Definição do ambiente de execução: recriar montagens, dispositivos, rede e dependências de serviços.
Cópias de segurança: manter cópias de recuperação fora do domínio de falha ativo.

O exemplo de implementação do Home Assistant no ZimaSpace é um contexto útil para esta separação: a plataforma de servidor pode mudar, enquanto o estado da aplicação e as responsabilidades de recuperação permanecem logicamente distintos.

As funções dos dados persistentes são importantes porque permitem reparar a camada afetada mais pequena. Um problema na base de dados não tem de se transformar numa instalação limpa, e uma atualização do contentor não tem de resultar na perda da configuração.