Rotation des sauvegarde

L'une des problématiques de l'archivage des sauvegardes est la question de la rotation, ou dit autrement la sélection des sauvegardes à conserver sur le court, moyen et long terme. Une sauvegarde datant de la semaine dernière, voire du mois dernier, devient de moins en moins pertinente : le nombre de sauvegarde archivé doit donc être réduit au cours du temps.

L'enjeu est de mettre en place un ou plusieurs scripts, répondant à certains critères :

  • Pertinence des sauvegardes choisies
    • le nombre de sauvegarde doit réduire au cours du temps selon une logique.
  • Adaptabilité du programme
    • Les scripts sont aisément modifiables pour faire de la gestion de sauvegarde sur d'autres échelles de temps
    • Les scripts disposent de paramètres (nombres de sauvegardes, emplacement)
    • Le format attendu des date de sauvegarde est modifiable
  • Simplicité de fonctionnement

Le premier objectif de conception a été de trouver une manière simple de sélectionner des sauvegardes pertinentes.

Suite au constat que les sauvegardes étaient produites de manière régulière, l'hypothèse d'équidistance a été considérée. De ce fait, le calcul des dates pertinentes se réduit à un calcul d'indices de tableau avec un pas constant (Nombre total de sauvegardes / Nombre de sauvegardes à conserver) :

 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|X |  |  |  |  |  |X |  |  |  |  |  |X |  |  |  |  |  |X |  |  |  |  |  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
			Exemple : 4 sauvegardes sur 24 / jour

X : sauvegarde conservée

La second objectif a été la définition des différents scripts :

  • Un premier script réduit le nombre de sauvegarde par jour sur les 6 jours précédents.
    • Aucune sauvegarde sur les dernières 24h ne sera supprimée par ce script.
    • Il est exécuté tout les jours.
  • Un second script réduit le nombre de sauvegarde de la semaine précédente.
    • Aucune sauvegarde sur les 7 derniers jours ne sera supprimée par ce script.
    • Il est exécuté toutes les semaines.
  • Enfin, un dernier script (non déployé pour le moment) est exécuté toutes les 4 semaines pour réduire le nombre de sauvegardes sur 48 semaines.

Il est à remarquer qu'il est théoriquement suffisant pour chaque script de ne traiter que la période de temps la plus proche (jour, semaine, …), c'est à dire la veille pour le script s'exécutant chaque jour, et la dernière semaine pour celui s'exécutant chaque mois.

Cependant, dans le cas ou un script ne peut être exécuté pour une raison quelconque (panne, machine éteinte) à l'heure prévue, le traitement se fera à la prochaine exécution puisque chaque script traite plusieurs périodes de temps (6 derniers jours, 3 dernières semaines).

Le choix du langage Bash a été décidé pour l'écriture des scripts. Leur fonctionnement est similaire, et se découpe en 3 étapes :

  1. Recensement des dates utiles, la date de départ étant la plus récente.
    • weekrotator.sh : 6 tableaux représentant les 6 derniers jours * monthrotator.sh : 3 tableaux représentant les 3 dernières semaines
    • year_rotator.sh : 11 tableaux représentant les 11 derniers mois
  2. Sélection des sauvegardes à conserver dans chaque tableau (par calcul des indices)
  3. Suppression des sauvegardes non conservées.

