Je train un fichier home-assistant_v2.db un peu lourd (~42 GB) et je n’arrive pas à le nettoyer. Alors, il y a un petit historique. A la base, mon HA tournait en mode supervised sur un Rpi4 avec un SSD externe. J’ai migré sur un NUC sur lequel j’ai installé proxmox. Déploiement d’un petit HAOS (merci helper scripts) et restauration de mon HA. Pour la restauration, j’ai eu quelques difficultés. Mon fichier de backup faisait 2-3 GB, mais les restaurations ne semblaient pas fonctionner (malgré une version d’HA identique). En lisant les logs, je me suis aperçu qu’il avait un problème d’espace de stockage. J’ai provisionné un disque de 100GB et la restauration a pu se faire correctement. Tout marche nickel si ce n’est que mon fichier de DB est incroyablement gros sans raison. Aujourd’hui, quand je fais un backup de mon HA, mon fichier fait 3GB. Ca me donne l’impression que ma DB comporte quelques données inutiles…
J’ai tenté de paramétrer « recorder ». j’ai mis ces lignes dans mon « configuration.yaml » :
recorder:
auto_purge: true
purge_keep_days: 10
Mais rien n’y fait. J’ai aussi tenter d’appeler le service « Recorder: purger » avec les paramètres de 10j à conserver et « reconditionner ». Mais je n’ai pas l’impression que cela fasse grand chose.
Je pense que tu peux prendre un peu de temps de lecture, les sujets sont nombreux à propos de la fameuse base de données https://forum.hacf.fr/search?q=purger%20la%20base%20de%20donn%C3%A9es
Clairement 42Go pour 10 jours c’est beaucoup trop et certainement plein de choses inutiles
J’ai bien lu plusieurs sujets. Mais je n’ai pas encore trouvé mon bonheur. Je pense que je vais devoir éditer la db…
J’ai l’impression que la partie purge du recorder ne fait rien, même avec l’option repack. Aussi, je n’ai pas non plus des centaines de device gérés. Je dois en avoir environ 50. Je n’ai aucune raison d’avoir une db si grosse. Histoire d’être toujours dans l’illogique, mon backup total de ha ne fait que 3 GB, est-ce que c’est logique vis à vis de la taille de la db?
Est-ce que c’est possible que la restauration de HA m’est stocké 40 GB de données mortes dans la db?
J’ai juste un conseil : oublie l’idée … le modèle est un casse-tête, si la gestion de BdD c’est pas ton métier, le seul truc que tu va réussir à faire c’est tout casser
Donc la config du recoder n’est pas assez précise, tu ne la partages pas. Et si sa config c’est
Ce n’est pas le nombre d’entités qui compte, mais la quantité d’infos que tu y rattaches qui prends de la place 1 entité avec 1 valeur par secondes, ça prends plus de place que 1 entité avec 1 valeur par jour
On est bien d’accord
La compression de données, c’est magique Comme l’archive du backup est compressée (gzip) c’est parfaitement logique
Des données ‹ mortes › (on va dire qui n’existent plus) issues de quoi ?
C’est là où je pense que tu n’as pas fait l’analyse assez approfondie. Dans les différents sujets, il ya des requetes SQL qui donnent des indices sur les entités les plus nombreuses… ça permet de répondre à 2 de tes questions :
existe-t-il des données mortes ?
quelles sont mes entités qui consomment de la place ?
Alors j’ai bien avancé. Ma base ne fait plus que 400 MB. J’ai pas tout compris sur l’origine du problème mais globalement :
Suite à la restauration pour ma migration, ma base faisait 40 GB. Et dans mon fichier de configuration, je n’avais pas du tout de configuration du recorder. Peut-être qu’il n’y avait jamais de ménage dans la base… En tout cas, les purge ne pouvaient pas fonctionner car je n’avais pas assez d’espace disponible pour faire le traitement.
Les actions que j’ai faites :
1 - augmentation de l’espace disque (heureusement que j’étais sur une VM, )
2 - action de purge avec seulement une rétention de 7j. La base est tombée à 3GB.
3 - petite analyse sur les différentes entités. Il s’avère que Lixee est très bavard. J’ai fait le ménage sur les entités qui me sont réellement utile.
4 - j’ai attendu un jour et j’ai rejoué une purge complète avec seulement 1j de rétention.
5 - j’ai reprovisionné une nouvelle VM avec seulement 32 GB de disque et fait une restauration.
6 - fin du game! Maintenant que j’ai bien pigé, je vais pouvoir personnaliser mon recorder selon mes besoins.
Merci beaucoup pour vos indications! Ça m’a aidé à comprendre et à me poser les bonnes questions.
Bonsoir,
Quels peuvent être les critères de choix pour garder des valeurs 7 jours , un mois , une année , indéfiniment ?
Je me pose cette question car je pense qu’un de ces 4 ça va arriver
Vous préconisez quoi comme stratégie de conservation ?
La durée de rétention dans le recorder ça n’est pas la durée pendant lesquels les données sont stockées !
C’est la durée pendant laquelle, elles sont ‹ brutes ›, à partir de Jour N+1, les données sont converties en données long termes et conservées indéfiniment (on perds en précision, plutôt que de garder 1 valeur par minutes, on fait un min/max et une moyenne par heure en gros)
Donc la stratégie, c’est simplement de dire : j’ai besoin de l’historique de ça, ça et ça je mets dans le recorder… Et le reste (comprendre ce dont le besoin n’est pas immédiat), je ne le mets pas ou je l’exclue de l’historique
J’ai vu sur le net des tutos qui parlent de mixer entre MariaDB et InfluxDB pour stocker les données.
Ça me semble un peu usine à gaz, surtout à mettre en place.
Vous en pensez quoi ?
De base c’est ni l’un ni l’autre (c’est du sqlite) et avec des données bien gérées, pas besoin de MariaDB…
Influxdb, en supplément c’est un choix cohérent si on a besoin d’agreger des données externes par exemple. Mais sinon, ça ne sert pas à grand chose.