Moet je de metadata van Home Assistant op een SSD zetten en bulkgegevens op een HDD?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Meestal wel: houd de actieve configuratie, registers, metadata en lokale database van Home Assistant op een betrouwbare SSD, en plaats grote mediabestanden, camera-opnamen, exports en secundaire back-upkopieën op HDD-opslag.

De belangrijke grens is niet simpelweg die tussen kleine en grote bestanden. De boomstructuur van Home Assistant in /config bevat nauw gekoppelde permanente statusgegevens, terwijl Recorder regelmatig databasebewerkingen uitvoert en externe mounts afhankelijkheden toevoegen voor het opstarten en de beschikbaarheid. Splits gegevens op basis van hun gebruikspatroon, documenteer elke mount en controleer een herstart plus herstel voordat je op de scheiding vertrouwt.

Houd de actieve status van Home Assistant samen op de SSD

Behandel /config als één hersteleenheid. Deze map bevat normaal gesproken YAML, geheimen, de map .storage, registers, integratiestatus en—bij gebruik van SQLite—de actieve database. Door afzonderlijke verborgen statusbestanden over mounts te verdelen, wordt het moeilijker om eigenaarschap, opstartvolgorde en de dekking van herstelacties te overzien.

Recorder schrijft continu, waardoor het opslaggedrag verschilt van dat van een archief dat af en toe wordt geopend. Onafhankelijke probleemoplossingsrichtlijnen adviseren snelle opslag voor de actieve Home Assistant-database, omdat frequente lees- en schrijfbewerkingen trage media kunnen veranderen in merkbare vertragingen in geschiedenis en automatiseringen. De relevante onderbouwing is snelle opslag voor de actieve database, niet de belofte dat elke SSD elk knelpunt oplost.

Als je een externe MariaDB- of PostgreSQL-service gebruikt, wordt de database een afzonderlijk systeem met permanente status, een eigen back-up-, authenticatie-, netwerk- en upgradegrens. Behandel het wijzigen van de database-URL niet als een eenvoudige wijziging van de bestandslocatie.

Verplaats gegevens die veel ruimte innemen alleen als ze een duidelijke grens hebben

HDD-opslag is een redelijk doel voor grote mediabestanden, langdurige camera-opnamen, geëxporteerde rapporten en extra back-upkopieën wanneer die paden niet de liveconfiguratie of database bevatten. Bij deze werkbelastingen is capaciteit doorgaans belangrijker dan een lage latentie bij kleine willekeurige I/O-bewerkingen.

Maak expliciete hostpaden en mount deze op stabiele containerlocaties. Plaats geen brede bovenliggende mount over /config, omdat een lege of laat beschikbare hostmap de verwachte gegevens kan verbergen en Home Assistant eruit kan laten zien alsof het opnieuw is geïnstalleerd. Controleer of de HDD is gemount voordat de container start en bepaal wat er moet gebeuren als deze niet beschikbaar is.

Het gerelateerde ZimaSpace-artikel over de groei van metadata en geschiedenis in Home Assistant helpt om registers, Recorder-geschiedenis, logboeken en back-ups van elkaar te onderscheiden voordat je elke categorie aan een opslaglaag toewijst.

Plan back-ups over beide opslaglagen

Leg vast welke back-up /config, de actieve database, de HDD-paden en eventuele externe database bevat. Een archief dat volledig lijkt, kan een afzonderlijk gemount media- of databasepad toch overslaan, terwijl een kopie van het bestandssysteem inconsistent kan zijn als deze tijdens een databasebewerking wordt gemaakt.

Bewaar ten minste één back-upkopie buiten de Home Assistant-host. De SSD/HDD-scheiding verbetert de plaatsing, maar beschermt niet tegen verwijdering, stroomstoringen, defecten aan de controller of een mislukte migratie die beide schijven bereikt. Bewaar versleutelingssleutels en inloggegevens in het herstelplan en niet op dezelfde machine.

Maak voordat je mounts wijzigt een bekende goede back-up en noteer de huidige aantallen entiteiten, integraties, recente geschiedenis, dashboards, automatiseringen en mediapaden. Deze observaties vormen de acceptatietest na het opnieuw aanmaken en zijn nuttiger dan alleen controleren of de inlogpagina wordt geopend.

Valideer de scheiding via herstart, belasting en herstel

Herstart de host, niet alleen Home Assistant, om de volgorde van mounts te testen. Controleer voordat Home Assistant begint te schrijven of /config naar het SSD-pad verwijst en elke mount voor bulkgegevens naar het bedoelde HDD-pad verwijst. Een lege map op een van beide locaties is een reden om te stoppen.

Voer de oorspronkelijke werkbelasting uit: open de geschiedenis, activeer een drukke automatisering, schrijf een opname- of mediabestand en maak een back-up. Een geslaagd resultaat houdt de bediening responsief, schrijft gegevens naar de bedoelde schijven, geeft geen database- of toestemmingswaarschuwingen en laat de host een normale I/O-latentie behouden.

Herstel ten slotte naar een geïsoleerde testinstantie en controleer beide opslaglagen. Draai de scheiding terug als Home Assistant start met lege registers, verouderde geschiedenis, ontbrekende media of fouten die afhankelijk zijn van mounts. Stap pas over op een externe database of een opnieuw ontworpen opslagindeling wanneer de eenvoudigere grens van SSD /config plus HDD voor bulkgegevens niet aan de eisen voor capaciteit of beschikbaarheid kan voldoen.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.