Vilka roller har beständiga data i Home Assistant, och varför är de viktiga?

Home Assistants beständiga data blir enklare att hantera när den delas upp efter roll i stället för att behandlas som en enda odifferentierad ”konfiguration”. Viss status definierar det smarta hemmets identitet och beteende, viss lagrar historiska observationer, viss innehåller autentiseringsuppgifter och viss finns endast för att återskapa runtime-miljön runt Home Assistant.

Dessa roller är viktiga eftersom de har olika återställningsvärde. Att förlora en månads historik är inte samma sak som att förlora entitetsregistret, och att återskapa en Docker-avbildning är inte samma sak som att återskapa enhetsmappningar, hemligheter eller den konfiguration som ger hushållet dess automatiseringar.

Konfiguration och registerstatus definierar installationen

Det beständiga konfigurationsträdet innehåller YAML, UI-hanterad lagring, integrationskonfiguration, instrumentpaneler, hjälpare, enhets- och entitetsregister, anpassade komponenter och andra filer som gör en Home Assistant-instans annorlunda än en ren installation.

Beständighet för containrar beror på att status lagras utanför containerns skrivbara lager. Dockers aktuella lagringsvägledning förklarar att volymer och bind mounts bevarar programdata oberoende av containerns livscykel. Avbildningen kan återskapas; den hushållsspecifika statusen kan inte förväntas återkomma.

Den här rollen kräver försiktig säkerhetskopiering, kontrollerad migrering och en känd återställningsväg. Den bör inte dela rensningspolicy med cache eller tillfälliga containerlager.

Recorder-historik är värdefull data, men inte samma sak som konfiguration

Recorder lagrar historiska tillstånd, händelser och statistik som används av Historik, Loggbok, instrumentpaneler och analyser. Dessa data kan vara viktiga, särskilt för energi, miljötrender eller felsökning, men Home Assistant kan fortfarande representera aktuellt tillstånd utan att behålla obegränsad råhistorik.

Att skilja historik från identitet förändrar återställningsbesluten. En skadad eller överdimensionerad Recorder-databas kan motivera reparation, återställning eller till och med återskapande av historiken utan att friska automatiseringar och integrationskonfigurationer kasseras.

Historiska data behöver en egen livscykel: samplingsfrekvens, lagringstid, sammanställningar, index och generationer av säkerhetskopior avgör lagringstillväxten oberoende av antalet automatiseringsregler. Hantera dessa lagringsbeslut separat från den konfigurations- och registerstatus som definierar installationen.

Hemligheter och återställningsnycklar har ett annat felhanteringskrav

Autentiseringsuppgifter, token, certifikat, krypteringsnycklar och material för nödåterställning kan vara små i byte men ha högt återställningsvärde. En säkerhetskopia som inte kan dekrypteras, eller en återställd integration som saknar giltiga autentiseringsuppgifter, kan göra systemet delvis obrukbart.

Home Assistants strategi för säkerhetskopiering rekommenderar uttryckligen att krypterade återställningskopior förvaras på olika medier och på en plats utanför den egna lokalen. Skyddet är bara användbart om nyckeln som krävs för att återställa säkerhetskopian också finns tillgänglig efter en förlust av värddatorn.

Lägg inte alla hemligheter i ett offentligt Git-arkiv bara för att konfigurationen versionshanteras. Lagra hemligt material med en skyddad metod och dokumentera varifrån det hämtas vid återställning.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Runtime-definitionen återskapar miljön runt statusen

Ett återställt konfigurationsträd kan ändå misslyckas om den nya värddatorn inte återskapar USB-radions mappning, nätverksläge, portar, värdsökvägar, databastjänst, MQTT-mäklare, miljövariabler, tidszon eller behörigheter som den ursprungliga driftsättningen förväntade sig.

Vägledningen för Home Assistant Container skiljer uppdateringar från beständig status och förutsätter att runtime-miljön återskapas från kända Docker-parametrar. Det aktuella Container-arbetsflödet håller säkerhetskopiering och byte av avbildning som separata åtgärder, vilket är samma åtskillnad som en återställningsplan bör bevara.

Spara Compose-filer eller motsvarande driftsättningsdefinitioner tillsammans med dokumentationen för externa tjänster. Runtime-konfigurationen är inte Home Assistants databas, men den ingår i att återskapa en fungerande tjänst.

Säkerhetskopior är återställningskopior, inte ytterligare en aktiv dataroll

En säkerhetskopia bör överleva det fel som den är avsedd att återställa från. Om alla säkerhetskopior finns på samma system-SSD som den aktiva konfigurationen och Recorder-databasen kan ett enda lagringsfel ta bort alla tre rollerna samtidigt.

Återställningskopior bör också överleva en förlust av Home Assistant-värddatorn. 3-2-1-modellen för säkerhetskopiering behåller flera kopior på olika medier, med minst en kopia på annan plats. För krypterade Home Assistant-säkerhetskopior måste nödåterställningskitet eller motsvarande nyckel på samma sätt finnas tillgängligt utanför det havererade systemet.

• Konfiguration och register: återställ eller reparera försiktigt eftersom de definierar identitet och automatiseringsbeteende.
• Recorder och statistik: reparera, återställ eller bygg om separat när historiken är det enda skadade lagret.
• Hemligheter och nycklar: återställ från en skyddad lagring utanför den havererade värddatorn.
• Runtime-definition: återskapa monteringar, enheter, nätverk och tjänsteberoenden.
• Säkerhetskopior: förvara återställningskopior utanför den aktiva felzonen.

ZimaSpaces exempel på Home Assistant-driftsättning är användbart som sammanhang för denna uppdelning: serverplattformen kan ändras medan programstatusen och återställningsansvaret förblir logiskt separerade.

Rollerna för beständiga data är viktiga eftersom de gör det möjligt att reparera det minsta felaktiga lagret. Ett databasproblem behöver inte bli en ren installation, och en containeruppdatering behöver inte leda till förlorad konfiguration.