Wat zijn de rollen van persistente gegevens in Home Assistant en waarom zijn ze belangrijk?

Home Assistant-gegevens die persistent moeten worden opgeslagen, zijn eenvoudiger te beheren wanneer ze op basis van hun rol worden verdeeld in plaats van als één ongedifferentieerde “configuratie” te worden behandeld. Sommige statusgegevens bepalen de identiteit en het gedrag van het slimme huis, andere slaan historische observaties op, sommige bevatten inloggegevens en weer andere bestaan alleen om de runtime rond Home Assistant opnieuw op te bouwen.

Die rollen zijn belangrijk omdat ze verschillende herstelwaarden hebben. Een maand geschiedenis verliezen is niet hetzelfde als het entiteitenregister verliezen, en een Docker-image opnieuw maken is niet hetzelfde als apparaatkoppelingen, geheimen of de configuratie die de automatiseringen van het huishouden aanstuurt opnieuw maken.

Configuratie- en registerstatus bepalen de installatie

De persistente configuratiestructuur bevat YAML, door de interface beheerde opslag, integratieconfiguratie, dashboards, helpers, apparaat- en entiteitenregisters, aangepaste componenten en andere bestanden die één Home Assistant-instantie onderscheiden van een schone installatie.

Containerpersistentie hangt af van het opslaan van status buiten de beschrijfbare containerlaag. De actuele opslagrichtlijnen van Docker leggen uit dat volumes en bind mounts applicatiegegevens onafhankelijk van de levenscyclus van de container persistent maken. De image kan opnieuw worden gemaakt; er kan niet van worden uitgegaan dat de huishoudspecifieke status vanzelf terugkomt.

Deze rol vereist voorzichtige back-ups, gecontroleerde migratie en een bekend herstelpad. De rol mag geen opschoonbeleid delen met cache- of wegwerpcontainerlagen.

Recorder-geschiedenis is waardevolle data, maar niet hetzelfde als configuratie

Recorder slaat historische statussen, gebeurtenissen en statistieken op die worden gebruikt voor Geschiedenis, Logboek, dashboards en analyses. Deze gegevens kunnen belangrijk zijn, vooral voor energie, omgevingstrends of probleemoplossing, maar Home Assistant kan de huidige status ook weergeven zonder onbeperkt ruwe geschiedenis te bewaren.

Het scheiden van geschiedenis en identiteit verandert herstelbeslissingen. Een beschadigde of te grote Recorder-database kan aanleiding geven tot reparatie, herstel of zelfs het opnieuw opbouwen van de geschiedenis, zonder gezonde automatiseringen en integratieconfiguratie te verwijderen.

Historische gegevens hebben een eigen levenscyclus nodig: bemonsteringsfrequentie, bewaartermijn, aggregaties, indexen en back-upgeneraties bepalen de opslaggroei onafhankelijk van het aantal automatiseringsregels. Behandel deze bewaarkeuzes afzonderlijk van de configuratie- en registerstatus die de installatie bepaalt.

Geheimen en herstelsleutels hebben een ander foutmodel

Inloggegevens, tokens, certificaten, encryptiesleutels en materiaal voor noodherstel nemen mogelijk weinig bytes in beslag, maar hebben een hoge herstelwaarde. Een back-up die niet kan worden ontsleuteld, of een herstelde integratie zonder geldige inloggegevens, kan het systeem gedeeltelijk onbruikbaar maken.

De back-upstrategie van Home Assistant raadt expliciet aan versleutelde herstelkopieën op verschillende media en op een externe locatie te bewaren. Die bescherming is alleen nuttig als de sleutel die nodig is om de back-up te herstellen ook na verlies van de host beschikbaar is.

Stop niet elk geheim in een openbare Git-repository alleen omdat de configuratie versiebeheer gebruikt. Bewaar geheim materiaal via een beveiligd mechanisme en documenteer waar het voor herstel kan worden opgehaald.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

De runtime-definitie bouwt de omgeving rond de status opnieuw op

Een herstelde configuratiestructuur kan nog steeds mislukken als de vervangende host niet opnieuw de USB-radiokoppeling, netwerkmodus, poorten, hostpaden, databaseservice, MQTT-broker, omgevingsvariabelen, tijdzone of rechten biedt die de oorspronkelijke implementatie verwachtte.

De richtlijnen voor Home Assistant Container scheiden updates van persistente status en gaan ervan uit dat de runtime opnieuw wordt gemaakt aan de hand van bekende Docker-parameters. De actuele Container-werkwijze houdt back-up en het vervangen van de image als afzonderlijke bewerkingen, dezelfde scheiding die een herstelplan moet behouden.

Bewaar Compose-bestanden of gelijkwaardige implementatiedefinities naast de documentatie voor externe services. Runtimeconfiguratie is niet de Home Assistant-database, maar maakt wel deel uit van het reproduceren van een werkende service.

Back-ups zijn herstelkopieën, geen afzonderlijke livegegevensrol

Een back-up moet bestand zijn tegen de storing waarvoor deze bedoeld is. Als elke back-up op dezelfde systeem-SSD staat als de actieve configuratie en Recorder-database, kan één opslagfout alle drie de rollen tegelijk verwijderen.

Herstelkopieën moeten ook bestand zijn tegen het verlies van de Home Assistant-host. Het 3-2-1-back-upmodel bewaart meerdere kopieën op verschillende media, met ten minste één kopie op een externe locatie. Voor versleutelde Home Assistant-back-ups moeten de noodkit of de bijbehorende sleutel eveneens buiten het defecte systeem beschikbaar blijven.

• Configuratie en registers: herstel of repareer deze zorgvuldig, omdat ze identiteit en automatiseringsgedrag bepalen.
• Recorder en statistieken: repareer, herstel of bouw deze onafhankelijk opnieuw op wanneer alleen de geschiedenislayer beschadigd is.
• Geheimen en sleutels: herstel deze uit een beveiligde opslag buiten de defecte host.
• Runtime-definitie: maak mounts, apparaten, netwerken en serviceafhankelijkheden opnieuw.
• Back-ups: bewaar herstelkopieën buiten het live-foutdomein.

Het implementatievoorbeeld van Home Assistant op ZimaSpace biedt nuttige context voor deze scheiding: het serverplatform kan veranderen, terwijl de applicatiestatus en herstelverantwoordelijkheden logisch gescheiden blijven.

De rollen van persistente gegevens zijn belangrijk omdat ze je in staat stellen de kleinst mogelijke defecte laag te repareren. Een databaseprobleem hoeft geen schone installatie te worden, en een containerupdate hoeft niet tot configuratieverlies te leiden.