Come evitare che i backup di Home Assistant acquisiscano uno stato incoerente del database

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Prevent Home Assistant Backups From Capturing Inconsistent Database State - Zima Store Online

Evita backup incoerenti di Home Assistant lasciando che l’applicazione coordini lo stato attivo del database oppure interrompendo le scritture prima di una copia del filesystem non elaborata.

Il caso rischioso non è semplicemente “eseguire il backup mentre Home Assistant è acceso”; è un metodo di copia che acquisisce i file correlati del database e dell’applicazione in momenti diversi senza conoscerne lo stato delle transazioni. I backup integrati possono coordinare i componenti di Home Assistant, mentre uno strumento generico come rsync o uno snapshot potrebbe non farlo. Definisci quale meccanismo garantisce la coerenza, evita la sovrapposizione di attività che coinvolgono intensamente il database, conserva il backup precedente valido e verifica ogni criterio con un ripristino isolato.

Non trattare un database SQLite attivo come un normale file statico

Recorder di Home Assistant può essere in fase di scrittura mentre un processo di backup generico copia la directory di configurazione. Con SQLite, lo stato confermato può coinvolgere il database principale e i file journal o WAL; acquisire momenti non corrispondenti può creare una copia incompleta o irrecuperabile, anche se nell’archivio sono presenti tutti i nomi dei file.

Un test di backup di un database SQLite attivo ha mostrato che copiare solo il file principale del database può omettere silenziosamente righe confermate ancora presenti nel WAL, anche quando il database copiato supera un controllo di integrità. Questo problema della copia basata sul WAL è il motivo per cui una copia grezza dei file dovrebbe utilizzare uno snapshot consapevole del database oppure essere eseguita solo dopo aver portato il database in uno stato ordinatamente inattivo.

Questo non significa che Home Assistant debba essere sempre arrestato per il backup. Significa che il meccanismo di backup deve sapere come creare un punto di ripristino coerente. Usa il backup integrato di Home Assistant per un’installazione in esecuzione; riserva le copie del filesystem a servizio arrestato alle migrazioni, all’archiviazione offline o agli strumenti esterni privi di integrazione consapevole dell’applicazione.

Evita attività di backup o manutenzione concorrenti nella stessa finestra

Anche un backup consapevole dell’applicazione può non riuscire a preparare il database quando un altro processo mantiene dei blocchi o quando il percorso di archiviazione è sottoposto a una manutenzione insolita. Non pianificare l’avvio, allo stesso minuto, di un secondo backup di un add-on, della manutenzione del database, di uno snapshot NAS e del backup di Home Assistant solo perché in casa regna la calma.

I fallimenti reali dei backup di Home Assistant riportano errori nella preparazione del blocco del database e un utente ha ricondotto un conflitto a un altro add-on di backup. È un segnale utile per la prevenzione: separa gli strumenti sovrapposti e verifica nei log dell’applicazione che la fase preliminare al backup sia completata.

Scagliona le finestre di manutenzione e registra la durata prevista. Se un backup attende regolarmente Recorder, individua prima il processo che detiene il blocco o il problema di integrità del database. Non aumentare i timeout alla cieca e non eseguire più copie in parallelo: un numero maggiore di attività di backup può aumentare proprio la contesa che stai cercando di evitare.

Per le copie grezze del filesystem, arresta Home Assistant e conserva l’intero insieme di dati

Se la tua policy richiede una copia diretta della directory di configurazione, arresta correttamente Home Assistant prima di copiarla, verifica che il processo non stia più scrivendo e copia tutti i dati richiesti invece di selezionare solo il file principale del database. Conserva i backup dei database esterni secondo un metodo di coerenza separato.

Il confronto esistente di ZimaSpace tra backup di Home Assistant attivo e arrestato traccia lo stesso confine: il backup attivo consapevole dell’applicazione e la copia grezza del filesystem sono procedure diverse e non dovrebbero essere combinati in un’unica regola.

Dopo la copia, riavvia il servizio e verifica il normale funzionamento di Recorder. Se la destinazione del backup è un archivio di rete, verifica anche che l’insieme di file sia stato copiato completamente prima della rimozione del montaggio di rete. Una copia arrestata interrotta a metà è coerente solo nel senso ristretto che la sorgente era inattiva; non è comunque un punto di ripristino completo.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Considera affidabile il backup solo dopo un ripristino isolato riuscito

Crea un’istanza temporanea di Home Assistant o una destinazione di ripristino e ripristina il backup candidato senza prendere in prestito file modificabili dall’ambiente di produzione. Verifica gli utenti esistenti, i dati storici, i pannelli, le integrazioni, le definizioni delle automazioni e almeno un riavvio. Registra il tempo di ripristino e tutte le correzioni manuali necessarie per rendere utilizzabile l’istanza.

Una regressione di Home Assistant Core limitata alla versione 2026.7.2 ha registrato il fallimento del checkpoint WAL di Recorder durante la fase preliminare al backup, dopodiché il gestore dei backup è andato in timeout in attesa del blocco del database. Questo segnale di errore preliminare al backup dovrebbe essere considerato solo una prova relativa a quel percorso specifico e un punto di ripristino non riuscito, non la dimostrazione che ogni timeout del blocco abbia la stessa causa.

La policy è valida quando un solo meccanismo di backup garantisce la coerenza alla volta, la fase di preparazione del database viene completata, la copia precedente sicuramente valida viene conservata e un ripristino riproduce utenti, cronologia, impostazioni e il normale comportamento al riavvio. Se il test di ripristino fallisce, conserva le prove e crea un nuovo backup supportato o una copia controllata a servizio arrestato prima di eliminare i punti di ripristino più vecchi.