Så återställer du Home Assistant efter en misslyckad containeruppdatering

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How to Restore Home Assistant After a Failed Container Update - Zima Store Online

En misslyckad uppdatering av en Home Assistant-container bör vanligtvis hanteras som ett problem med att ersätta körmiljön, inte som en anledning att skapa en ny installation. Om den värdmonterade /config-katalogen är intakt är den säkraste återställningsvägen att bevara det tillståndet, verifiera volymmappningen, starta en välfungerande avbild och testa den befintliga installationen innan du återställer en äldre säkerhetskopia.

Det farliga är att låta en ny container starta mot en felaktig eller tom sökväg på värden. Home Assistant kan då visa onboarding som om konfigurationen hade försvunnit, medan det ursprungliga tillståndet fortfarande finns någon annanstans på disken. Frys ändringar först, identifiera den auktoritativa konfigurationskatalogen och radera inte den gamla containern eller katalogen förrän den återställda instansen har godkänts.

Stoppa nya skrivningar och hitta den riktiga sökvägen till /config

Stoppa den misslyckade containern och granska körningsdefinitionen som skapade den. Bekräfta vilken katalog på värden eller namngiven volym som är mappad till /config, och kontrollera sedan den platsen efter dina YAML-filer, .storage, anpassade komponenter, hemligheter och databas.

I ett återställningsfall i communityn efter en Docker-uppgradering visade det sig att en ”helt ny” Home Assistant-instans faktiskt berodde på att containern pekade på fel konfigurationsmapp. De beständiga data hade inte raderats; den ersatta körmiljön monterade dem helt enkelt inte korrekt.

Kopiera eller skapa en ögonblicksbild av den aktuella konfigurationskatalogen innan du ändrar ägarskap, sökvägar eller databasfiler. Även ett delvis skadat tillstånd är värdefull information och kan innehålla nyare automationer eller autentiseringsuppgifter än den senaste säkerhetskopian.

Återskapa körmiljön utan att återskapa installationen

Använd samma nätverksläge, tidszon, enhetsmappningar, åtkomst till USB-radioenheter, privilegier eller funktioner samt samma montering av /config från värden som den fungerande containern använde före uppdateringen. Avbilden kan ersättas; dessa körningsinställningar och de beständiga data avgör om tjänsten återkommer som samma Home Assistant-instans.

Beständighet i containrar beror på monteringen från värden, inte på containerns filsystem. Ett exempel för Home Assistant Container monterar en beständig volym från värden direkt på /config, så att återskapandet av körmiljön inte återskapar hushållets konfiguration. Om den mappningen ändras under en uppdatering kan en ersättningscontainer se ny ut, medan det ursprungliga tillståndet fortfarande finns någon annanstans.

Kopiera inte det gamla containerfilsystemet till den nya avbilden. Återskapa driftsättningen från en dokumenterad Compose- eller kördefinition och anslut det beständiga tillståndet uttryckligen.

Rulla tillbaka avbilden innan du återställer ett äldre tillstånd

Om konfigurationsmonteringen är korrekt men den nya versionen av Home Assistant inte startar eller förstör en viktig integration, testar du den tidigare välfungerande avbilden mot samma bevarade /config. Då kan du skilja på ”den nya körmiljön är inkompatibel med det aktuella tillståndet” och ”själva tillståndet är skadat”.

Det aktuella arbetsflödet för Home Assistant Container skiljer uttryckligen avbilden från det beständiga tillståndet: säkerhetskopiera först, hämta målavbilden, återskapa containern och använd en specifik äldre avbildstagg när en nedgradering krävs. Det är denna återställningsgräns du ska bevara: ersätt körmiljön medan du behåller den auktoritativa konfigurationssökvägen intakt.

Kom ihåg vid återställning att vissa uppgraderingar migrerar datastrukturer. Använd en säkerhetskopia från före migreringen om den äldre versionen inte kan läsa ett tillstånd som redan har uppgraderats av den nyare versionen på ett säkert sätt. Växla inte upprepade gånger mellan versioner mot den enda kopian av de beständiga data.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Återställ en säkerhetskopia endast när det aktuella tillståndet inte är tillförlitligt

Använd en säkerhetskopia när den beständiga konfigurationen saknas, är skadad, delvis överskriven eller inte längre är kompatibel med den version du kan köra på ett säkert sätt. Återställ om möjligt till ett isolerat eller rent mål så att du kan jämföra det återställda tillståndet med den skadade kopian.

Förvara krypteringslösenordet eller nödpaketet som krävs för att öppna säkerhetskopian utanför den felande värden. En säkerhetskopia som endast finns på samma disk, eller som inte kan dekrypteras, ger ingen återställningsväg.

Exemplet med ZimaSpace där man separerar återställningen av Home Assistant från själva lagringsvärden förstärker samma regel: applikationstillstånd behöver en oberoende återställningsväg, inte bara en speglad aktiv disk.

Validera den återställda containern innan du raderar något

Bekräfta att förväntade användare, instrumentpaneler, integrationer, automationer, hjälpare och områden finns på plats.
Verifiera en lokal enhetssökväg och en radiobaserad sökväg om Zigbee, Z-Wave eller Bluetooth används.
Kontrollera Recorder efter databas- eller migreringsfel.
Starta om den återställda containern och bekräfta att samma tillstånd återkommer.
Behåll den gamla avbildstaggen, konfigurationskopian och den senaste välfungerande säkerhetskopian tills den andra uppstarten har godkänts.

Om den gamla avbilden fungerar med den ursprungliga konfigurationen var den misslyckade uppdateringen främst ett problem med körmiljön eller versionen. Om ingen avbild fungerar mot samma tillstånd går du vidare med konfigurationsreparation eller återställning från säkerhetskopia. Om en ren container endast fungerar med en tom /config ska du inte acceptera den nya konfigurationen som ”åtgärdad” förrän du förstår vad i det beständiga tillståndet som hindrar återställningen.

Vanliga frågor

Bör jag radera den misslyckade Home Assistant-containern innan jag felsöker?

Nej. Stoppa den först och bevara dess körningsdefinition och monterade konfigurationssökväg. Du kan skapa en ersättningscontainer utan att radera den misslyckade, vilket håller information för återställning tillgänglig medan du verifierar den nya körmiljön.

Varför visar Home Assistant onboarding efter en uppdatering?

Den vanligaste containerspecifika orsaken är att den ersatta körmiljön inte hittar den ursprungliga /config-sökvägen. Verifiera monteringen från värden innan du antar att konfigurationen har raderats eller återställer en äldre säkerhetskopia ovanpå ett nyare tillstånd.