Scénario #24214
Bareos : voir comment limiter la taille occupée par les volumes dépassant la rétention
100%
Description
Malgré l'application de durée de rétention, on trouve sur environ 40% de nos horus et scribe de notre académie des volumes ayant dépassé cette dernière.
Sur une rétention à 40jours (diff et full), avec une diff par semaine, une full par mois et une inc par jour (8 jours de rétention), nous avons un peu de tout qui dépasse la durée demandée.
Par exemple :
J'ai ce volume "127.0.0.1-dir-diff-0248" dans mon catalogue donc le "list volumes" me donne :
248 | 127.0.0.1-dir-diff-0248 | Full | 1 | 1,999,936,603 | 0 | 3,456,000 | 1 | 0 | 0 | File | 2018-01-26 22:05:00 |
Idem sur le disque
-rwxr-xr-x 1 bareos root 1999936603 janv. 26 22:00 /mnt/sauvegardes/127.0.0.1-dir-diff-0248*
La duré est largement dépassé, et il me semble que bareos n'a depuis sa dernière utilisation jamais essayé de le purger :
zcat /var/log/rsyslog/local/bareos-dir/bareos-dir.err.log*.gz | grep 127.0.0.1-dir-diff-0248
2018-01-26T22:00:17.647790+01:00 sc450053.clg-dunois-orleans.lan bareos-dir: 127.0.0.1-dir JobId 910: There are no more Jobs associated with Volume "127.0.0.1-dir-diff-0248". Marking it purged.
2018-01-26T22:00:17.648785+01:00 sc450053.clg-dunois-orleans.lan bareos-dir: 127.0.0.1-dir JobId 910: All records pruned from Volume "127.0.0.1-dir-diff-0248"; marking it "Purged"
2018-01-26T22:00:17.650300+01:00 sc450053.clg-dunois-orleans.lan bareos-dir: 127.0.0.1-dir JobId 910: Recycled volume "127.0.0.1-dir-diff-0248"
2018-01-26T22:00:18.014895+01:00 sc450053.clg-dunois-orleans.lan bareos-dir: 127.0.0.1-sd JobId 910: Recycled volume "127.0.0.1-dir-diff-0248" on device "FileStorage" (/mnt/sauvegardes), all previous data lost.
2018-01-26T22:05:00.543471+01:00 sc450053.clg-dunois-orleans.lan bareos-dir: 127.0.0.1-sd JobId 910: End of medium on Volume "127.0.0.1-dir-diff-0248" Bytes=1,999,936,603 Blocks=31,001 at 26-Jan-2018 22:05.
2018-01-26T22:32:34.352679+01:00 sc450053.clg-dunois-orleans.lan bareos-dir: Volume name(s): 127.0.0.1-dir-diff-0248|127.0.0.1-dir-diff-0249|127.0.0.1-dir-diff-0250|127.0.0.1-dir-diff-0251|127.0.0.1-dir-diff-0252
Depuis ce recyclage, plus rien...
Par ailleurs, si on demande a bareos de purger les volumes dépassés par la rétention via :
echo "list volumes" | bconsole | grep 127.0.0.1-dir | awk '{print $4}' | xargs -i% echo -e "prune volume=%\nyes" | bconsole
les volumes passent bien en statut "prune". Je ne sais pas pourquoi certains volumes passent a travers "l'autoprune" de bareos.
Après dialogue avec E Garette, qui a notamment trouvé des infos relative a ce comportement tel que http://admin.shamot.cz/?p=309#sthash.TooEI6wU.dpbs , avoir l'option " “Action On Purge = Truncate” in all Pools" dans le directeur permet de limiter l'impact de ce comportement.
Ce que l'on ne sait pas, c'est si cela suffira : les volumes seront-il "Trucate" une fois la durée de rétention dépassé malgré le fait que leur statut n'est pas changé par bareos ?
Nicolas
Sous-tâches
Demandes liées
Révisions associées
ref #24214 correction diagnose
Message plus générique en cas d’erreur de lecture du fichier de rapport.
Ref #24214
Historique
#1 Mis à jour par équipe eole Academie d'Orléans-Tours il y a presque 6 ans
Ça devrait fonctionner car de ce qui est expliqué dans ce vieil article https://adsm.org/lists/html/Bacula-users/2010-06/msg00199.html nos volumes sont bien "scannés" par bareos, ils passent en Full puis en état Used, et sont parfois recyclés. Il semble que la suppression totale ne soit pas trop dans les habitudes de bacula...
Le fonctionnement fait qu'on conserve tous les Jobs, on garde donc les volumes associés :
*list jobs Automatically selected Catalog: MyCatalog Using Catalog "MyCatalog" +-------+-----------------+---------------------+------+-------+-----------+-----------------+-----------+ | JobId | Name | StartTime | Type | Level | JobFiles | JobBytes | JobStatus | +-------+-----------------+---------------------+------+-------+-----------+-----------------+-----------+ | 1 | JobSchedulePre | 2017-09-19 22:00:11 | B | F | 0 | 0 | T | | 286 | JobSauvegarde | 2017-12-22 22:00:14 | B | D | 114,959 | 6,175,068,638 | T | | 306 | JobSauvegarde | 2017-12-29 22:00:14 | B | D | 114,999 | 6,175,085,183 | T | | 326 | JobSauvegarde | 2018-01-05 22:00:15 | B | D | 115,034 | 6,175,098,492 | T | | 350 | JobSauvegarde | 2018-01-12 22:00:15 | B | D | 98,059 | 2,661,164,629 | T | | 370 | JobSauvegarde | 2018-01-19 22:00:17 | B | D | 135,574 | 7,796,023,727 | T | | 390 | JobSauvegarde | 2018-01-26 22:00:16 | B | D | 170,646 | 11,375,598,061 | T |
Après je ne sais pas pourquoi certains sites tournent sur peu de volumes (recycle régulier) et d'autres beaucoup plus (presque un an de volumes "Inc" à des endroits)...
#2 Mis à jour par équipe eole Academie d'Orléans-Tours il y a presque 6 ans
Je suis tombé sur https://blog.bacula.org/whitepapers/CommunityDiskBackup.pdf
Avec notamment son paragraphe sur 1.4 Truncate Volume on Purge intéressante pour ce signalement.
J'ai aussi vu https://www.bareos.com/en/company_news/bareos-16-2-5-maintenance-release-published.html qui dit
The new action 'truncate on purge' directly deletes old backup volumes on disk storage, making it free for other purposes.
Du coup l'action est-elle limité à certaines versions du logiciel ? (on est en bareos 14.2 sur des eole 2.5.2)
Ou faut-il comprendre qu'a partir de cette version de bareos 16.2.5, il est possible d'avoir une suppression auto des volumes sur le disque ?
#3 Mis à jour par Emmanuel GARETTE il y a plus de 5 ans
Je met ci-joint le script adapter au contexte d'EOLE :
bareosmount.py --mount ./unused.sh -t ./unused.sh -p ./unused.sh -Dp ./unused.sh -Do bareosmount.py --umount
Ajouter “Action On Purge = Truncate” à tous les Pools via un patch (voir : http://doc.bareos.org/master/html/bareos-manual-main-reference.html#directiveDirPoolAction%20On%20Purge ).
#4 Mis à jour par Gilles Grandgérard il y a environ 5 ans
- Tracker changé de Demande à Scénario
- Début
14/06/2018supprimé
#5 Mis à jour par Gilles Grandgérard il y a plus de 4 ans
- Projet changé de creole à eole-bareos
#6 Mis à jour par Gilles Grandgérard il y a plus de 4 ans
- Release mis à Carnet de produit (Cadoles)
#7 Mis à jour par Gilles Grandgérard il y a plus de 4 ans
- Points de scénarios mis à 4.0
#8 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Echéance mis à 11/10/2019
- Version cible mis à Prestation Cadoles 39-41
- Début mis à 23/09/2019
#9 Mis à jour par Benjamin Bohard il y a plus de 4 ans
Bareos privilégie la création de nouveau volume au recyclage des anciens tant qu’il a la place pour le faire. Il faudrait s’assurer qu’utiliser l’option Truncate n’aboutisse pas à un autre problème si Bareos remplit l’espace disque sans que l’espace reste alloué aux volumes qu’il pourrait potentiellement utiliser.
Pour limiter l’espace disque utilisé, il existe également d’autres méthodes impliquant de limiter le nombre de volumes que Bareos est autorisé à créé et en forçant le recyclage des plus anciens volumes.
#10 Mis à jour par Matthieu Lamalle il y a plus de 4 ans
On fournit un indicateur pour que l'administrateur soit en mesure d'adapter la configuration de bareos en fonction de l'espace disque disponible et en prévision de la prochaine sauvegarde, basée sur la taille des sauvegardes précédentes.
Il faut reporter et commenter cela dans la doc pour assister l'administrateur quant aux décisions qu'il peut prendre selon ces indications.
#11 Mis à jour par Daniel Dehennin il y a plus de 4 ans
- Lié à Tâche #29065: Validation du scénario : bareos - voir comment limiter la taille occupée par les volumes dépassant la rétention ajouté
#12 Mis à jour par Fabrice Barconnière il y a plus de 4 ans
- Statut changé de Nouveau à Terminé (Sprint)
#13 Mis à jour par Fabrice Barconnière il y a plus de 4 ans
- Statut changé de Terminé (Sprint) à En cours
#14 Mis à jour par Fabrice Barconnière il y a plus de 4 ans
- Statut changé de En cours à Terminé (Sprint)
#15 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Release changé de Carnet de produit (Cadoles) à EOLE 2.7.1.2