Qu’est-ce qui fait que Home Assistant conserve plus de données temporaires que prévu ?

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.

Home Assistant conserve plus de données temporaires que prévu lorsque les opérations de sauvegarde, de base de données, de journalisation, de mise à jour ou de cache se prolongent au-delà de l’événement de nettoyage attendu par l’opérateur.

Temporaire ne signifie pas toujours éphémère ni sans danger à supprimer. Une archive ayant échoué peut laisser des fichiers de préparation, SQLite peut conserver des journaux ou des pages libres, une intégration très verbeuse peut faire grossir les journaux, et un processus en cours peut maintenir un espace de stockage supprimé jusqu’à son redémarrage. Identifiez le chemin concerné, le processus, la date de création et la tâche active avant toute suppression ; sinon, le nettoyage peut interrompre une récupération ou corrompre l’état du système.

Distinguer les chemins temporaires des données d’application conservées

Classez la croissance par répertoire et par propriétaire : base de données et journaux, préparation des sauvegardes, journaux d’activité, conversion multimédia, téléchargements de mises à jour, cache des modules complémentaires, couches de conteneurs et espace temporaire du système d’exploitation. Comparez la taille apparente des fichiers, les blocs alloués et l’espace libre du système de fichiers. Un chemin nommé « temp » peut contenir une transaction active, tandis qu’un répertoire de cache peut être volontairement conservé après les redémarrages.

Les installations Home Assistant conservent généralement l’historique détaillé pendant une période configurée et les statistiques à long terme selon d’autres règles. Cette distinction de conservation montre pourquoi la croissance de la base de données ne doit pas être qualifiée de temporaire simplement parce que les détails anciens seront finalement purgés.

Si les données relèvent d’une politique de conservation documentée, ajustez cette politique plutôt que de supprimer des fichiers. Si elles appartiennent à une tâche terminée ou échouée sans propriétaire actif, elles peuvent être candidates au nettoyage. L’impossibilité d’identifier le propriétaire impose l’arrêt de la procédure, en particulier dans les chemins gérés par la base de données, les sauvegardes ou le superviseur.

Les tâches échouées peuvent laisser des données de préparation orphelines

Les sauvegardes, mises à jour, importations et opérations de maintenance de la base de données créent souvent une seconde copie pendant leur exécution. En cas de réussite, les données de préparation sont généralement renommées ou supprimées ; une interruption, un manque d’espace disque ou le plantage d’un processus peut empêcher ce nettoyage. Des tentatives répétées peuvent alors créer plusieurs générations dont les horodatages correspondent aux tâches échouées.

Un cas concret est documenté dans la demande visant à purger les fichiers de sauvegarde échoués, où des exécutions de sauvegarde infructueuses avaient laissé de volumineux répertoires temporaires du superviseur. La leçon porte sur le propriétaire et l’état de la tâche, et non sur un chemin universel que chaque installation devrait supprimer manuellement.

Vérifiez qu’aucune sauvegarde, restauration, mise à niveau ou migration n’est en cours, conservez l’erreur de la tâche et utilisez le mécanisme de nettoyage pris en charge par le type d’installation. Si les mêmes fichiers réapparaissent, corrigez d’abord la tâche défaillante ou le seuil d’espace libre. Supprimer les symptômes sans modifier la boucle d’échec ne fait que remettre le compteur à zéro.

Les fichiers de base de données peuvent ne pas rétrécir lorsque des lignes disparaissent

La purge de Recorder peut supprimer des lignes logiques tandis que la base de données conserve les pages allouées pour les réutiliser. Les journaux en avance d’écriture ou les journaux de transactions peuvent également grossir jusqu’à ce que les conditions de point de contrôle soient réunies. La taille du fichier peut donc rester élevée même après une réduction de la période de conservation, et une suppression manuelle brutale peut détruire la cohérence au lieu de libérer un cache sans danger.

Une analyse de Home Assistant portant sur un schéma de purge de la base de données distingue la croissance quotidienne continue du moment de la purge planifiée et montre pourquoi une courte période d’observation peut faire prendre un comportement attendu pour un problème.

Mesurez l’âge des lignes logiques, l’état de santé de la base de données, l’état des journaux et la tendance de l’espace libre sur au moins un cycle de nettoyage. N’effectuez la maintenance de la base de données prise en charge qu’avec une sauvegarde vérifiée et suffisamment d’espace temporaire disponible. Faites remonter le problème si les journaux ne se résorbent jamais, si les contrôles d’intégrité échouent ou si Recorder redémarre régulièrement pendant le nettoyage.

-15% OFF

Effectuer un diagnostic sûr des données temporaires

Prenez deux instantanés du stockage à une heure d’intervalle, en indiquant le chemin, la taille allouée, la date de modification, le processus propriétaire et l’état de la tâche associée. Marquez chaque élément comme actif, conservé par une règle, orphelin après un échec ou inconnu. Interrompez la génération de nouvelles sauvegardes et mises à jour pendant la comparaison afin que la cause de la croissance puisse être établie.

La procédure ZimaSpace consacrée au cache et au stockage temporaire fournit les commandes de contrôle au niveau de l’installation une fois le propriétaire identifié.

Supprimez uniquement les éléments documentés comme jetables et qui ne sont ouverts par aucun processus, puis relancez la tâche d’origine et vérifiez à la fois sa réussite et le nettoyage effectué. La procédure est concluante si l’espace libre reste stable sur deux cycles. Si le propriétaire demeure inconnu ou si l’intégrité de la base de données est en jeu, préservez les données et faites remonter le problème plutôt que de forcer leur récupération.

Centre Tech & IA

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.