Quels sont les rôles des données persistantes de Home Assistant et pourquoi sont-ils importants ?
Les données persistantes de Home Assistant sont plus faciles à gérer lorsqu’elles sont réparties par rôle plutôt que traitées comme une seule « configuration » indifférenciée. Certaines données définissent l’identité et le comportement de la maison connectée, d’autres stockent les observations historiques, certaines contiennent des identifiants, et d’autres encore servent uniquement à reconstruire l’environnement d’exécution de Home Assistant.
Ces rôles sont importants, car leur valeur en matière de récupération diffère. Perdre un mois d’historique n’est pas la même chose que perdre le registre des entités, et recréer une image Docker n’est pas la même chose que recréer les mappages des appareils, les secrets ou la configuration qui régit les automatisations du foyer.
La configuration et l’état des registres définissent l’installation
L’arborescence de configuration persistante contient le YAML, le stockage géré via l’interface, la configuration des intégrations, les tableaux de bord, les assistants, les registres des appareils et des entités, les composants personnalisés et d’autres fichiers qui distinguent une instance Home Assistant donnée d’une installation vierge.
La persistance des conteneurs dépend du stockage de l’état en dehors de la couche inscriptible du conteneur. Les recommandations actuelles de Docker concernant le stockage expliquent que les volumes et les montages de liaison conservent les données de l’application indépendamment du cycle de vie du conteneur. L’image peut être recréée ; on ne peut pas supposer que les données propres au foyer réapparaîtront.
Ce rôle nécessite une sauvegarde prudente, une migration contrôlée et une procédure de restauration connue. Il ne doit pas partager une politique de nettoyage avec le cache ou les couches de conteneur jetables.
L’historique du Recorder est une donnée précieuse, mais ce n’est pas la configuration
Le Recorder stocke les états, événements et statistiques historiques utilisés par l’Historique, le Journal, les tableaux de bord et les analyses. Ces données peuvent être importantes, notamment pour l’énergie, les tendances environnementales ou le dépannage, mais Home Assistant peut toujours représenter l’état actuel sans conserver indéfiniment tout l’historique brut.
La séparation de l’historique et de l’identité modifie les décisions de récupération. Une base de données Recorder corrompue ou excessivement volumineuse peut justifier une réparation, une restauration, voire une recréation de l’historique sans supprimer les automatisations et la configuration des intégrations en bon état.
Les données historiques ont besoin de leur propre cycle de vie : le taux d’échantillonnage, la durée de conservation, les agrégations, les index et les générations de sauvegarde déterminent la croissance du stockage indépendamment du nombre de règles d’automatisation. Gérez ces décisions de conservation séparément de l’état de configuration et des registres qui définissent l’installation.
Les secrets et les clés de récupération répondent à un autre contrat de défaillance
Les identifiants, jetons, certificats, clés de chiffrement et éléments d’urgence nécessaires aux sauvegardes peuvent être peu volumineux, mais avoir une grande valeur pour la récupération. Une sauvegarde qui ne peut pas être déchiffrée, ou une intégration restaurée dépourvue d’identifiants valides, peut rendre le système partiellement inutilisable.
La stratégie de sauvegarde de Home Assistant recommande explicitement de conserver des copies de récupération chiffrées sur différents supports et dans un emplacement hors site. Cette protection n’est utile que si la clé nécessaire à la restauration est également disponible après la perte de l’hôte.
Ne placez pas tous les secrets dans un dépôt Git public simplement parce que la configuration est versionnée. Stockez les secrets au moyen d’un mécanisme protégé et indiquez dans la documentation où les récupérer.
La définition de l’environnement d’exécution recrée l’environnement autour de l’état
Une arborescence de configuration restaurée peut tout de même échouer si l’hôte de remplacement ne reproduit pas le mappage de la radio USB, le mode réseau, les ports, les chemins sur l’hôte, le service de base de données, le courtier MQTT, les variables d’environnement, le fuseau horaire ou les autorisations attendus par le déploiement d’origine.
La documentation de Home Assistant Container sépare les mises à jour de l’état persistant et suppose que l’environnement d’exécution est recréé à partir de paramètres Docker connus. Le flux de travail Container maintient la sauvegarde et le remplacement de l’image comme deux opérations distinctes, séparation qu’un plan de récupération devrait également préserver.
Enregistrez les fichiers Compose ou les définitions de déploiement équivalentes avec la documentation des services externes. La configuration de l’environnement d’exécution n’est pas la base de données de Home Assistant, mais elle fait partie de la reproduction d’un service fonctionnel.
Les sauvegardes sont des copies de récupération, pas un autre rôle de données actives
Une sauvegarde doit survivre à la défaillance contre laquelle elle est censée protéger. Si toutes les sauvegardes résident sur le même SSD système que la configuration active et la base de données Recorder, une seule panne de stockage peut supprimer les trois rôles en même temps.
Les copies de récupération doivent également survivre à la perte de l’hôte Home Assistant. Le modèle de sauvegarde 3-2-1 conserve plusieurs copies sur différents supports, dont au moins une copie hors site. Pour les sauvegardes Home Assistant chiffrées, le kit d’urgence ou la clé correspondante doit également rester disponible en dehors du système défaillant.
- Configuration et registres : restaurez-les ou réparez-les avec précaution, car ils définissent l’identité et le comportement des automatisations.
- Recorder et statistiques : réparez, restaurez ou reconstruisez-les indépendamment lorsque seule la couche historique est endommagée.
- Secrets et clés : récupérez-les depuis un stockage protégé situé en dehors de l’hôte défaillant.
- Définition de l’environnement d’exécution : recréez les montages, les appareils, le réseau et les dépendances entre services.
- Sauvegardes : conservez les copies de récupération en dehors du domaine de défaillance actif.
L’exemple de déploiement de Home Assistant sur ZimaSpace fournit un contexte utile pour cette séparation : la plateforme serveur peut changer tandis que l’état de l’application et les responsabilités de récupération restent logiquement distincts.
Les rôles des données persistantes sont importants, car ils permettent de réparer la plus petite couche défaillante. Un problème de base de données ne doit pas nécessairement conduire à une installation vierge, et une mise à jour du conteneur ne doit pas entraîner la perte de la configuration.
Produits recommandés
Centre Tech & IA
Plus à lire
Pourquoi Home Assistant fonctionne-t-il différemment sur le réseau local et à distance ?
Les sessions Home Assistant en réseau local et à distance utilisent des chemins réseau différents ; la latence à distance ajoute le DNS, le...
Home Assistant fonctionne-t-il de manière fiable derrière un CGNAT ou un double NAT ?
Le CGNAT et le double NAT n’affectent généralement pas le contrôle local de Home Assistant ; ils modifient principalement la façon dont les clients...
Comment la latence du réseau affecte-t-elle Home Assistant pendant les pannes d’Internet ?
La perte de connexion Internet et la latence du réseau sont deux problèmes distincts : les chemins locaux entre les appareils peuvent rester rapides...
