Appliquer la règle 3-2-1 à sa configuration Home Assistant

Trois copies, sur deux supports différents, dont une hors site. La règle est connue ; elle est rarement appliquée à une installation domotique, alors que celle-ci représente souvent des dizaines d’heures de réglages.

Le jour où le SSD lâche — et il lâchera —, la différence entre « on restaure en vingt minutes » et « on repart de zéro » tient entièrement à ce qui suit.

Ce que contient réellement une sauvegarde Home Assistant

La sauvegarde intégrée (Paramètres → Système → Sauvegardes) produit une archive qui embarque :

• la configuration : configuration.yaml, automatisations, scripts, scènes, tableaux de bord ;
• la base d’états (l’historique), souvent le plus gros morceau ;
• les modules complémentaires et leur configuration — Zigbee2MQTT, Mosquitto, ESPHome… ;
• les intégrations configurées via l’interface, stockées dans .storage.

Autrement dit : tout ce qui fait votre installation. Une sauvegarde complète restaurée sur une machine neuve redonne une maison fonctionnelle, appairages Zigbee compris si le coordinateur n’a pas changé.

À savoir : l’historique gonfle les archives pour une valeur faible. Réduire la rétention du recorder (purge_keep_days) allège les sauvegardes sans rien perdre d’important.

Pourquoi la copie locale ne compte pas

Par défaut, les sauvegardes s’empilent sur le disque de la machine… qu’elles sont censées protéger. Panne de disque, corruption du système, vol, surtension : la sauvegarde disparaît avec l’original.

La copie locale reste utile — c’est la plus rapide à restaurer après une mauvaise manipulation. Mais dans le décompte 3-2-1, elle vaut pour la copie n°1, pas plus.

Copie n°2 : l’envoi automatique vers un NAS

Home Assistant sait monter un partage réseau (Paramètres → Système → Stockage → « Ajouter un stockage réseau ») et l’utiliser comme destination par défaut des sauvegardes. Avec un NAS Synology, QNAP ou un simple partage Samba sur un autre serveur :

1. créer sur le NAS un partage dédié backups-ha, avec un utilisateur qui n’a accès qu’à ce dossier ;
2. l’ajouter dans Home Assistant en SMB, et le définir comme destination des sauvegardes ;
3. activer la sauvegarde automatique quotidienne, avec une rétention de deux à trois semaines.

Deux supports, deux machines : en cas de panne de l’une, l’autre a la copie.

Copie n°3 : hors site et chiffrée

Le NAS et le serveur brûlent ensemble dans le même incendie et partent ensemble dans le même cambriolage. La troisième copie doit sortir du logement.

Les sauvegardes Home Assistant peuvent être chiffrées à la création — c’est indispensable dès qu’elles quittent la maison, car elles contiennent des secrets (mots de passe Wi-Fi, jetons d’API, clés). Ensuite, deux approches saines :

• synchroniser le dossier de sauvegardes du NAS vers un stockage distant avec un outil type rclone ou la fonction de sauvegarde cloud du NAS ;
• ou répliquer vers un second site que l’on contrôle — le NAS d’un proche, un petit serveur ailleurs — dans l’esprit auto-hébergement du reste de l’installation.

Dans les deux cas, la clé de chiffrement se garde hors de la machine sauvegardée, dans un gestionnaire de mots de passe.

Le test de restauration : la seule étape qui compte

Une sauvegarde jamais restaurée est une hypothèse, pas une sauvegarde. Le test ne demande pas de sacrifier son installation :

1. prendre une machine de test — une VM, un vieux mini-PC, un Raspberry Pi ;
2. installer Home Assistant OS vierge ;
3. au premier écran, choisir « Restaurer depuis une sauvegarde » et charger la dernière archive complète ;
4. vérifier que l’interface revient, que les automatisations sont là, que les modules complémentaires démarrent.

Trente minutes, une fois par an, et le jour de la vraie panne devient une formalité au lieu d’un deuil.

En résumé

La machine qui héberge tout ça mérite elle aussi d’être choisie avec soin : voir l’installation sur mini-PC d’occasion, qui pose les bases de cette stratégie dès le premier jour.