Reconstruisez Home Assistant uniquement lorsque l’état persistant actuel n’est plus une source de récupération fiable et qu’une restauration connue comme saine ne permet pas de remettre l’installation en service. La plupart des pannes doivent d’abord être classées comme des problèmes d’exécution, d’intégration, de configuration, de base de données, de stockage ou de réseau, puis réparées au niveau le plus restreint possible.
Une réinstallation n’est pas automatiquement une reconstruction. Remplacer l’image d’un conteneur peut laisser /config intact, tandis qu’une véritable reconstruction crée un état applicatif vierge et implique de restaurer ou de recréer les intégrations, appareils, tableaux de bord, assistants et automatisations. Prenez cette décision en fonction de l’état des données, et non de votre frustration face au symptôme actuel.
Utilisez trois actions distinctes : réparer, restaurer, reconstruire
Réparer consiste à conserver la configuration actuelle et à corriger le composant défaillant. Restaurer consiste à remplacer un état endommagé ou incompatible par une sauvegarde connue comme saine. Reconstruire consiste à repartir d’une installation Home Assistant propre, puis à importer ou recréer uniquement les données auxquelles vous accordez délibérément votre confiance.
Cette distinction évite qu’un problème de conteneur ou de paquet ne se transforme en perte de données inutile. Si les utilisateurs, zones, appareils et automatisations actuels sont toujours présents, une installation vierge peut détruire davantage d’informations fiables qu’elle n’en répare.
Notez laquelle de ces trois actions vous entreprenez avant de modifier des fichiers. Cette simple indication rend plus difficile le passage accidentel d’une réparation à une réinitialisation destructive.
Réparez d’abord lorsque l’état persistant reste cohérent
La réparation est appropriée lorsque Home Assistant ouvre l’instance attendue, que le répertoire de configuration est renseigné et que l’erreur peut être associée à une intégration précise, à une modification YAML, à un composant personnalisé, à un fichier de base de données, à un point de montage ou à un paramètre d’exécution.
Le mode sans échec et le mode de récupération existent précisément parce que de nombreuses pannes au démarrage peuvent être isolées sans abandonner la configuration. Un guide de récupération récent recommande de lire l’erreur exacte au démarrage, d’utiliser le mode sans échec pour isoler le code personnalisé et le mode de récupération comme voie de réparation minimale avant de reconstruire.
Désactivez ou mettez à jour une intégration personnalisée, corrigez une entrée de configuration invalide, réparez le chemin de stockage ou revenez à une version antérieure de l’environnement d’exécution, puis effectuez un nouveau test. Ne réinitialisez pas toute l’installation tant que la panne reste circonscrite.
Ne réparez la base de données que si l’historique mérite d’être conservé
La corruption de la base de données Recorder peut sembler grave parce que les journaux se remplissent d’erreurs de base de données, mais cette base n’est pas la même chose que la configuration complète de Home Assistant. Si la configuration actuelle et les intégrations sont intactes, une nouvelle base de données d’historique peut parfois être moins risquée qu’une reconstruction complète de l’application.
Lorsque l’historique est important, une procédure pratique de récupération montre comment arrêter Home Assistant et utiliser les outils de récupération de SQLite pour reconstituer une base de données Home Assistant endommagée dans un nouveau fichier.
Travaillez uniquement sur des copies, conservez la base de données corrompue d’origine et acceptez que la récupération puisse être partielle. L’échec d’une réparation de l’historique ne doit pas devenir une raison de supprimer des automatisations et intégrations saines.
Restaurez lorsqu’une sauvegarde connue comme saine est plus sûre que de poursuivre la réparation
Restaurez lorsque la panne a commencé après une mise à jour ou une modification identifiable et que vous disposez d’une sauvegarde testée datant d’avant ce changement. C’est souvent plus rapide et plus sûr que d’inverser manuellement des dizaines de fichiers migrés ou partiellement modifiés.
Un guide de restauration Home Assistant de longue date recommande d’abord de corriger la cause de la panne, puis de restaurer une sauvegarde copiée hors du système défaillant. Restaurer sans retirer l’alimentation défaillante, le problème de disque, le mauvais point de montage ou l’environnement d’exécution incompatible ne fait que recréer l’incident.
Conservez l’état endommagé jusqu’à ce que le système restauré ait passé les tests. Il peut contenir des automatisations, secrets ou modifications de configuration récentes qu’il faudra comparer ou récupérer sélectivement.
Reconstruisez lorsque l’état et les éléments de récupération ne sont plus fiables
Une reconstruction propre devient raisonnable lorsque le répertoire de configuration est manquant ou fortement corrompu, que plusieurs sauvegardes échouent aux tests de restauration, que la définition de l’environnement d’exécution est inconnue ou que des réparations répétées laissent l’installation dans un état non documenté et impossible à reproduire.
La reconstruction peut également être le choix le plus propre lors de l’abandon d’un déploiement mal structuré — par exemple lorsque des éléments de configuration importants sont enfermés dans un conteneur éphémère — à condition d’exporter d’abord toutes les données fiables que vous pouvez récupérer.
Le guide d’automatisation locale de ZimaSpace souligne que la récupérabilité est une exigence essentielle d’une plateforme domotique. Une reconstruction n’est réussie que lorsque la nouvelle installation est plus facile à sauvegarder, restaurer et exploiter que l’état abandonné.
Utilisez un tableau de décision avant de supprimer l’ancien état
| Condition | Action privilégiée |
|---|---|
| Erreur liée à une seule intégration ou à la configuration | Réparer |
| Échec d’une mise à jour de l’environnement d’exécution ou de l’image, configuration intacte | Réparer ou revenir à une version antérieure de l’environnement d’exécution |
| Base de données endommagée, configuration saine | Réparer ou remplacer la base de données |
| Sauvegarde connue comme saine et antérieure à des dommages étendus | Restaurer |
| Configuration et sauvegardes impossibles à considérer comme fiables ou impossibles à reproduire | Reconstruire |
Ne supprimez pas l’ancienne configuration, l’ancienne base de données ou l’ensemble de sauvegardes avant que la solution choisie ait résisté à un redémarrage et à un cycle normal d’utilisation domestique.
FAQ
La réinstallation du conteneur Home Assistant compte-t-elle comme une reconstruction ?
Non. Si le conteneur de remplacement reconnecte le même répertoire persistant /config, vous avez remplacé l’environnement d’exécution tout en conservant le même état d’installation. Une reconstruction commence avec un état vierge ou abandonne délibérément l’ancien état.
Dois-je reconstruire Home Assistant parce que la base de données Recorder est corrompue ?
En général, non. L’historique de Recorder peut être réparé, restauré ou remplacé indépendamment du reste de Home Assistant. Ne reconstruisez l’installation complète que lorsque la configuration et l’état de récupération — et pas uniquement l’historique — ne sont plus fiables.
Assistance et conseils
Plus à lire

Faut-il sauvegarder Home Assistant en fonctionnement ou arrêter d’abord le service ?
Les sauvegardes intégrées de Home Assistant peuvent s’exécuter à chaud ; les simples copies du système de fichiers doivent arrêter ou mettre en veille...

Pourquoi un serveur Home Assistant chauffe-t-il ou est-il bruyant pendant les périodes d’inactivité ?
Corrélez les pics du ventilateur ou de température de Home Assistant avec Recorder, les sauvegardes, les intégrations et les tâches exécutées en parallèle avant...

Quelle quantité de stockage libre Home Assistant doit-il conserver pour les tâches en arrière-plan ?
Dimensionnez l’espace libre de Home Assistant en fonction de la base de données Recorder, de la croissance des sauvegardes, des pics de maintenance et...

