Kan Home Assistant köras på ARM och x86 med samma data?

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.

Ja, Home Assistant-data kan vanligtvis flyttas mellan ARM och x86 via en stödd säkerhetskopierings- och återställningsprocess, men det återställda systemet är säkert först när arkitekturberoende komponenter har klarat valideringen.

Konfiguration, register, instrumentpaneler, automatiseringar och historik är i regel portabla data, medan tilläggsbilder, anpassade binärfiler, USB-radioenheter, värddrivrutiner, enhetssökvägar och installationsmetoder kan skilja sig åt. Återställ till ett isolerat mål, håll den gamla styrenheten avstängd men möjlig att återställa och testa exakt de integrationer och den arbetsbelastning för enhetsstyrning som används innan du betraktar arkitekturbytet som slutfört.

Skilj portabla data från arkitekturberoende komponenter

Inventera källan före migreringen: installationstyp, Core- och OS-versioner, tillägg, anpassade integrationer, extern databas, USB-radioenheter, nätverksadresser, monteringar, hemligheter och säkerhetskopians storlek. Markera varje komponent som innehåller inbyggd kod eller använder värdmaskinens hårdvara som arkitekturkänslig.

En migrering från x86-64 till ARM i communityn visar vilken fråga som är rätt: säkerhetskopian kan innehålla samma konfiguration, men tillägg måste fortfarande ha kompatibla avbildningar för målarkitekturen. Behandla stöd för tilläggsarkitektur som en komponentkontroll, inte som bevis på att varje migrering är utbytbar.

Om ett nödvändigt tillägg eller en anpassad komponent saknar en version för målet ska du stoppa före övergången och ersätta den med en kompatibel tjänst eller låta den rollen ligga kvar någon annanstans. Om alla kritiska komponenter anger kompatibla paket fortsätter du med en kontrollerad återställning i stället för att kopiera en aktiv katalog mellan värdar.

Återställ till ett isolerat mål utan att skapa två styrenheter

Skapa och ladda ner en ny krypterad säkerhetskopia, spara nyckeln separat och anteckna källversionen. Installera målet med rätt ARM- eller x86-avbildning och återställ sedan medan källstyrenheten är avstängd eller isolerad från produktionsenheter, så att dubbla kommandon inte skickas.

Rapporter från communityn beskriver lyckade återställningar från ARM till x86 när säkerhetskopian återställs på den nya installationen och nätverksidentiteten hanteras noggrant. Det användbara beviset är en arkitekturmigrering baserad på säkerhetskopia, inte en garanti för att varje USB-radioenhet och varje tillägg följer med automatiskt.

Håll målet på en tillfällig adress tills du har bekräftat att det återställde förväntade användare, instrumentpaneler, automatiseringar, entiteter, historik och integrationer. Om målet startar tomt eller visar introduktionsguiden ska du stoppa och kontrollera valet av säkerhetskopia, krypteringsnyckeln, återställningsstatusen och lagringskapaciteten innan du ändrar nätverket.

Validera tillägg, radioenheter, sökvägar och nätverksidentitet

Öppna alla kritiska tillägg och bekräfta att de kör en avbildning för målarkitekturen. Anslut USB-radioenheter en i taget, identifiera dem med en stabil enhetssökväg när det är möjligt och verifiera Zigbee-, Z-Wave-, Bluetooth-, serie- och andra hårdvaruintegrationer utan att para om enheter i förtid.

Kontrollera värdmonteringar, externa databaser, brokeradresser, DNS-namn, certifikat samt rutter för omvänd proxy eller VPN. Den relaterade ZimaSpace-artikeln om rollerna för beständiga Home Assistant-data hjälper dig att skilja det som säkerhetskopian hanterar från tillstånd som fortfarande finns i en extern tjänst.

Om endast en hårdvaruberoende integration fungerar felaktigt ska du behålla de återställda Core-data och reparera den gränsen. Om ett större delen av tillståndet saknas ska du återställa den tidigare installationen i stället för att återskapa enheter manuellt. Bevara den gamla värden oförändrad tills du vet om felet gäller en specifik komponent eller hela säkerhetskopian.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Fatta beslutet om körning eller avbrytande under den ursprungliga arbetsbelastningen

Kör den mest belastande normala automatiseringssekvensen, öppna historiken, använd instrumentpanelerna och testa lokal samt fjärråtkomst. Bekräfta att tillståndsändringar når riktiga enheter en gång och endast en gång, att Recorder fortsätter att skriva, att aviseringar kommer fram och att CPU- och lagringsbelastningen stabiliseras efter starten.

Starta om målet två gånger och testa igen efter schemalagda jobb och uppdateringar av tillägg. En lyckad migrering klarar dessa omstarter med samma entitetsidentiteter, radionätverk, historik och externa beroenden. Arkitekturens portabilitet bevisas av funktionen, inte av en lyckad inloggning.

Gå tillbaka till den gamla värden om en kritisk komponent utan stöd saknar en säker ersättning, men kör aldrig båda styrenheterna mot samma enhetsnätverk under en återställning. Eskalera med käll- och målarkitektur, installationstyper, versioner, namn på tilläggsbilder och enhetssökvägar när endast det arkitekturberoende lagret fortfarande är olöst.