Les fonctions communes aux différents scripts sont issues de différents fichiers dans le dossier lib :

  • date : Traitement des dates
    • Conversion de date entre :
      • le format de sauvegarde choisi,
      • le format Unix (utilisable avec le programme binaire date)
      • le format Timestamp (utile pour le calcul d'intervalle de date)
    • Calcul de la différence entre deux dates dans n'importe lequel des formats
    • Ajout de quantité de temps (seconde, minute, heure, semaine) à une date
  • array : Manipulation simplifiée de tableaux en Bash (insertion, suppression, lecture, écriture)
  • functions : Fonctions spécifiquement utiles aux scripts (calcul d'index, suppression des sauvegardes)

Par ailleurs, les scripts sont lancés automatiquement grâce à des tâches cron.

Quels paramètres

Les scripts mis en place au sein de l'infrastructure de Picasoft fonctionnent avec les paramètres suivants :

  • weekrotator.sh <dossier des sauvegardes> 4 : 4 sauvegardes par jour de la semaine * monthrotator.sh <dossier des sauvegardes> 14 : 14 sauvegardes par semaine (2 par jour de la semaine)
  • year_rotator.sh <dossier des sauvegardes> 2 : 2 sauvegardes par 4 semaines

Étant donné que les scripts sont exécutés à la fin de la journée prévue, les résultats suivants sont attendus.

Pour week_rotator.sh :

Heure : 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |X |  |  |  |  |  |X |  |  |  |  |  |X |  |  |  |  |  |X |  |  |  |  |  |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
		Légende : 4 sauvegardes sur 24 par jour de la semaine courante

X : sauvegarde conservée

Pour month_rotator.sh :

    Jour n°1        Jour n°2        Jour n°3        Jour n°4        Jour n°5        Jour n°6        Jour n°7   
+---------------+---------------+---------------+---------------+---------------+---------------+---------------+
|  23 11 05 00  |  23 11 05 00  |  23 11 05 00  |  23 11 05 00  |  23 11 05 00  |  23 11 05 00  |  23 11 05 00  |
| +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ |
| |X |  |X |  | | |X |  |X |  | | |X |  |X |  | | |X |  |X |  | | |X |  |X |  | | |X |  |X |  | | |X |  |X |  | |
| +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ | +--+--+--+--+ |
|               |               |               |               |               |               |               |
+---------------+---------------+---------------+---------------+---------------+---------------+---------------+
		Légende : 7 sauvegardes sur 14 / semaine sur les 3 dernières semaine

X : sauvegarde conservée

L'image Docker

Afin de faciliter l'intégration de ces scripts dans l'infrastructure de Picasoft, une image Docker a été mise à disposition sur le Gitlab (pica-backup-rotation). Un script au démarrage de l'image Docker inscrit 3 tâches cron par sous-dossiers du dossier /backup :

  • Exécution du script weekrotator.sh à 23h00 chaque jour * Exécution du script monthrotator.sh à 23h00 chaque Dimanche
  • Exécution du script year_rotator.sh à 23h00 chaque Dimanche, cependant celui-ci dispose d'un mécanisme interne qui fait qu'il ne s'exécute qu'une semaine sur 4.

Dans l'exemple ou nous disposons de deux services mattermost et etherpad dont les sauvegardes sont respectivement contenues dans les dossiers /DATA/BACKUP/mattermost et /DATA/BACKUP/etherpad. Pour chacun de ces deux services, des sauvegardes sont produites chaque heure.

On utilise une configuration docker-compose telle que celle ci-dessous :

pica-backup-rotation:
  image: registry.picasoft.net:5000/pica-backup-rotation:1.0
  container_name: pica-backup-rotation
  volumes:
    - /DATA/BACKUP/:/backup
    - /etc/localtime:/etc/localtime:ro

Ainsi, si nous sommes un Mardi à 23h00, le script week-rotator.sh s’exécutera, ne laissant que 2 sauvegardes par jour entre le Mercredi précédent et ce Lundi inclus. Si nous sommes un Dimanche à 23h00, le script month-rotator.sh s’exécutera aussi, ne laissant que 7 sauvegardes par semaine sur les trois semaines précédentes (pas celle courante).

Cela donne les résultats suivants :

Sauvegardes de la journée :

2018.01.01.230001.sql
2018.01.01.220001.sql
2018.01.01.210001.sql
2018.01.01.200001.sql
2018.01.01.190001.sql
2018.01.01.180001.sql
2018.01.01.170001.sql
2018.01.01.160001.sql
2018.01.01.150001.sql
2018.01.01.140001.sql
2018.01.01.130001.sql
2018.01.01.120001.sql
2018.01.01.110001.sql
2018.01.01.100001.sql
2018.01.01.090001.sql
2018.01.01.080001.sql
2018.01.01.070001.sql
2018.01.01.060001.sql
2018.01.01.050001.sql
2018.01.01.040001.sql
2018.01.01.030001.sql
2018.01.01.020001.sql
2018.01.01.010001.sql
2018.01.01.000001.sql

Jour n°2

2017.12.31.230001.sql
2017.12.31.170001.sql
2017.12.31.110001.sql
2017.12.31.050001.sql

Jour n°3

2017.12.30.230001.sql
2017.12.30.180001.sql
2017.12.30.120001.sql
2017.12.30.050001.sql

Jour n°4

2017.12.29.230001.sql
2017.12.29.170001.sql
2017.12.29.110001.sql
2017.12.29.050001.sql

Jour n°5

2017.12.28.230001.sql
2017.12.28.170001.sql
2017.12.28.110001.sql
2017.12.28.050001.sql

Jour n°6

2017.12.27.230001.sql
2017.12.27.170001.sql
2017.12.27.110001.sql
2017.12.27.050001.sql

Jour n°7

2017.12.26.230001.sql
2017.12.26.170001.sql
2017.12.26.110001.sql
2017.12.26.050001.sql

Semaine n°2

2017.12.25.230001.sql
2017.12.25.110001.sql

2017.12.24.230001.sql
2017.12.24.110001.sql

2017.12.23.230001.sql
2017.12.23.110001.sql

2017.12.22.230001.sql
2017.12.22.110001.sql

2017.12.21.230001.sql
2017.12.21.110001.sql

2017.12.20.230001.sql
2017.12.20.110001.sql

2017.12.19.230001.sql
2017.12.19.110001.sql

Semaine n°3

2017.12.18.230001.sql
2017.12.18.110001.sql

2017.12.17.230001.sql
2017.12.17.110001.sql

2017.12.16.230001.sql
2017.12.16.110001.sql

2017.12.15.230001.sql
2017.12.15.110001.sql

2017.12.14.230001.sql
2017.12.14.110001.sql

2017.12.13.230001.sql
2017.12.13.110001.sql

2017.12.12.230001.sql
2017.12.12.150001.sql

Semaine n°4 etc…

Avec le script de test

Un script de test est présent dans les sources (test.sh). Celui permet de vérifier le bon fonctionnement des scripts en générant des sauvegardes sur une année, et en appliquant les scripts au bon moment.

Afin de vérifier le bon fonctionnement, il faut regarder l'évolution des fichiers de sauvegardes au cours de l’exécution :

  • Le script weekrotator.sh réduit-il le nombre de sauvegarde à X pour le jour précédent ? * Le script monthrotator.sh réduit-il le nombre de sauvegarde à Y pour la semaine précédente ?
  • Le script year_rotator.sh réduit-il le nombre de sauvegarde à Z pour l'année précédente ?

Sur l'environnement d’exécution de l'image Docker

Voici les quelques vérifications qu'il est possible de faire sur un environnement d'éxécution :

  • Vérifier le fonctionnement des scripts avec les questions posées dans la section précédent, mais en regardant dans le dossier de sauvegarde (/DATA/BACKUP/<nom du service> sur l'infrastructure de Picasoft) au lieu d’exécuter test.sh

L'utilisation du langage Bash pour ce type de rotation ne s'avère pas être le meilleur candidat en terme de langage, notamment concernant :

  • la manipulation de tableaux : La manipulation de tableaux en Bash n'est pas des plus naturelles, surtout concernant le passage de variables de ce type dans des fonctions. Pour pallier à celà, une bibliothèque (fichier lib/array) propose des fonctions de lecture, écriture de tableaux, mais n'est pas comparable à une gestion native comme en Python par exemple.
  • la transformation des formats de date : l'utilisation de awk pour transformer un format de date en un autre semble limiter fortement les performances de traitement.
  • Les résultats des scripts ne sont actuellement pas affichés sur la sortie de l'image docker (docker-compose logs pica-backup-rotation). Il s'agit d'un bug qu'il sera nécessaire de résoudre. Autrement, les logs sont consultables dans l'image à la racine (faire docker-compose exec pica-backup-rotation pour accéder au conteneur)
  • La sortie de test.sh devrait être améliorée, afin de ne pas avoir à suivre l'évolution du script. Il faudrait donc mettre en place un système de vérification autonome (dans l'idéal, n'avoir qu'une sortie vrai/faux).
  • sauvegarde/rotation.txt
  • Dernière modification: 2019/05/13 15:42
  • (modification externe)