Wanneer het databasevolume van Home Assistant vol is, stop je eerst nieuwe schrijfbewerkingen. Maak werkruimte vrij zonder de actieve database te verwijderen, bewaar een kopie en bepaal of Recorder de database kan openen en onderhouden voordat je kiest voor opschonen, repareren of herstellen.
Een vol volume kan juist de opruimactie blokkeren die het probleem moet oplossen, vooral wanneer opnieuw inpakken of het reconstrueren van de database tijdelijke ruimte vereist. Houd de volgorde voorzichtig aan: stop Home Assistant, controleer welke bestandssysteem werkelijk vol is, verplaats niet-gerelateerde bestanden of breid het volume uit, kopieer de database, controleer logboeken en integriteit en pas vervolgens het minst destructieve herstel toe dat bij het resultaat past.
Schrijfactiviteiten stoppen en het werkelijk volle bestandssysteem bevestigen
Stop Home Assistant of Recorder zodra fouten bij het schrijven naar de database zich herhalen. Controleer welk bestandssysteem, aankoppelpunt of thin volume de actieve database bevat en vergelijk de totale ruimte, vrije ruimte, inodes, databasegrootte, logboeken, back-ups en schrijfbare containerlagen. Een volle systeemschijf en een vol extern databasevolume vereisen verschillende oplossingen.
Ga er niet van uit dat de database de enige verbruiker is. Oude back-ups, foutopsporingslogboeken, exports, snapshots en niet-gerelateerde containerlagen kunnen veiligere noodruimte opleveren. Verplaats of verwijder alleen bestanden waarvan het doel en de back-upstatus bekend zijn; verwijder de actieve database, WAL, het journaal of bestanden van de database-engine niet afzonderlijk.
De ZimaSpace-handleiding over Docker-schijfgebruik buiten gekoppelde gegevens vinden is de juiste parallelle controle wanneer het geconfigureerde databasepad klein lijkt, maar de systeemschijf van de host nog steeds vol is.
Werkruimte creëren en de database behouden
Breid het volume bij voorkeur uit of verplaats niet-gerelateerde archieven naar een andere gecontroleerde schijf. Als dat niet mogelijk is, kopieer je de gestopte database en de bijbehorende bestanden naar opslag met voldoende capaciteit voordat je onderhoud uitvoert. Noteer eigenaar, rechten, engine, de Home Assistant-versie en de database-URL.
Opnieuw inpakken is geen goede eerste noodmaatregel op een vol bestandssysteem, omdat dit veel tijdelijke ruimte kan vereisen. Volgens opmerkingen uit de community kan het opnieuw inpakken van SQLite vrije ruimte nodig hebben die vergelijkbaar is met de databasegrootte; het praktische punt is daarom om werkruimte te creëren vóór het opnieuw inpakken in plaats van te vertrouwen op een bijna vol volume.
Controleer na het vrijmaken van ruimte of het bestandssysteem schrijfbaar en stabiel is. Als het opnieuw alleen-lezen is aangekoppeld, hardwarefouten meldt of onmiddellijk weer ruimte verliest, stop dan en herstel eerst de opslaglaag voordat je de database opent.
Kiezen tussen opschonen, integriteitsherstel of een bekende goede back-up
Start Home Assistant alleen lang genoeg om de Recorder-logboeken en databasestatus te controleren. Als de database zonder problemen wordt geopend, verklein je de bewaartermijn of sluit je luidruchtige entiteiten uit en voer je eerst een opschoning uit zonder opnieuw inpakken. Hiermee verklein je de logische gegevensomvang en vermijd je de stap die de meeste tijdelijke ruimte vereist.
Als er integriteitsfouten optreden, stop je opnieuw met schrijven en werk je op een kopie. Gebruik de ondersteunde integriteits- en hersteltools van de database-engine of herstel een bekende goede back-up. Start Home Assistant niet herhaaldelijk met een beschadigde database, omdat nieuwe schrijfbewerkingen het herstel kunnen bemoeilijken en de oorspronkelijke fout kunnen verhullen.
Als er geen bruikbare databasekopie of back-up bestaat, herstelt het aanmaken van een nieuwe Recorder-database de werking, maar gaat de geschiedenis verloren. Beschouw dit als de laatste hersteloptie, bewaar de mislukte database voor latere analyse en houd de configuratie en registers gescheiden van de beslissing over de geschiedenis.
De oorzaak van de groei beperken voordat je de service hervat
Stel vast waardoor het volume vol is geraakt: buitensporig veel entiteitsupdates, een lange bewaartermijn, grote logbestanden, een opeenstapeling van back-ups, een mislukte opschoning, databasegroei of een volume dat kleiner is dan bedoeld. Los de gemeten oorzaak op in plaats van alle opruimopties tegelijk toe te passen.
Stel een verdedigbare bewaartermijn in, sluit entiteiten uit waarvan de frequente geschiedenis weinig waarde heeft, zet logging van debug terug naar normaal, verplaats back-ups buiten de host en waarschuw zowel bij weinig vrije ruimte als bij een hoge groeisnelheid. Houd ruimte vrij voor upgrades, back-ups, schem wijzigingen en onderhoud.
Vergelijk de herstelde database met de ZimaSpace-criteria voor databaseonderhoud versus vervanging wanneer herhaalde beschadigingen of integriteitsfouten voortgezet herstel minder betrouwbaar maken dan een herstel vanaf een bekende goede back-up.
Herstel valideren onder Recorder-belasting
Start Home Assistant en controleer de huidige statussen, nieuwe geschiedenisbewerkingen, logboekquery's, automatiseringsacties en databasegrootte. Voer dezelfde werklast met veel updates uit die aan de fout voorafging en houd daarbij de vrije ruimte, schrijffouten, databasevertraging en groeisnelheid in de gaten.
Start Home Assistant tweemaal opnieuw en voer de volgende geplande opschoning of back-up uit. Het herstel is alleen geslaagd als de database opnieuw wordt geopend, de geschiedenis wordt bijgewerkt, de vrije ruimte boven de stopgrens blijft en er geen integriteits- of alleen-lezenfouten terugkeren.
Ga terug naar de bewaarde kopie of bekende goede back-up als het onderhoud nieuwe beschadigingen veroorzaakt, de geschiedenis onverwacht verdwijnt of het volume in hetzelfde tempo volloopt. Escaleer opslagfouten, fouten van de database-engine en reproduceerbare Recorder-fouten met logboeken en de bewaarde tijdlijn.
Ondersteuning & Tips
Meer om te lezen

Hoe je databaseverbindingen van Home Assistant optimaliseert voor gelijktijdige containers
Stem een externe Recorder-database af op basis van gemeten actieve verbindingen en latentie, niet door het maximumaantal verbindingen te verhogen of de pool van...

Dubbele taken of imports in Home Assistant voorkomen
Gebruik traceringen en unieke bewerkingssleutels om automatiseringen en importbewerkingen veilig opnieuw uit te voeren zonder dubbele acties of records te produceren.

Waarom maakt Home Assistant ontbrekende bestanden opnieuw aan met de verkeerde eigenaar?
Stem de runtime-UID en -GID af op het hostpad, herstel alleen de getroffen bestanden wanneer deze is gestopt en controleer het eigenaarschap na het...

