Intégration optionnelle des log dans les sauvegardes

Bonjour,

Le seul sujet que j’ai trouvé qui en parle est le suivant et il est succin :
Backup - fichier des logs non sauvegardés - Utilisation du core de Jeedom / Backup/Restauration - Communauté Jeedom

NB: Je ne critique rien ni personne ici.

Je ne sais pas si je suis le seul à qui c’est arrivé, mais en m’appercevant d’une petite tuile (que je ne détaillerai pas ici) et comme les log sont purgés tous les jours pour réduire leur taille (et ça c’est bien) que j’ai paramétré à 1000 lignes, je me suis dit que je pourrai aller voir dans le backup de la veille ou même de l’avant-veille. Quelle n’a pas été ma surprise de voir que les log ne sont pas sauvegardés et qu’il n’y a pas d’option pour les sauvegarder.

Les log sont explicitement exclus de la sauvegarde :

Les log en mode debug génèrent plein de lignes et c’est bien le principe. Ces lignes sont purgées et c’est tant mieux. Par défaut les fichiers log ne sont pas sauvegardés et c’est très bien aussi pour les systèmes n’ayant pas beaucoup d’espace disque. Dans mon cas, j’ai de la place et j’aimerais que les log soient sauvegardés et ça ne m’est pas possible.

Qu’à cela ne tienne, je pourrais modifier le core pour y ajouter cette option et ajouter le fonctionnement que je désire. Oui mais est-ce que c’est une option voulue ? Est-ce que ça servira à quelque chose que je passe du temps à développer ça si le principe même n’est pas souhaité ?
Parce qu’un script qui sauvegarde les log est possible aussi, mais forcément c’est moins « intégré » dans Jeedom…

Qu’en pensez-vous ?

A+
Michel

Salut,

Comme tu dis, on est ici pour débattre, personne n’attaque qui ou quoi que ce soit :wink:

Perso je trouve qu’il ne faudrait pas ajouter une option pour sauvegarder les logs: ca n’a pas à mes yeux pas vraiment de sens en tant que user et je suis partisan de rendre les choses plus simples, prête à l’emploi et pas qu’il y a des centaines d’options possibles qui de plus pourraient causer des problèmes

par contre on pourrait avoir un mécanisme de rotation des logs un peu plus évolué qui pourrait se baser sur le nombre de ligne mais aussi le nombre de jours ou autre, créer une archive compressée lors de la rotation en gardant les X derniers etc
y a des lib très bien suivies qui gère ça comme monolog… mais il a été décidé de virer les libs et de faire du home made (sic!); c’est donc incompatible.

1 « J'aime »

Ce que je ferais si je voulais garder les logs sans script externe, c’est un scénario déclenché par #begin_backup#. Et dedans, j’y mettrais soit soit un bloc code, soit un appel à un script sh avec le plugin script, dont le but serait de faire une copie du dossier log sous un autre nom afin qu’il soit pris en compte. Après, il faut voir si entre #begin_backup# et le zip il a assez de temps pour que ça fasse bien.

2 « J'aime »

Personnellement, pour éviter de toucher au core ou de faire un script custom, je ferais un scénario avec déclencheur post backup qui appelle une commande qui réalise le backup.

Perso, je me sers déjà de CloudSync Pro pour faire des copies / restaurations / purges mais il en existe d’autres.
Mais ça à l’avantage de rester dans l’écosystème jeedom sans faire de script externe.

1 « J'aime »

+1 pour les 2 solutions du dessus avec un script pre ou post backup.
Si tu as de la place, pourquoi limites tu les logs à 1000 lignes

Et pourquoi ne pas supprimer cette limite en nombre ligne et utiliser le rotatelog du système ?

Norbert

Merci pour vos réponses, comme ça je sais qu’il est préférable que je ne propose pas de modification du core.

:+1:

1 « J'aime »

Bonjour,

Jeedom offre la possibilité de configurer un syslog pour externaliser les logs. À gérer ensuite avec l’outil correspondant dont c’est le job.