När bör du bygga om i stället för att reparera Home Assistant?
Bygg om Home Assistant först när det aktuella beständiga tillståndet inte längre är en tillförlitlig källa för återställning och en verifierat fungerande säkerhetskopia inte kan få installationen i drift igen. De flesta fel bör först klassificeras som problem med körning, integrationer, konfiguration, databas, lagring eller nätverk och åtgärdas på den minsta berörda nivån.
En ominstallation är inte automatiskt en ombyggnad. Att ersätta en containeravbildning kan lämna /config orörd, medan en verklig ombyggnad skapar ett nytt programtillstånd och innebär att integrationer, enheter, instrumentpaneler, hjälpare och automationer måste återställas eller återskapas. Fatta beslutet utifrån tillståndets skick, inte utifrån frustration över det aktuella symptomet.
Använd tre olika åtgärder: reparera, återställ, bygg om
Reparation behåller den aktuella konfigurationen och åtgärdar den komponent som har slutat fungera. Återställning ersätter skadat eller inkompatibelt tillstånd med en verifierat fungerande säkerhetskopia. En ombyggnad börjar med en ren Home Assistant-installation och importerar eller återskapar sedan endast det tillstånd du medvetet litar på.
Denna åtskillnad förhindrar att ett container- eller paketproblem leder till onödig dataförlust. Om de aktuella användarna, områdena, enheterna och automationerna fortfarande finns kvar kan en ny installation förstöra mer känd fungerande information än den reparerar.
Skriv ned vilken av de tre åtgärderna du genomför innan du ändrar filer. Den enkla etiketten gör det svårare att oavsiktligt gå från reparation till en destruktiv återställning.
Reparera först när det beständiga tillståndet fortfarande är sammanhängande
Reparation är lämpligt när Home Assistant öppnar den förväntade instansen, konfigurationskatalogen är ifylld och felet kan kopplas till en specifik integration, YAML-ändring, anpassad komponent, databasfil, monteringspunkt eller körningsinställning.
Felsäkert läge och återställningsläge finns just eftersom många startfel kan avgränsas utan att konfigurationen överges. En aktuell återställningsguide rekommenderar att du läser det exakta startfelet, använder felsäkert läge för att isolera anpassad kod och använder återställningsläge som en minimal reparationsväg innan du bygger om.
Inaktivera eller uppdatera en anpassad integration, korrigera en ogiltig konfigurationspost, reparera lagringssökvägen eller återgå till en tidigare körningsversion och testa sedan igen. Återställ inte hela installationen medan felet fortfarande är avgränsat.
Reparera databasen endast om historiken är värd att spara
Korruption i Recorder kan verka allvarlig eftersom loggarna fylls med databasfel, men Recorder-databasen är inte samma sak som hela Home Assistant-konfigurationen. Om den aktuella konfigurationen och integrationerna är intakta kan en ny historikdatabas ibland vara mindre riskfylld än en fullständig ombyggnad av programmet.
När historiken är värdefull visar en praktisk återställningsguide hur du stoppar Home Assistant och använder SQLite:s återställningsverktyg för att återskapa en skadad Home Assistant-databas i en ny fil.
Arbeta endast med kopior, bevara den ursprungliga skadade databasen och acceptera att återställningen kan bli ofullständig. En misslyckad reparation av historiken bör inte bli ett skäl att kasta bort fungerande automationer och integrationer.
Återställ när en verifierat fungerande säkerhetskopia är säkrare än fortsatt reparation
Återställ när felet började efter en identifierbar uppdatering eller redigering och du har en testad säkerhetskopia från före ändringen. Det är ofta snabbare och säkrare än att manuellt backa dussintals migrerade eller delvis ändrade filer.
En sedan länge använd återställningsguide för Home Assistant rekommenderar att du först åtgärdar orsaken till felet och sedan återställer en säkerhetskopia som kopierats bort från det havererade systemet. Om du återställer utan att ta bort den felande strömförsörjningen, diskproblemet, felaktiga monteringspunkten eller inkompatibla körningsmiljön återskapar du bara incidenten.
Behåll det skadade tillståndet tills det återställda systemet har godkänts. Det kan innehålla nya automationer, hemligheter eller konfigurationsändringar som behöver jämföras eller återställas selektivt.
Bygg om när tillståndet och återställningsunderlaget inte längre är tillförlitliga
En ren ombyggnad blir rimlig när konfigurationskatalogen saknas eller är omfattande skadad, flera säkerhetskopior misslyckas i återställningstester, körningsdefinitionen är okänd eller upprepade reparationer lämnar installationen i ett odokumenterat tillstånd som inte kan återskapas.
En ombyggnad kan också vara det renare valet när du lämnar en dåligt strukturerad driftsättning – till exempel viktig konfiguration som är fast inne i en förbrukningsbar container – förutsatt att du först exporterar varje tillförlitlig del av tillståndet som du kan.
ZimaSpaces guide för lokal automation betonar återställningsbarhet som ett grundläggande krav för en plattform för smarta hem. En ombyggnad är lyckad endast när den nya installationen är enklare att säkerhetskopiera, återställa och driva än det tillstånd du övergav.
Använd en beslutstabell innan du raderar det gamla tillståndet
| Förhållande | Rekommenderad åtgärd |
|---|---|
| Enstaka integrations- eller konfigurationsfel | Reparera |
| Uppdatering av körningsmiljö/avbildning misslyckades, konfigurationen är intakt | Reparera eller återgå till tidigare körningsmiljö |
| Databasen är skadad, konfigurationen är frisk | Reparera/ersätt databasen |
| Verifierat fungerande säkerhetskopia från tiden före omfattande skador | Återställ |
| Konfiguration och säkerhetskopior kan inte litas på eller återskapas | Bygg om |
Radera inte den gamla konfigurationen, databasen eller uppsättningen med säkerhetskopior förrän den valda vägen har klarat en omstart och en normal användningscykel i hemmet.
Vanliga frågor
Räknas ominstallation av Home Assistant-containern som en ombyggnad?
Nej. Om ersättningscontainern ansluter till samma beständiga /config-katalog har du ersatt körningsmiljön men behållit samma installationstillstånd. En ombyggnad börjar med ett nytt tillstånd eller innebär att det gamla tillståndet överges medvetet.
Bör jag bygga om Home Assistant eftersom Recorder-databasen är skadad?
Vanligtvis inte. Recorder-historiken kan repareras, återställas eller ersättas separat från resten av Home Assistant. Bygg om hela installationen endast när konfigurationen och återställningstillståndet – inte bara historiken – inte längre är tillförlitliga.
Rekommenderade produkter
Support och tips
Mer att läsa
Bör du säkerhetskopiera Home Assistant medan det körs eller stoppa tjänsten först?
Inbyggda säkerhetskopieringar i Home Assistant kan köras live; vanliga filsystemkopior bör stoppa eller försätta Home Assistant i viloläge, såvida inte databasen säkerhetskopieras på ett...
Varför blir en Home Assistant-server varm eller låter mycket under inaktiva timmar?
Koppla ihop toppar i fläktvarvtal eller temperatur i Home Assistant med Recorder, säkerhetskopieringar, integrationer och samlokaliserade jobb innan du ändrar kylningen eller CPU-begränsningarna.
Hur mycket ledigt lagringsutrymme bör Home Assistant ha för bakgrundsjobb?
Dimensionera Home Assistants lediga utrymme utifrån Recorder-databasen, säkerhetskopieringarnas tillväxt, underhållstoppar och återställningsåtgärder – inte utifrån en universell procentsats.
