Come ripristinare Home Assistant dopo un aggiornamento del container non riuscito
Un aggiornamento non riuscito del container di Home Assistant dovrebbe generalmente essere considerato un problema di sostituzione del runtime, non un motivo per creare una nuova installazione. Se la directory /config montata dall'host è intatta, il percorso di ripristino più sicuro consiste nel preservare quello stato, verificare la mappatura del volume, avviare un'immagine sicuramente funzionante e testare l'installazione esistente prima di ripristinare un backup precedente.
La mossa più rischiosa è consentire l'avvio di un nuovo container sul percorso host errato o vuoto. Home Assistant potrebbe quindi mostrare la procedura di configurazione iniziale come se la configurazione fosse scomparsa, mentre lo stato originale esiste ancora altrove sul disco. Blocca prima le modifiche, individua la directory di configurazione autorevole e non eliminare il vecchio container o la vecchia directory finché l'istanza ripristinata non supera i test.
Interrompi le nuove scritture e trova il percorso reale di /config
Arresta il container non riuscito e controlla la definizione del runtime che lo ha creato. Verifica quale directory host o volume denominato è mappato su /config, quindi controlla quella posizione per individuare i file YAML, .storage, i componenti personalizzati, i segreti e il database.
Un caso di ripristino della community dopo un aggiornamento di Docker ha rilevato che un'istanza di Home Assistant “completamente nuova” era in realtà causata dal fatto che il container puntava alla cartella di configurazione sbagliata. I dati persistenti non erano stati cancellati: il runtime sostitutivo semplicemente non li montava correttamente.
Copia o crea uno snapshot della directory di configurazione attuale prima di modificare proprietari, percorsi o file del database. Anche uno stato parzialmente danneggiato è una prova preziosa e potrebbe contenere automazioni o credenziali più recenti rispetto all'ultimo backup.
Ricrea il runtime senza ricreare l'installazione
Usa la stessa modalità di rete, lo stesso fuso orario, le stesse mappature dei dispositivi, lo stesso accesso alle radio USB, gli stessi privilegi o le stesse capability e lo stesso montaggio host di /config utilizzati dal container funzionante prima dell'aggiornamento. L'immagine è sostituibile; questi parametri del runtime e i dati persistenti determinano se il servizio tornerà a essere la stessa istanza di Home Assistant.
La persistenza del container dipende dal montaggio dell'host, non dal filesystem del container. Un esempio di Home Assistant Container monta direttamente un volume host persistente su /config, quindi ricreare il runtime non ricrea la configurazione domestica. Se questa mappatura cambia durante un aggiornamento, un container sostitutivo può sembrare nuovo mentre lo stato originale esiste ancora altrove.
Non copiare il filesystem del vecchio container nella nuova immagine. Ricrea la distribuzione a partire da una definizione Compose o da un comando di esecuzione documentato e ricollega esplicitamente lo stato persistente.
Ripristina l'immagine prima di ripristinare uno stato precedente
Se il montaggio della configurazione è corretto ma la nuova versione di Home Assistant non si avvia o interrompe un'integrazione critica, prova l'immagine precedente sicuramente funzionante usando lo stesso /config preservato. In questo modo puoi distinguere tra “il nuovo runtime non è compatibile con lo stato attuale” e “lo stato stesso è danneggiato”.
Il flusso di lavoro attuale di Home Assistant Container separa esplicitamente l'immagine dallo stato persistente: esegui prima il backup, scarica l'immagine di destinazione, ricrea il container e usa un tag specifico di un'immagine precedente quando è necessario effettuare un downgrade. Questo è il confine da preservare durante il ripristino: sostituire il runtime mantenendo intatto il percorso di configurazione autorevole.
Quando esegui il rollback, ricorda che alcuni aggiornamenti migrano le strutture dei dati. Usa un backup creato prima della migrazione se la versione precedente non è in grado di leggere in sicurezza uno stato già aggiornato dalla versione più recente. Non alternare ripetutamente le versioni usando l'unica copia dei dati persistenti.
Ripristina un backup solo quando lo stato attuale non è affidabile
Usa un backup quando la configurazione persistente è mancante, danneggiata, parzialmente sovrascritta o non più compatibile con la versione che puoi eseguire in sicurezza. Quando possibile, esegui il ripristino in una destinazione isolata o pulita, così potrai confrontare lo stato recuperato con la copia danneggiata.
Conserva la password di crittografia o il kit di emergenza necessario per aprire il backup al di fuori dell'host non funzionante. Un backup presente solo sullo stesso disco o che non può essere decrittografato non costituisce un percorso di ripristino.
L'esempio di ZimaSpace che mostra la separazione del ripristino di Home Assistant dall'host di archiviazione stesso rafforza la stessa regola: lo stato dell'applicazione necessita di un percorso di ripristino indipendente, non soltanto di un disco live replicato.
Convalida il container ripristinato prima di eliminare qualsiasi elemento
- Conferma che siano presenti gli utenti, i pannelli di controllo, le integrazioni, le automazioni, gli helper e le aree previsti.
- Verifica un percorso per un dispositivo locale e uno basato su radio se utilizzi Zigbee, Z-Wave o Bluetooth.
- Controlla nel Recorder la presenza di errori del database o di migrazione.
- Riavvia il container ripristinato e conferma che ritorni lo stesso stato.
- Conserva il tag della vecchia immagine, la copia della configurazione e l'ultimo backup sicuramente funzionante finché anche questo secondo avvio non sarà superato.
Se la vecchia immagine funziona con la configurazione originale, l'aggiornamento non riuscito era principalmente un problema di runtime o di versione. Se nessuna immagine funziona con lo stesso stato, passa alla riparazione della configurazione o al ripristino da backup. Se un container pulito funziona solo con un /config vuoto, non accettare la nuova configurazione come “risolta” finché non avrai compreso quale elemento dello stato persistente impedisce il ripristino.
Domande frequenti
Devo eliminare il container di Home Assistant non riuscito prima di iniziare la diagnostica?
No. Arrestalo prima e conserva la definizione del runtime e il percorso di configurazione montato. Puoi creare un container sostitutivo senza eliminare quello non riuscito, mantenendo così disponibili le informazioni per il rollback mentre verifichi il nuovo runtime.
Perché Home Assistant mostra la procedura di configurazione iniziale dopo un aggiornamento?
Il motivo più comune specifico dei container è che il runtime sostitutivo non riesce a vedere il percorso originale di /config. Verifica il montaggio sull'host prima di presumere che la configurazione sia stata cancellata o di ripristinare un backup precedente sopra uno stato più recente.
Prodotti consigliati
Supporto e consigli
Altro da leggere
È meglio eseguire il backup di Home Assistant mentre è in funzione o arrestare prima il servizio?
I backup integrati di Home Assistant possono essere eseguiti a caldo; le semplici copie del file system dovrebbero arrestare o mettere in pausa Home...
Perché un server Home Assistant diventa caldo o rumoroso durante le ore di inattività?
Metti in correlazione i picchi della ventola o della temperatura di Home Assistant con Recorder, i backup, le integrazioni e i processi eseguiti sullo...
Quando dovresti ricostruire Home Assistant invece di ripararlo?
Ripara prima il livello di Home Assistant guasto più piccolo, ripristina poi uno stato noto e funzionante, e ricostruisci solo quando non è possibile...
