Så reparerar du Home Assistant efter att databasvolymen blivit full

När Home Assistant-databasens volym är full ska du först stoppa nya skrivningar. Skapa arbetsutrymme utan att radera den aktiva databasen, bevara en kopia och fastställ om Recorder kan öppna och underhålla databasen innan du väljer rensning, reparation eller återställning.

En full volym kan blockera själva rensningsåtgärden som ska lösa problemet, särskilt när ompackning eller rekonstruktion av databasen kräver tillfälligt utrymme. Följ en försiktig ordning: stoppa Home Assistant, bekräfta vilket filsystem som är fullt, flytta orelaterade filer eller utöka volymen, kopiera databasen, kontrollera loggar och integritet och tillämpa sedan den minst destruktiva återställningen som stämmer med resultatet.

Stoppa skrivningar och bekräfta vilket filsystem som faktiskt är fullt

Stoppa Home Assistant eller Recorder så snart databasens skrivfel upprepas. Bekräfta vilket filsystem, vilken monteringspunkt eller tunna volym som innehåller den aktiva databasen och jämför totalt utrymme, ledigt utrymme, inoder, databasstorlek, loggar, säkerhetskopior och skrivbara lager för containrar. En full systemdisk och en full extern databasvolym kräver olika åtgärder.

Utgå inte från att databasen är den enda förbrukaren. Gamla säkerhetskopior, felsökningsloggar, exporter, ögonblicksbilder och orelaterade lager för containrar kan ge säkrare akututrymme. Flytta eller radera endast filer vars syfte och säkerhetskopieringsstatus är kända; ta inte bort den aktiva databasen, WAL-, journal- eller databasmotorfiler individuellt.

ZimaSpaces guide om att hitta Docker-diskanvändning utanför mappad data är rätt parallella kontroll när den konfigurerade databassökvägen verkar liten men värddatorns systemdisk fortfarande är full.

Skapa arbetsutrymme och bevara databasen

Utöka helst volymen eller flytta orelaterade arkiv till en annan verifierad disk. Om det inte är möjligt ska du kopiera den stoppade databasen och dess relaterade filer till lagring med tillräcklig kapacitet innan du försöker utföra underhåll. Dokumentera ägare, behörigheter, motor, Home Assistant-version och databas-URL.

Ompackning är inte ett lämpligt första steg i ett nödläge på ett fullt filsystem, eftersom det kan kräva betydande tillfälligt utrymme. Felsökningsanteckningar från communityn visar att SQLite-ompackning kan behöva ledigt utrymme som motsvarar databasens storlek; det praktiska är att skapa arbetsutrymme före ompackning i stället för att lita på en nästan full volym.

Efter att du har frigjort utrymme ska du bekräfta att filsystemet är skrivbart och stabilt. Om det har monterats om som skrivskyddat, rapporterar maskinvarufel eller omedelbart blir fullt igen ska du avbryta och reparera lagringslagret innan du öppnar databasen.

Välj rensning, integritetsreparation eller en känd fungerande återställning

Starta Home Assistant endast så länge som behövs för att granska Recorder-loggar och databasstatus. Om databasen öppnas utan problem ska du minska lagringstiden eller undanta brusiga entiteter och köra en rensning utan ompackning först. Det minskar den logiska datamängden samtidigt som det mest utrymmeskrävande tillfälliga steget undviks.

Om integritetsfel visas ska du stoppa skrivningarna igen och arbeta med en kopia. Använd databasmotorns stödda integritets- och återställningsverktyg eller återställ en känd fungerande säkerhetskopia. Starta inte Home Assistant upprepade gånger mot en skadad databas, eftersom nya skrivningar kan försvåra återställningen och dölja det ursprungliga felet.

Om det inte finns någon användbar databaskopia eller säkerhetskopia återställer en ny Recorder-databas driften men historiken går förlorad. Behandla detta som den sista återställningsvägen, bevara den trasiga databasen för senare analys och håll konfiguration och register separerade från beslutet om historiken.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Minska orsaken till tillväxten innan tjänsten åter tas i drift

Identifiera vad som fyllde volymen: för många entitetsuppdateringar, för lång lagringstid, stora loggar, ansamling av säkerhetskopior, misslyckad rensning, databasuppsvällning eller en volym som är mindre än avsett. Åtgärda den uppmätta orsaken i stället för att tillämpa alla rensningsalternativ samtidigt.

Ange en välgrundad lagringstid, undanta entiteter vars historik med hög uppdateringsfrekvens har litet värde, återställ loggningen från felsökning till normalt läge, flytta säkerhetskopior från värddatorn och skapa larm för både ledigt utrymme och tillväxthastighet. Lämna arbetsutrymme för uppgraderingar, säkerhetskopior, schemändringar och underhåll.

Jämför den återställda databasen med ZimaSpaces kriterier för databasunderhåll kontra ersättning när upprepade korruptions- eller integritetsfel gör fortsatt reparation mindre tillförlitlig än en känd fungerande återställning.

Validera återställningen under Recorder-belastning

Starta Home Assistant och bekräfta aktuella tillstånd, nya historikskrivningar, loggboksfrågor, automatiseringsåtgärder och databasens storlek. Kör samma arbetsbelastning med många uppdateringar som föregick felet medan du övervakar ledigt utrymme, skrivfel, databasfördröjning och tillväxthastighet.

Starta om Home Assistant två gånger och kör nästa schemalagda rensning eller säkerhetskopiering. Återställningen är godkänd endast om databasen öppnas igen, historiken fortsätter att uppdateras, det lediga utrymmet förblir över stoppgränsen och inga integritets- eller skrivskyddsfel återkommer.

Återgå till den bevarade kopian eller den kända fungerande säkerhetskopian om underhållet orsakar ny korruption, historik försvinner oväntat eller volymen börjar fyllas i samma takt igen. Eskalera lagringsfel, databasmotorfel och reproducerbara Recorder-fel med loggar och den bevarade tidslinjen.