13. Backup e disaster recovery

Il momento in cui capirai perché serve una strategia di backup è il momento in cui non ce l’hai più. La scheda SD si rompe di venerdì sera, l’aggiornamento fallisce, il disco del server muore. Dopo mesi di configurazione, automazioni, integrazioni, dashboard, ricominciare da zero è un lavoro di giorni. In questo capitolo vediamo cosa contiene un backup di HA, dove salvarlo (perché sulla stessa macchina è peggio che niente), come automatizzare la creazione e come testare che il backup si restore davvero, che poi è la parte che quasi nessuno fa.

Cosa contiene un backup di HA

Un backup Supervisor di Home Assistant contiene:

• Cartella <config>, cioè tutta la configurazione: configuration.yaml, automazioni, script, scene, dashboards, .storage/ (registry, entità, dispositivi, aree), i file di HACS custom_components.
• Cartella addons/: gli add-on installati.
• Cartella media/: file media (snapshot camera, TTS cache, se configurati)
• Configurazione di sistema: utenti HA, integrazioni installate, network settings.
• Dati degli add-on selezionati: es. il database di Mosquitto, le config di ESPHome, la cronologia di Node-RED.

Non contiene:

• Il DB della history di HA (home-assistant_v2.db) non viene incluso nei backup automatici per non appesantirli, quindi perdi la cronologia dei valori dei sensori (ma non le automazioni o gli stati correnti). Se ti serve, includilo esplicitamente.
• Dati esterni: se HA punta a un database MariaDB su un altro server, quel server va backuppato a parte.

Backup dalla UI: partial vs full

Impostazioni → Sistema → Backup → Crea backup.

Ti offre:

• Full backup (default): tutto quanto sopra, esclusa la history DB.
• Partial backup: scegli cosa includere (solo config, solo alcuni add-on, ecc).

Un full backup di un’installazione media pesa 100-500 MB. Se lo comprimi (opzione nel dialogo) e non includi la history DB, resta compatto.

Il backup si salva di default in /backup/ sulla macchina HA. Che è il problema principale: se il disco muore, muore anche il backup.

Il problema del “backup locale”

Un backup che sta sulla stessa macchina che vuoi backuppare non è un backup. È al più uno snapshot per il rollback rapido dopo un errore di configurazione.

Un vero backup deve stare:

• Su un dispositivo fisicamente diverso (NAS di casa, altro server, cloud).
• Almeno due copie, in due posti diversi. Regola 3-2-1: 3 copie totali, 2 supporti diversi, 1 offsite.
• Testato: sapere che il file esiste non basta, va provato il restore ogni tanto.

Il minimo indispensabile per HA: una copia locale + una off-site (NAS o cloud).

Automated Backup addon

Il modo standard per automatizzare i backup è l’add-on Automated Backup (HACS supervisor add-ons store).

Cosa fa:

• Crea un backup a orario stabilito (default ogni notte).
• Applica una retention policy (es. tieni gli ultimi 7 giornalieri + 4 settimanali).
• Cancella i backup vecchi oltre la retention (evitando di riempire il disco).

Configurazione tipica:

generational: true
days: 3          # tieni 3 giornalieri
weeks: 4         # tieni 4 settimanali
months: 3        # tieni 3 mensili

Combinato con un secondo add-on per la copia off-site (vedi sotto) ottieni un ciclo di backup che gira da solo.

Copia off-site: dove metterlo

Le opzioni tipiche, dalla più semplice alla più robusta.

Samba backup / NFS backup addon

L’add-on Samba backup (o l’equivalente NFS) monta una share di un NAS, e ogni volta che HA crea un backup, ne copia una copia lì. Combinato con Automated Backup, ottieni: backup notturno → copia sul NAS.

Setup: aggiungi la share (indirizzo, credenziali, cartella) alla config dell’add-on, resta in ascolto e copia ogni backup nuovo.

Google Drive Backup

Un add-on molto usato: Google Drive Backup (community). Fa esattamente quello che dice: sync dei backup HA su Google Drive personale, con retention configurabile. Setup OAuth iniziale, poi va da solo.

Vantaggio: cloud, quindi off-site vero. Rimane offsite anche se ti bruciano casa. 15 GB gratuiti bastano per anni di HA backup.

