Comment restaurer Home Assistant après l’échec d’une mise à jour du conteneur

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How to Restore Home Assistant After a Failed Container Update - Zima Store Online

Une mise à jour échouée du conteneur Home Assistant doit généralement être considérée comme un problème de remplacement de l’environnement d’exécution, et non comme une raison de créer une nouvelle installation. Si le répertoire /config monté depuis l’hôte est intact, la méthode de récupération la plus sûre consiste à préserver cet état, à vérifier le mappage du volume, à démarrer une image connue pour être fiable et à tester l’installation existante avant de restaurer une ancienne sauvegarde.

La manœuvre dangereuse consiste à laisser un nouveau conteneur démarrer avec un chemin hôte incorrect ou vide. Home Assistant peut alors afficher l’assistant de configuration initiale comme si la configuration avait disparu, alors que l’état d’origine existe toujours ailleurs sur le disque. Commencez par bloquer les modifications, identifiez le répertoire de configuration faisant autorité et ne supprimez pas l’ancien conteneur ou répertoire tant que l’instance récupérée n’a pas été validée.

Bloquer les nouvelles écritures et trouver le véritable chemin /config

Arrêtez le conteneur défaillant et examinez la définition d’exécution qui l’a créé. Vérifiez quel répertoire hôte ou volume nommé est associé à /config, puis inspectez cet emplacement pour y trouver vos fichiers YAML, .storage, composants personnalisés, secrets et base de données.

Dans un cas de récupération rapporté par la communauté après une mise à niveau de Docker, une instance Home Assistant prétendument « toute neuve » était en réalité due au fait que le conteneur pointait vers le mauvais dossier de configuration. Les données persistantes n’avaient pas été effacées ; le nouvel environnement d’exécution ne les montait simplement pas correctement.

Copiez ou créez un instantané du répertoire de configuration actuel avant de modifier les propriétaires, les chemins ou les fichiers de base de données. Même un état partiellement défectueux constitue une information précieuse et peut contenir des automatisations ou des identifiants plus récents que ceux de la dernière sauvegarde.

Recréer l’environnement d’exécution sans recréer l’installation

Utilisez le même mode réseau, fuseau horaire, mappages de périphériques, accès aux radios USB, privilèges ou capacités, ainsi que le même montage hôte de /config que celui utilisé précédemment par le conteneur fonctionnel. L’image peut être remplacée ; ces paramètres d’exécution et les données persistantes déterminent si le service revient en tant que la même instance Home Assistant.

La persistance d’un conteneur dépend du montage hôte, et non du système de fichiers du conteneur. Un exemple de Home Assistant Container monte directement un volume hôte persistant sur /config, de sorte que la recréation de l’environnement d’exécution ne recrée pas la configuration du foyer. Si ce mappage change lors d’une mise à jour, un conteneur de remplacement peut sembler vierge alors que l’état d’origine existe toujours ailleurs.

Ne copiez pas le système de fichiers de l’ancien conteneur dans la nouvelle image. Recréez le déploiement à partir d’une définition Compose ou d’une commande d’exécution documentée, puis reconnectez explicitement l’état persistant.

Rétrograder l’image avant de restaurer un état plus ancien

Si le montage de configuration est correct, mais que la nouvelle version de Home Assistant ne démarre pas ou interrompt une intégration critique, testez l’image précédente connue pour être fiable avec le même /config préservé. Cela permet de distinguer un « nouvel environnement d’exécution incompatible avec l’état actuel » d’un « état lui-même endommagé ».

Le processus actuel de Home Assistant Container sépare explicitement l’image de l’état persistant : effectuez d’abord une sauvegarde, récupérez l’image cible, recréez le conteneur et utilisez une balise d’image plus ancienne précise lorsqu’une rétrogradation est nécessaire. C’est cette limite de récupération qu’il faut préserver : remplacer l’environnement d’exécution tout en conservant le chemin de configuration faisant autorité.

Lors d’une rétrogradation, n’oubliez pas que certaines mises à niveau migrent les structures de données. Utilisez une sauvegarde effectuée avant une migration si l’ancienne version ne peut pas lire correctement un état déjà mis à niveau par la nouvelle version. Ne changez pas plusieurs fois de version en utilisant l’unique copie des données persistantes.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

Ne restaurer une sauvegarde que lorsque l’état actuel n’est pas fiable

Utilisez une sauvegarde lorsque la configuration persistante est absente, corrompue, partiellement écrasée ou n’est plus compatible avec la version que vous pouvez exécuter en toute sécurité. Dans la mesure du possible, restaurez-la dans une cible isolée ou propre afin de pouvoir comparer l’état récupéré avec la copie endommagée.

Conservez le mot de passe de chiffrement ou le kit d’urgence nécessaire pour ouvrir la sauvegarde en dehors de l’hôte défaillant. Une sauvegarde présente uniquement sur le même disque, ou impossible à déchiffrer, ne constitue pas une solution de récupération.

L’exemple de ZimaSpace consistant à séparer la récupération de Home Assistant de l’hôte de stockage lui-même renforce la même règle : l’état de l’application doit disposer d’une voie de restauration indépendante, et pas seulement d’un disque actif en miroir.

Valider le conteneur récupéré avant toute suppression

Vérifiez que les utilisateurs, tableaux de bord, intégrations, automatisations, assistants et zones attendus sont présents.
Vérifiez le fonctionnement d’un chemin vers un appareil local et d’un chemin utilisant une radio si Zigbee, Z-Wave ou Bluetooth est utilisé.
Recherchez les erreurs de base de données ou de migration dans Recorder.
Redémarrez le conteneur récupéré et confirmez que le même état réapparaît.
Conservez l’ancienne balise d’image, une copie de la configuration et la dernière sauvegarde connue pour être fiable jusqu’à la réussite de ce second démarrage.

Si l’ancienne image fonctionne avec la configuration d’origine, la mise à jour échouée était principalement un problème d’environnement d’exécution ou de version. Si aucune image ne fonctionne avec le même état, passez à la réparation de la configuration ou à la restauration d’une sauvegarde. Si un conteneur propre ne fonctionne qu’avec un /config vide, n’acceptez pas la nouvelle configuration comme étant « réparée » tant que vous n’avez pas compris ce qui, dans l’état persistant, empêche la récupération.

FAQ

Dois-je supprimer le conteneur Home Assistant défaillant avant le dépannage ?

Non. Arrêtez-le d’abord et préservez sa définition d’exécution ainsi que son chemin de configuration monté. Vous pouvez créer un conteneur de remplacement sans supprimer le conteneur défaillant, ce qui conserve les informations nécessaires à une rétrogradation pendant que vous validez le nouvel environnement d’exécution.

Pourquoi Home Assistant affiche-t-il l’assistant de configuration initiale après une mise à jour ?

La raison la plus courante, spécifique aux conteneurs, est que le nouvel environnement d’exécution ne voit pas le chemin /config d’origine. Vérifiez le montage hôte avant de supposer que la configuration a été effacée ou de restaurer une ancienne sauvegarde par-dessus un état plus récent.