Comment créer un déploiement Home Assistant récupérable avec des conteneurs
Un déploiement conteneurisé de Home Assistant pouvant être restauré considère l’image du conteneur comme jetable, tandis que l’état, la configuration, les secrets, les mappages de périphériques, le comportement réseau et la procédure de restauration constituent le véritable système.
L’objectif n’est pas simplement de faire redémarrer Home Assistant par Docker. Il s’agit de reconstruire le service sur un hôte vierge après une mise à jour défaillante, la perte d’un disque ou le remplacement de l’hôte, puis de récupérer les mêmes utilisateurs, intégrations, automatisations, radios, données de la base et identité réseau dans un délai connu.
Conservez l’état persistant en dehors de l’image du conteneur
Montez l’intégralité du répertoire de configuration de Home Assistant sur un stockage hôte persistant et sauvegardez tout son contenu, y compris les répertoires cachés. Les migrations effectuées par la communauté échouent régulièrement lorsque les opérateurs copient les fichiers YAML visibles mais oublient .storage, qui contient les entités gérées depuis l’interface, les intégrations et d’autres éléments d’état. Un échec de migration de conteneur montre comment l’expansion des jokers par le shell peut omettre silencieusement ces fichiers cachés.
Conservez le fichier Compose, le modèle de variables d’environnement, le fuseau horaire, le mode réseau, les mappages de périphériques, les chemins des montages de liaison et les éventuelles permissions de groupe requises dans des notes d’infrastructure versionnées. N’intégrez pas l’état propre à un foyer dans une image personnalisée, sauf si vous disposez également d’une compilation reproductible et d’une copie de récupération distincte.
La topologie complète d’un serveur Home Assistant de ZimaSpace présente le schéma général : gardez le chemin de contrôle réduit, séparez l’état persistant du stockage volumineux et placez la récupération en dehors du domaine de défaillance actif avant d’ajouter d’autres dépendances de service.
Sauvegardez l’état de manière cohérente, pas seulement fréquemment
Une sauvegarde n’est utile que si ses fichiers représentent un instant cohérent. Pour un déploiement SQLite local simple, arrêter le service pendant une fenêtre de maintenance puis copier le volume de configuration persistant est facile à comprendre. Pour une base de données externe, sauvegardez-la à l’aide d’une méthode cohérente au niveau de la base et indiquez à quelle sauvegarde de la configuration de Home Assistant elle correspond.
Un flux de sauvegarde de volume Docker récent insiste sur la restauration de la copie plutôt que sur l’hypothèse qu’une commande d’archivage réussie garantit la récupérabilité. Conservez au moins une génération en dehors de l’hôte Docker afin qu’un SSD, un système de fichiers défaillant ou un nettoyage accidentel ne puisse pas supprimer à la fois le service et la sauvegarde.
Consignez l’ancienneté de la sauvegarde, la version de l’application, la version de la base de données, la taille, la somme de contrôle, l’emplacement de la clé de chiffrement et les étapes de restauration sur un hôte vierge. Une politique de conservation sans métadonnées de restauration produit une pile d’archives plutôt qu’un système de récupération.
Modélisez les dépendances et la disponibilité dans Compose
Lorsque Home Assistant dépend de MQTT, d’une base de données externe, d’un proxy ou d’un autre service local, l’ordre de démarrage des conteneurs ne correspond pas à la disponibilité des services. Un processus peut être en cours d’exécution alors que son socket, son schéma ou son point de terminaison d’état de santé reste indisponible. Un guide sur la disponibilité dans Compose montre comment les contrôles d’état de santé et les conditions de dépendance réduisent les problèmes de concurrence au démarrage.
Attribuez à chaque dépendance son propre signal d’état de santé et son propre comportement en cas de défaillance. Home Assistant doit réessayer de se connecter à une base de données en cours de démarrage, mais une base qui reste constamment défaillante doit être signalée comme un problème plutôt que masquée par des redémarrages incessants. Utilisez les politiques de redémarrage pour récupérer après l’arrêt d’un processus ; utilisez les contrôles d’état de santé et la surveillance pour déterminer si le service est réellement disponible.
Dans la mesure du possible, gardez les services facultatifs en dehors de la chaîne critique de démarrage. Un moteur de rendu de tableau de bord, un outil multimédia ou un exportateur de métriques défaillant ne doit pas maintenir le contrôleur domotique hors ligne.
Définissez les limites de changement et conservez une paire de restauration
Avant une mise à jour, consignez la balise actuelle de l’image Home Assistant, la définition Compose, la version de la base de données, la sauvegarde de la configuration et les versions des éventuels services auxiliaires participant au démarrage. Modifiez une seule couche à la fois. Si une mise à jour échoue, revenir uniquement à l’image du conteneur peut être dangereux lorsque des migrations de configuration ou de base de données ont modifié l’état persistant.
Utilisez une restauration de préproduction ou un répertoire de récupération cloné pour tester la version cible avant une migration majeure de l’hôte ou de la base de données. Conservez l’image précédente connue comme fonctionnelle et l’instantané d’état créé juste avant la mise à jour sous forme de paire. Ne supprimez cette paire qu’après validation des automatisations, de l’historique, des radios, des tableaux de bord, des notifications et d’un test de redémarrage avec la nouvelle version.
Un article plus récent sur la conception de Home Assistant avec Docker Compose traite le réseau, le stockage persistant et les sauvegardes comme des décisions explicites de déploiement. C’est le bon modèle pour une restauration : conservez l’état et la définition du déploiement nécessaires à un conteneur de remplacement, et non le système de fichiers jetable du conteneur lui-même.
Reconstruisez le système sur un hôte vierge avant de considérer le déploiement comme récupérable
Choisissez une machine de secours, une VM ou un répertoire de test isolé, puis effectuez la récupération sans lire de fichiers depuis le système de fichiers du conteneur en production. Installez le moteur de conteneurs, placez la définition Compose, restaurez l’état persistant, recréez les secrets, connectez les radios à l’aide de chemins de périphériques stables, démarrez les dépendances requises et lancez Home Assistant.
Vérifiez la propriété et les permissions des fichiers avant de conclure à une sauvegarde défectueuse. Des différences de permissions après une migration peuvent afficher un écran de première configuration même lorsque les données sont présentes. Un cas de récupération après une migration Docker montre comment les permissions et l’état caché peuvent indépendamment empêcher l’installation restaurée de réapparaître.
- Connectez-vous avec le compte administrateur existant.
- Vérifiez les intégrations, les entités, les automatisations, les tableaux de bord et l’historique.
- Confirmez la gestion de Zigbee, Z-Wave, Thread, Bluetooth ou de toute autre radio.
- Déconnectez Internet et exécutez une automatisation locale critique.
- Redémarrez l’hôte et chaque dépendance requise.
- Mesurez le temps total de restauration entre un hôte vierge et le rétablissement du contrôle du foyer.
Utilisez un contrat de récupération pour chaque dépendance conteneurisée
| Composant | Objet persistant | Preuve de récupération |
|---|---|---|
| Home Assistant | État complet de /config |
Le compte et les automatisations existants réapparaissent |
| Base de données | Sauvegarde cohérente de la base | Les requêtes d’historique et les écritures de Recorder réussissent |
| MQTT/broker | Configuration, identifiants et état conservé si nécessaire | Les appareils se reconnectent et publient |
| Radios | Identité du périphérique, clés réseau et mappage | Le coordinateur se reconnecte sans nouvel appairage |
| Réseau/proxy | Ports, noms, certificats et routes | Les clients locaux et distants prévus se reconnectent |
Un déploiement récupérable dispose d’une définition versionnée, d’un état conservé hors de l’hôte, de dépendances dont la disponibilité est vérifiée, d’une paire de restauration et d’une restauration chronométrée sur un hôte vierge. Une fois ces tests réussis, les conteneurs deviennent ce qu’ils sont censés être : des unités d’exécution remplaçables plutôt que des animaux de compagnie irremplaçables.
Produits recommandés
Configuration NAS et serveur
Plus à lire
Une configuration RAG locale pour les articles de recherche, les notes et les documents privés
Conserver l’autorité des documents originaux, rendre l’indexation reproductible, exiger des citations et séparer les modèles remplaçables des données sources privées.
Pourquoi les développeurs utilisent-ils un nœud passerelle pour le DNS privé, le VPN et les applications de test ?
Un nœud passerelle fournit aux applications privées un nom et un chemin d’accès contrôlés uniques, tandis que les nœuds de calcul restent non exposés...
Comment créer une pile d’applications reproductible avec des fichiers Compose, des secrets et des données persistantes séparés
Gardez les définitions Compose portables, protégez les secrets et sauvegardez séparément les données des applications afin de pouvoir reconstruire la pile sur un hôte...