Nabu Casa Cloud

Se hai Nabu Casa (il servizio a pagamento di Home Assistant, 6.5€/mese) hai anche 5 GB di backup cloud integrato, con setup zero. Meno spazio del Google Drive ma zero attrito.

rsync su altro server

Per chi ha già un secondo server (Raspberry di supporto, NAS con SSH), un semplice rsync schedulato dal cron di HA copia /backup/* sull’altro server. È lo scenario più “old school” ma è affidabile e sotto controllo tuo.

Restore: il momento della verità

Un backup che non hai mai testato non è un backup. È un file speranzoso.

Modi per testare:

Su una VM di test. Il migliore. Su un PC, un NUC, un mini-PC, installi HAOS in una VM VirtualBox/Proxmox/UTM. Prendi il backup più recente della produzione, lo restore sulla VM. Se HA parte, se vedi le tue automazioni, se puoi controllare (fake) i tuoi device: il backup è buono.

Fallo almeno una volta ogni 3 mesi. Meglio scoprire un backup rotto oggi che il giorno che ne hai bisogno.

Sulla produzione (con cautela). Se non hai VM, puoi restore un backup vecchio sulla produzione stessa (Impostazioni → Sistema → Backup → click sul backup → Ripristina). Attenzione: sostituisce lo stato attuale con quello del backup. Fai prima un backup di quello che c’è ora, così puoi tornare indietro se il vecchio non parte.

Restore parziale. Se non hai bisogno di sostituire tutto (es. solo un add-on rotto), puoi ripristinare solo quella parte del backup senza toccare il resto.

Cosa fare se HA non parte più dopo un aggiornamento

Scenario tipico: aggiornamento HA fallito, sistema in loop di boot o schermata bianca.

1. Prima di tutto, ferma e respira. Non fare altre modifiche, non riavviare in loop.
2. Se HA si avvia in “safe mode” (recovery mode), da lì hai accesso ai backup: restore l’ultimo funzionante.
3. Se HA non si avvia proprio, monti la scheda SD / il disco su un PC, copi la cartella /backup/ da qualche parte, poi reinstalli HAOS pulito, restore il backup.
4. Se hai anche una copia offsite del backup, sei tranquillo anche se la scheda SD è distrutta: reinstalla su hardware nuovo, restore dal cloud, sei operativo.

Cosa NON è coperto dai backup HA

• Configurazione del router / firewall / reverse proxy: HA non li conosce. Fai backup delle loro config a parte.
• Certificati SSL (se non gestiti da HA): idem.
• Firmware dei device Zigbee/Z-Wave: dovrai reimportare i device manualmente sulla rete Zigbee/Z-Wave dopo un restore su hardware nuovo (a meno che tu abbia il coordinator backup).
• Database esterno (se usi MariaDB fuori HA): backup a parte.
• Il tuo blueprint mentale della configurazione: come funzionano le automazioni, perché sono state fatte così. → serve documentazione (vedi 17 Pratiche di buon uso).

La configurazione della retention

Un errore comune è “tengo tutti i backup, mai si sa mai”. Risultato: 200 backup che occupano 50 GB e nessuna storia usabile.

Meglio una policy generazionale:

• 7 daily: recupero rapido di errori recenti.
• 4 weekly: recupero di “settimana scorsa avevo qualcosa che funzionava”.
• 3 monthly: recupero di “prima del grande refactoring”.

Automated Backup gestisce questa policy nativamente. Totale: 14 backup vs 200, con copertura molto più significativa nel tempo.

Ricapitolando

• Un backup HA contiene config, add-on, dati sensibili di sistema; non contiene la history DB di default.
• Backup locale = non è un backup. Serve almeno una copia off-site (NAS, Google Drive, Nabu Casa Cloud).
• Automated Backup addon + Samba/Google Drive/Nabu = ciclo automatico.
• Testa il restore ogni 3 mesi. Un backup non testato è un file speranzoso, non un backup.
• Policy generazionale (7d + 4w + 3m) copre meglio con meno file.
• Prima di ogni major update di HA, backup manuale, poi update: se qualcosa si rompe, restore in pochi minuti.