Een grote Home Assistant-database hoeft niet automatisch te worden vervangen. Toenemende omvang, trage geschiedenis of een bestand dat na het opschonen groot blijft, vraagt meestal eerst om aanpassingen aan bewaartermijnen, filters, opslag of herverpakking. Vervanging wordt redelijker wanneer de database niet consequent kan worden geopend, herhaaldelijk integriteitsfouten optreden of Home Assistant de database al als beschadigd heeft geïsoleerd.
Maak onderscheid tussen “onderhoud nodig” en “status niet langer betrouwbaar”. De eerste categorie moet bruikbare geschiedenis behouden. De tweede vereist dat je de defecte database veiligstelt, een bekende goede kopie terugzet of een nieuwe Recorder-database start, en onderzoekt waarom de beschadiging is ontstaan voordat normale schrijfbewerkingen worden hervat.
Snelle groei is eerst een onderhoudssignaal en pas daarna een vervangingssignaal
Controleer de geschatte Recorder-omvang en de dagelijkse groei. Als enkele luidruchtige entiteiten, een lange bewaartermijn voor ruwe geschiedenis of onnodige gebeurtenissen de database domineren, verminder dan eerst de inkomende belasting voordat je het hele bestand verwijdert.
De huidige opslagrichtlijnen van Home Assistant adviseren om oude Recorder-gegevens te verwijderen, te filteren wat wordt opgeslagen en de bewaartermijn aan te passen wanneer de database te groot wordt.
Als de groei afneemt na wijzigingen in filters of bewaartermijnen, kan de database zelf gezond zijn. Blijf monitoren in plaats van de geschiedenis te resetten alleen omdat de absolute bestandsgrootte oncomfortabel lijkt.
Een groot bestand na het opschonen heeft mogelijk herverpakking nodig, geen vervanging
Door oude rijen te verwijderen kan ruimte in de database worden vrijgemaakt voor hergebruik, zonder dat het bestand op de schijf kleiner wordt. Herverpakken herschrijft de database, zodat ruimte op het bestandssysteem kan worden teruggewonnen.
Voer dit alleen uit met voldoende vrije ruimte en een geteste back-up. Een trage of grote database tijdens het herverpakken is geen bewijs dat de gegevens moeten worden verwijderd.
Herhaalde beschadigde of integriteitsfouten zijn sterkere waarschuwingssignalen
Databasefouten zoals beschadigde pagina's, mislukte integriteitscontroles, herhaalde I/O-fouten of beschadiging die na een schone herstelactie terugkeert, vereisen een andere aanpak dan gewone groei. Stel het bestand veilig en stop destructief onderhoud terwijl je bepaalt of opslag, stroomuitval, geheugendruk of het bestandssysteem een rol speelt.
Onherstelbare SQLite-beschadiging is een herstelgebeurtenis en geen normale onderhoudstoestand: Home Assistant kan een beschadigde Recorder-database opzijzetten en een nieuwe database starten, zodat de rest van het systeem online kan blijven. Dat is een veel sterker vervangingssignaal dan gewone omvangstoename of trage geschiedenisquery's.
Als je een SQLite-controle op laag niveau nodig hebt, kan PRAGMA integrity_check de consistentie van de database controleren. Werk met een kopie of tijdens een gecontroleerd onderhoudsvenster wanneer je handmatige databasetools gebruikt.
Vervanging is zinvol wanneer de Recorder-status niet kan worden vertrouwd
Vervanging betekent óf een bekende goede database terugzetten óf Home Assistant een nieuwe database laten aanmaken wanneer het behoud van de geschiedenis minder belangrijk is dan Recorder weer beschikbaar maken. Het is geen optimalisatie voor prestaties die je als eerste moet uitvoeren.
Kies voor vervanging wanneer de database herhaaldelijk niet kan worden geopend, beschadiging bij normale herstelpogingen blijft terugkeren, een bekende goede back-up veiliger is dan reparatie of het verlies van oude geschiedenis acceptabel is terwijl de configuratiestatus verder gezond is.
De ZimaSpace-handleiding voor het vastleggen van de status vóór risicovol applicatieonderhoud is hierbij nuttig: bewaar een terugdraaiartefact vóór het opschonen, herverpakken, handmatig repareren met SQL of vervangen van de database.
Gebruik het foutpatroon om de volgende actie te kiezen
| Symptoom | Eerste actie | Vervangen? |
|---|---|---|
| Database groeit snel | Luidruchtige entiteiten filteren / bewaartermijn verkorten | Niet nodig |
| Bestand blijft groot na het opschonen | Herverpakken plannen met voldoende vrije ruimte | Niet nodig |
| Geschiedenisquery's zijn traag tijdens schijfbelasting | Opslaglatentie meten | Meestal niet |
| Beschadigde pagina's of integriteitsfouten | Bestand veiligstellen, opslag controleren, kopie terugzetten/testen | Mogelijk |
| Herhaalde beschadiging na herstel | Opslag/stroom onderzoeken en bekende goede status terugzetten | Vaak wel |
Verwijder home-assistant_v2.db niet alleen omdat Home Assistant traag aanvoelt. Stel eerst vast of het probleem wordt veroorzaakt door gegevensvolume, onderhoud, servicetijd van de opslag of daadwerkelijke beschadiging.
Veelgestelde vragen
Moet ik home-assistant_v2.db verwijderen om Home Assistant sneller te maken?
Meestal niet. Door het bestand te verwijderen, verwijder je de Recorder-geschiedenis en verberg je mogelijk de werkelijke oorzaak. Verminder onnodige registratie, controleer opslag en vrije ruimte en gebruik het opschonen of herverpakken op de juiste manier voordat je voor vervanging kiest.
Ondersteuning & Tips
Meer om te lezen

Hoeveel gelijktijdige gebruikers kan Home Assistant verwerken voordat het trager wordt?
Home Assistant heeft geen vaste, bruikbare gebruikerslimiet: benchmark actieve clients met echte dashboards en updates van entiteiten en stop voordat er herhaaldelijk merkbare latentie...

Kan Home Assistant een externe database gebruiken zonder upgrades te verstoren?
Een externe Recorder-database kan upgrades overleven, maar brengt eigen verantwoordelijkheden met zich mee op het gebied van beschikbaarheid, schemamigratie, back-ups, herstel en versiebeheer.

Zo test je of DNS verbindingsproblemen met Home Assistant veroorzaakt
Toon een DNS-fout in Home Assistant aan door dezelfde hostnaam vanaf het getroffen pad te testen, de bereikbaarheid van het directe IP-adres te vergelijken...

