Förhindra att Home Assistant-loggar fyller disken genom att först identifiera den exakta filen som växer, åtgärda den återkommande händelsen och tillämpa lagringstiden på det lager som äger loggen.
På en liten hemmaserver kan loggar från Home Assistant Core, Docker, Supervisor eller tillägg samt värddatorns journal alla förbruka samma systemdisk, samtidigt som de kräver olika åtgärder. Mät tillväxten under ett kort, kontrollerat tidsintervall, bevara tillräckligt med bevis för att identifiera den komponent som skriver, använd reversibla begränsningar och stoppa icke nödvändiga skrivningar om det återstående utrymmet är för litet för en säker omstart eller säkerhetskopia.
Identifiera vilken logg som förbrukar utrymme
Notera först det totala lediga utrymmet och lista sedan de största filerna och katalogerna på det berörda filsystemet utan att radera något. Jämför storlekarna igen efter fem till tio minuter medan Home Assistant körs normalt. Filen vars storlek förändras är mer användbar än en statisk lista över gamla stora filer.
Fall med Home Assistant visar att slut på diskutrymme kan bero på olika lager, inklusive systemloggar snarare än Recorder-databasen. I en löst diskussion spårades tillväxten till systemd-journalen, så den första frågan är vilken katalog som fortsätter att växa, inte om Home Assistant verkar vara upptaget.
Om en Core-logg växer granskar du dess återkommande komponent och meddelande. Om Docker JSON-loggar växer granskar du containerns loggdrivrutin. Om journalen växer granskar du tjänsten som genererar meddelandena. Om det lediga utrymmet redan är kritiskt lågt stoppar du den mest högljudda icke nödvändiga containern eller själva Home Assistant innan ytterligare skrivningar gör återställningen svårare.
Åtgärda återkommande fel innan du minskar synligheten
Räkna det vanligaste meddelandet och matcha tidsstämplarna mot en enhet, integration, automatisering, ett tillägg eller en nätverkshändelse. En varning som upprepas tusentals gånger har vanligtvis större förebyggande värde än dussintals orelaterade engångsposter. Spara ett kort exempel med version och utlösare innan du ändrar inställningarna.
Ett problem i Home Assistant Core dokumenterade ett Tradfri-fel som drev en logg över 10 GB och fyllde systemdisken. Det är ett versionsspecifikt exempel på en integration som översvämmar en logg; det stöder att isolera den komponent som genererar meddelandena, inte att anta att Tradfri eller loggrotation alltid är orsaken.
Inaktivera felsökningsloggning när insamlingen är klar och ladda sedan om eller inaktivera endast den bekräftat högljudda integrationen och upprepa den ursprungliga utlösaren. Om meddelandefrekvensen sjunker kraftigt åtgärdar du integrationen eller dess beroende. Om den inte gör det återställer du inställningen och går vidare till nästa verifierade komponent i stället för att undertrycka alla varningar.
Ställ in lagringstid på det lager som äger loggen
Ställ in en begränsad policy separat för värddatorns journal, Dockers loggdrivrutin, reverse proxy och andra tillägg. En loggnivå i Core begränsar inte lagringen i systemd-journalen, och ett storleksalternativ i Docker roterar inte en fil som skrivs direkt i en monterad konfigurationskatalog.
Välj gränser som bevarar tillräckligt med historik för att täcka intervallet mellan kontrollerna, samtidigt som utrymme lämnas för säkerhetskopior, uppdateringar, databasarbete och återställning. Den relaterade ZimaSpace-artikeln om ledigt lagringsutrymme i Home Assistant förklarar varför det kan leda till problem att förbruka den sista marginalen när en åtgärd tillfälligt behöver ytterligare diskutrymme.
Dokumentera varje policy i den konfiguration som överlever återskapande. Starta om eller återskapa endast den berörda tjänsten, bekräfta att inställningen är aktiv och behåll det tidigare värdet tillgängligt för återställning. Använd inte schemalagd massradering som ersättning för att hitta en onormal skrivande komponent.
Verifiera att tillväxten förblir begränsad under den ursprungliga utlösaren
Återskapa händelsen som orsakade översvämningen, till exempel att en enhet går offline, en integration försöker igen, en säkerhetskopia körs eller ett nätverksavbrott inträffar. Följ samma filstorlek, meddelandefrekvens, lediga utrymme, tjänstehälsa och automatiseringsrespons under längre tid än den tidigare tillväxtperioden.
Ett godkänt resultat innebär ett stabilt eller roterande loggutrymme, ingen förlust av nödvändig diagnostik, normala historikskrivningar och tillräckligt med ledigt utrymme för nästa säkerhetskopia och uppdatering. Starta om värddatorn en gång och upprepa utlösaren så att begränsningarna bevisas även efter att tjänsten har återskapats.
Återställ en ändring av lagringstiden om den tar bort bevis som behövs för att diagnostisera ett pågående fel. Eskalera med det återkommande meddelandet, den komponent som genererar det, versionen, tillväxthastigheten och lagringssökvägen om loggen fortfarande växer efter att den bekräftade källan har isolerats. Stoppa skrivningarna igen om disken närmar sig full kapacitet.
Support och tips
Mer att läsa

Home Assistant fungerar via Wi-Fi men inte via Ethernet eller VPN
Testa varje nätverkssökväg separat, verifiera gränssnittets och routingens status, skilj direktanslutning via IP-adress från upptäckt och reparera sedan endast det lager som har fallerat.

Så avvecklar du Home Assistant utan att lämna kvar oskyddade data
Bevisa utbytet eller arkiveringen, återkalla varje förtroendeväg, sanera varje databärande enhet och behåll endast dokumenterade skyddade återställningskopior.

Bör du använda automatiska uppdateringar för Home Assistant på en hemmaserver?
Välj manuella, endast aviserade eller stegvis automatiska uppdateringar utifrån påverkan på hushållet, kompatibilitetsrisk, observationstid och beredskap för återställning.

