Jusqu’à quelle taille les données de Home Assistant peuvent-elles atteindre sur un seul hôte ?
Les données de Home Assistant peuvent rester sur un seul hôte tant que la croissance, les pics de maintenance, la durée des sauvegardes et le temps de récupération restent dans les limites opérationnelles mesurées.
Il n’existe pas de plafond universel pertinent en gigaoctets, car l’historique de Recorder, les statistiques à long terme, les sauvegardes, les journaux, les médias et les données des modules complémentaires ont des comportements différents. Mesurez chaque catégorie pendant au moins sept jours normaux, en incluant la période d’automatisation la plus chargée, et prévoyez de l’espace pour les mises à niveau ou la maintenance de la base de données. Cessez de considérer la conception comme sûre lorsque les marges d’espace libre ou de récupération diminuent, même si le système de fichiers n’est pas encore plein.
Définir ce qui compte comme données de Home Assistant
Séparez l’arborescence de configuration active, la base de données Recorder, les statistiques à long terme, les sauvegardes, les journaux, les médias, les données des modules complémentaires et les fichiers temporaires. Le total d’un répertoire masque le composant qui est durable, remplaçable, conservé par obligation ou en croissance inattendue. Les décisions de capacité nécessitent ces catégories, car chacune possède son propre parcours de nettoyage et de récupération.
Une installation de Home Assistant fonctionnant depuis longtemps peut accumuler bien plus de données Recorder que prévu lorsque de nombreuses entités se mettent à jour fréquemment. L’expérience présentée dans l’analyse de la croissance de la base de données montre pourquoi la sélection des entités et la conservation doivent être mesurées séparément de l’utilisation totale du disque.
RÉUSSITE signifie que chaque grande catégorie de données a un responsable, une règle de conservation, une taille actuelle et une exigence de récupération. ÉCHEC signifie qu’un total indifférencié guide la décision. Ne déplacez ni ne supprimez rien avant d’avoir identifié la catégorie en croissance et sa valeur.
Mesurer le taux de croissance plutôt qu’un instantané
Relevez les mêmes compteurs de taille à la même heure chaque jour pendant au moins une semaine. Incluez un week-end, une occupation normale, les sauvegardes et la maintenance planifiée. Calculez la croissance quotidienne de chaque catégorie et notez les changements soudains après l’ajout de nouvelles intégrations, de caméras, d’une journalisation détaillée ou la modification de la conservation.
Les recommandations de la communauté sur la croissance de la base de données Recorder établissent un lien entre les changements d’état fréquents, des index plus volumineux, davantage d’E/S et des opérations de sauvegarde ou de restauration plus longues, ce qui justifie un test fondé sur le taux plutôt que sur un simple seuil de taille de fichier.
RÉUSSITE signifie que le taux est stable et explicable dans le cadre de la charge actuelle. ÉCHEC signifie que la pente s’accélère ou qu’une catégorie augmente fortement sans événement planifié. Inspectez les principaux générateurs de données et les changements récents avant d’augmenter la capacité de stockage, car une croissance incontrôlée finira par remplir un disque plus grand sur une période plus longue.
Prévoir les pics de maintenance et de récupération
L’hôte a besoin d’une marge au-delà des données en régime permanent. Les migrations de bases de données, les réorganisations, la création et l’extraction de sauvegardes ainsi que la validation d’une restauration peuvent temporairement dupliquer ou réécrire une quantité importante de contenu. Modélisez l’opération planifiée la plus exigeante ainsi que le chevauchement entre ses données d’entrée, sa sortie temporaire et la copie de restauration conservée.
Un pic de base de données signalé s’est stabilisé après la désactivation de capteurs bruyants, montrant comment une variation du taux de croissance peut identifier le générateur de données avant d’entreprendre une purge ou une mise à niveau de la capacité.
RÉUSSITE signifie que le pic modélisé laisse une réserve documentée et n’empiète pas sur le système d’exploitation ou la base de données. ÉCHEC signifie qu’une mise à niveau ou une restauration pourrait remplir le système de fichiers. Augmentez la marge ou réduisez les données non essentielles conservées avant l’opération ; n’attendez pas un incident de réparation dû au manque d’espace.
Utiliser la durée des sauvegardes et des restaurations comme plafond pratique
La seule capacité de stockage ne suffit pas à prouver qu’un système est exploitable. Chronométrez une sauvegarde vérifiée, copiez-la vers l’emplacement de récupération et restaurez-la dans une instance de test isolée. Notez la durée d’indisponibilité, le temps de transfert, le temps d’extraction, le délai de disponibilité de la base de données et le moment où les intégrations essentielles deviennent utilisables.
Le modèle d’espace libre de ZimaSpace dimensionne la capacité à partir de la croissance de la base de données et des tâches en arrière-plan plutôt qu’à partir d’un pourcentage universel. Utilisez la marge d’espace libre de Home Assistant comme contrôle opérationnel complémentaire.
RÉUSSITE signifie que la sauvegarde et la restauration se terminent dans les objectifs de récupération du foyer, avec une réserve restante. ÉCHEC signifie que l’hôte unique est devenu trop volumineux sur le plan opérationnel, même s’il reste de l’espace libre. Séparez les médias remplaçables ou les données d’archives, réduisez la durée de conservation lorsque cela se justifie ou déplacez les copies de sauvegarde hors de l’hôte.
Définir un déclencheur de réévaluation et une condition d’arrêt
Projetez chaque taux de croissance mesuré jusqu’à la prochaine date de réévaluation et définissez des seuils pour l’espace libre, la durée des sauvegardes, la durée des restaurations et la réactivité des requêtes d’historique. Utilisez les valeurs absolues observées sur l’hôte, et non un pourcentage emprunté. Réévaluez la situation après l’ajout d’une intégration à haute fréquence ou la modification de la conservation.
La conception reste acceptable lorsque deux périodes de réévaluation consécutives montrent une croissance stable, que la maintenance tient dans la réserve et qu’une restauration isolée respecte l’objectif. Si une seule mesure échoue, corrigez la catégorie de données ou le flux de travail concerné avant de remplacer l’ensemble de l’hôte.
Cessez d’étendre la conception à hôte unique lorsque la maintenance projetée dépasse la réserve, que la récupération n’atteint pas son objectif de durée ou que la croissance ne peut pas être attribuée après des tests contrôlés. Traitez séparément les erreurs de stockage ou la corruption de la base de données ; il s’agit de défaillances de fiabilité, et non d’une simple indication que le jeu de données est volumineux.
Produits recommandés
Assistance et conseils
Plus à lire
Home Assistant fonctionne en Wi-Fi, mais échoue en Ethernet ou via VPN
Testez chaque chemin réseau séparément, vérifiez l’état de l’interface et du routage, distinguez l’accès direct par IP de la découverte, puis ne réparez que...
Comment mettre hors service Home Assistant sans laisser de données non protégées
Prouvez le remplacement ou l’archivage, révoquez chaque chaîne de confiance, assainissez chaque appareil contenant des données et ne conservez que les copies de récupération...
Faut-il utiliser les mises à jour automatiques de Home Assistant sur un serveur domestique ?
Choisissez des mises à jour manuelles, avec notification uniquement, ou automatiques par étapes, en fonction de l’impact sur le foyer, du risque de compatibilité,...
