Scénario #37421
Base de donnée de postgresql Bareos énorme
100%
Description
Dans les tests migrationSh, nous sauvegardons le code PHP d'applications (Nextcloud, Sabre, ...) sur une version et le restaurons sur une nouvelle version.
Quelle est le sens de cet action ?
Je propose de ne plus sauvegarder de code (seulement des données, ou du code modifié par rapport aux paquets Deb).
Sous-tâches
Historique
#1 Mis à jour par Gilles Grandgérard il y a 6 mois
Pour info :
ls -l /mnt/eole-ci-tests/sauvegarde/etb3.amonecole/default-2.9.0/migrationSh/
1071923200 avril 8 03:22 sauvegarde-210.tar.gz
Soit 1 Go !
#2 Mis à jour par Joël Cuissinat il y a 5 mois
- Release mis à Carnet de produit Cadoles - MEN
- Points de scénarios mis à 1.0
- taille des données
- nombre de fichiers
#3 Mis à jour par Arnaud FORNEROT il y a 5 mois
Si le sujet du ticket est le mail envoyé par la Réunion, je ne vois pas le rapport le script de backup de migration.sh
Que dans ce cadre là on sauvegarde tt /var/www/html c'est préférable, et le volume ici ne semble ne pas être problématique pour eux.
Ce qui pose problème c'est bien la base postgresSQL de bareos qui montrait à 16go, ce qui est extrêmement étrange si dans cette base on ne référence que les chemins des fichiers sauvegardés
En plus sur la configuration bareos de nextcloud on ne sauvegarde pas le /var/www/html/nextcloud mais uniquement /home/www-data/var/www/html/nextcloud, ce qui me semble tout à fait normal
J'ai pu avoir Laurent et lui demandé s'il était possible d'avoir cette fameux base de 16Go que l'on puisse analyser ce qui peut prendre autant de place dans sa base qui est sensé stocké que des chemins
#4 Mis à jour par Laurent Gourvenec il y a 5 mois
- Echéance mis à 01/01/2026
- Assigné à mis à Arnaud FORNEROT
- Version cible mis à Carnet Cadoles - MEN
- Début mis à 01/10/2022
#5 Mis à jour par Benjamin Bohard il y a 5 mois
Pour continuer la digression sur la taille de la base de données de bareos, il y a un doute sur la conduite des opérations de maintenance type VACUUM.
La tâche schedule existante (https://dev-eole.ac-dijon.fr/projects/eole-bareos/repository/revisions/master/entry/schedule/scripts/bareos) n’est pas prévu pour gérer la base postgresql. Il ne doit donc pas y avoir de tâche planifiée côté EOLE pour la récupération de l’espace occupé par les enregistrements supprimés.
En l’état actuel, la tâche existante ne sert à rien vu que le choix de la base de données pour bareos n’existe plus. Il faudrait donc mettre à jour cette tâche pour effectuer le VACUUM sur postgres.
#6 Mis à jour par Joël Cuissinat il y a 4 mois
- Points de scénarios changé de 1.0 à 2.0
+1 pour travailler sur la purge du PostgreSQL
#7 Mis à jour par Joël Cuissinat il y a 3 mois
- Sujet changé de Sauvegarde Code PHP ? à Base de donnée de postgresql Bareos énorme
- Assigné à changé de Arnaud FORNEROT à Benjamin Bohard
#8 Mis à jour par Ludwig Seys il y a 3 mois
- Statut changé de Nouveau à Résolu
#9 Mis à jour par Joël Cuissinat il y a 3 mois
- Statut changé de Résolu à Terminé (Sprint)
- Version cible changé de Carnet Cadoles - MEN à Livraison Cadoles - MEN 31/12/2025 (30)
- Release changé de Carnet de produit Cadoles - MEN à EOLE 2.8.1