Quando dovresti ricostruire Home Assistant invece di ripararlo?
Ricostruisci Home Assistant solo quando lo stato persistente attuale non è più una fonte affidabile per il ripristino e un ripristino verificato non riesce a rendere nuovamente operativo il sistema. La maggior parte dei guasti dovrebbe essere prima classificata come problema di runtime, integrazione, configurazione, database, archiviazione o rete e risolta al livello più circoscritto possibile.
Una reinstallazione non equivale automaticamente a una ricostruzione. La sostituzione di un’immagine del container può lasciare intatto /config, mentre una vera ricostruzione crea uno stato applicativo nuovo e richiede di ripristinare o ricreare integrazioni, dispositivi, dashboard, helper e automazioni. Prendi questa decisione in base alle condizioni dello stato, non alla frustrazione causata dal sintomo attuale.
Usa tre azioni diverse: riparare, ripristinare, ricostruire
La riparazione mantiene la configurazione attuale e corregge il componente guasto. Il ripristino sostituisce lo stato danneggiato o incompatibile con un backup verificato. La ricostruzione parte da un’installazione pulita di Home Assistant e importa o ricrea solo lo stato di cui ti fidi deliberatamente.
Questa distinzione evita che un problema del container o del pacchetto si trasformi in una perdita di dati non necessaria. Se utenti, aree, dispositivi e automazioni attuali sono ancora presenti, una nuova installazione potrebbe distruggere più informazioni affidabili di quante ne ripari.
Annota quale delle tre azioni stai eseguendo prima di modificare i file. Questa semplice etichetta rende più difficile passare accidentalmente dalla riparazione a un ripristino distruttivo.
Ripara prima quando lo stato persistente è ancora coerente
La riparazione è appropriata quando Home Assistant apre l’istanza prevista, la directory di configurazione è popolata e l’errore può essere ricondotto a un’integrazione specifica, a una modifica YAML, a un componente personalizzato, a un file del database, a un punto di montaggio o a un’impostazione del runtime.
La Modalità provvisoria e la Modalità di ripristino esistono proprio perché molti errori di avvio possono essere circoscritti senza abbandonare la configurazione. Una guida aggiornata al ripristino consiglia di leggere l’errore di avvio esatto, usare la Modalità provvisoria per isolare il codice personalizzato e usare la Modalità di ripristino come percorso di riparazione minimo prima di ricostruire.
Disabilita o aggiorna una sola integrazione personalizzata, correggi una voce di configurazione non valida, ripara il percorso di archiviazione o ripristina la versione del runtime, quindi esegui nuovamente il test. Non reimpostare l’intera installazione finché il problema resta circoscritto.
Ripara il database solo se vale la pena salvare la cronologia
La corruzione del Recorder può sembrare grave perché i log si riempiono di errori del database, ma il database del Recorder non coincide con l’intera configurazione di Home Assistant. Se la configurazione attuale e le integrazioni sono integre, un nuovo database della cronologia può talvolta essere meno rischioso di una ricostruzione completa dell’applicazione.
Quando la cronologia è importante, una guida pratica al ripristino mostra come arrestare Home Assistant e usare gli strumenti di ripristino di SQLite per ricostruire il database danneggiato di Home Assistant in un nuovo file.
Lavora solo su copie, conserva il database originale danneggiato e accetta che il ripristino possa essere parziale. Una riparazione della cronologia non riuscita non dovrebbe diventare un motivo per scartare automazioni e integrazioni sane.
Ripristina quando un backup verificato è più sicuro che continuare a riparare
Esegui un ripristino quando il guasto è iniziato dopo un aggiornamento o una modifica identificabile e disponi di un backup verificato precedente a tale cambiamento. Spesso è più rapido e sicuro che annullare manualmente decine di file migrati o modificati parzialmente.
Una guida di ripristino di Home Assistant, disponibile da tempo, consiglia innanzitutto di correggere la causa del guasto e poi di ripristinare un backup copiato lontano dal sistema guasto. Ripristinare senza rimuovere l’alimentatore difettoso, il problema del disco, il punto di montaggio errato o il runtime incompatibile significa semplicemente ricreare l’incidente.
Conserva lo stato danneggiato finché il sistema ripristinato non supera i controlli. Potrebbe contenere automazioni, segreti o modifiche alla configurazione recenti da confrontare o recuperare selettivamente.
Ricostruisci quando lo stato e gli elementi di ripristino non sono più affidabili
Una ricostruzione pulita diventa ragionevole quando la directory di configurazione è mancante o ampiamente corrotta, più backup non superano i test di ripristino, la definizione del runtime è sconosciuta oppure le riparazioni ripetute lasciano l’installazione in uno stato non documentato e impossibile da riprodurre.
La ricostruzione può essere anche la scelta più ordinata quando abbandoni una distribuzione strutturata male, ad esempio una configurazione importante intrappolata all’interno di un container usa e getta, purché prima esporti ogni elemento affidabile dello stato che riesci a recuperare.
La guida di ZimaSpace sull’automazione locale sottolinea la possibilità di recupero come requisito fondamentale di una piattaforma per la casa intelligente. Una ricostruzione ha successo solo quando la nuova installazione è più facile da sottoporre a backup, ripristinare e gestire rispetto allo stato abbandonato.
Usa una tabella decisionale prima di eliminare il vecchio stato
| Condizione | Azione preferita |
|---|---|
| Errore di una singola integrazione o configurazione | Riparazione |
| Aggiornamento del runtime o dell’immagine non riuscito, configurazione intatta | Riparazione o ripristino del runtime |
| Database danneggiato, configurazione integra | Riparazione/sostituzione del database |
| Backup verificato precedente a un danno esteso | Ripristino |
| Configurazione e backup non affidabili o impossibili da riprodurre | Ricostruzione |
Non eliminare la vecchia configurazione, il database o l’insieme dei backup finché il percorso scelto non ha superato un riavvio e un normale ciclo di utilizzo domestico.
Domande frequenti
La reinstallazione del container di Home Assistant equivale a una ricostruzione?
No. Se il container sostitutivo si ricollega alla stessa directory persistente /config, hai sostituito il runtime mantenendo lo stesso stato dell’installazione. Una ricostruzione inizia con uno stato nuovo oppure abbandona deliberatamente quello precedente.
Devo ricostruire Home Assistant perché il database del Recorder è corrotto?
Di solito no. La cronologia del Recorder può essere riparata, ripristinata o sostituita separatamente dal resto di Home Assistant. Ricostruisci l’intera installazione solo quando non sono più affidabili la configurazione e lo stato di ripristino, non soltanto la cronologia.
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...
Quanto spazio di archiviazione libero dovrebbe conservare Home Assistant per i processi in background?
Dimensiona lo spazio libero di Home Assistant in base al database Recorder, alla crescita dei backup, ai picchi di manutenzione e alle operazioni di...
