Restauration quotidienne de sauvegardes

Voici un état de mon architecture de sauvegardes, qui a un peu évolué depuis que j'avais parlé du sujet il y a deux ans (voir : Validation de backups, avril 2008).

Architecture

Les nouveautés concernent essentiellement l'ordonnancement.

Sur le plan fonctionnel, les principes sont :

• une sauvegarde complète quotidienne
• une restauration complète quotidienne
• des tests d'acceptabilité sur les données restaurées (par exemple, vérifier que les données qu'on a restaurées ne sont pas constituées de répertoires vides)
  

Sur le plan technique, les principes sont :

• pour tout ce qui concerne les flux entre machines, l'ordonnancement est centralisé
• les flux sont sécurisés (SSH)
• les accès sont sécurisés de machine à machine (restrictions des adresses IP autorisées, etc.)
• on limite les volumes des transferts réseaux (compression BZ2, regroupement des commandes envoyées par SSH…)

L'architecture se synthétise ainsi :


Légende :

• ref — référentiels, « Repositories » : Ce sont les éléments à sauvegarder. En l'occurrence Subversion, un wiki…
  
• m2 — ordonnanceur, « Scheduler »
• bkp — espace de sauvegarde, « Archives »
• tmp — espace temporaire pour restauration
• ci — outil d'intégration continue, « Continuous Integration »

Les machines « ref » et « m2 » sont sur un même réseau local (LAN).

• « ref » est visible sur internet, ports 22 et 80. Sur le LAN elle est dans une DMZ, et en particulier n'accède pas à « m2 ».
• « m2 » n'est pas visible sur internet.
  

Les machines « bkp + tmp » et « ci » sont sur internet, avec leurs accès SSH limités à certaines adresses IP.

Les étapes du processus sont les suivantes :

1. sauvegardes locales sur « ref », par l'outil « backup-manager »
2. copie vers une machine distante qui stocke les archives, avec éventuellement une copie intermédiaire locale sur l'ordonnanceur lui-même
   
3. décompression de la dernière sauvegarde présente dans les archives, restauration, contrôles et mesures
4. copie des résultats des contrôles et mesures, vers une machine d'intégration continue
5. analyse des résultats des contrôles et mesures, tests sur des critères d'acceptabilité
6. [E] si une erreur est décelée, envoi d'un e-mail à l'administrateur

En gros, j'arrête de poser des crontabs partout comme je faisais il y a deux ans (voir article : Validation de backups) ; c'est un plat de spaghetti à administrer, et, quand une machine tombe ou est recyclée, les autres continuent leur semoule sans que ça serve à quoi que ce soit.

L'ordonnancement centralisé facilite les enchaînements.

En revanche, il ne facilite pas forcément la gestion de verrous.

Autre changement par rapport à il y a deux ans, j'écris mes scripts système en Bash et délaisse Ruby, qui n'apportait pas tant que ça.


Contrôles et mesures

Pour un repository Subversion, après restauration des données, les tests d'intégration continue se feront sur les mesures suivantes :

• nom et taille du fichier de sauvegarde restauré => la date doit être celle du jour
  
• dates de début et fin de la restauration => le traitement ne doit pas avoir été trop rapide
  
• numéro de version (Revision) => ?
  
• nombre total de fichiers après checkout => il doit être supérieur à telle valeur
• nombre de fichiers « pom.xml » après checkout => il doit être supérieur à telle valeur
• nombre de fichiers « build.xml » après checkout => il doit être supérieur à telle valeur

L'idée est de repérer les cas de sauvegardes vides, ainsi que les sauvegardes obsolètes.


Quelques idées rejetées

Il est bon de fonder ses choix aussi sur l'historique des choix qui n'ont pas été retenus ;-)


Idée rejetée : copie directe depuis la machine de référentiel vers la machine de backup.


Explication : pourquoi la machine de référentiel devrait-elle avoir connaissance de l'existence d'une machine de backup ? Et en être dépendante ? Et dépenser de la charge et être administrée pour ça ?
L'idée est que les processus de restauration d'archives doivent être vus par ailleurs. La machine à sauvegarder n'a pas elle-même à savoir qu'elle devrait envoyer un e-mail, etc.


Idée rejetée : accès direct depuis la machine de backup à la machine de référentiel.


Explication : on a choisi dans l'architecture de limiter les accès SSH à « ref» depuis l'internet à l'utilisation de Subversion. En particulier, pas d'accès aux utilitaires « ls » et « tar ».


Idée rejetée : stocker les archives sur la machine d'ordonnancement.


Explication : cette machine est dans les mêmes locaux que la machine référentiel. Or on veut évidemment que les données archivées soient physiquement découplées des données d'origine.


Idée rejetée : ordonnancement par cron de la restauration depuis l'espace temporaire.

C'est ce que faisait l'ancienne architecture.



Explication : l'espace temporaire n'a pas à être administré et donc n'a pas à contenir de scripts résiduels ni de crontab.


Idée rejetée : restauration sur la machine d'ordonnancement.


Explication : Il faut que la restauration ait lieu à partir d'un élément archivé (celui qu'on ira réellement chercher en cas de problème), et pas depuis une copie intermédiaire, qui par définition disparaîtra.
De plus, ni la mémoire ni le CPU ne sont suffisants sur cette machine pour une restauration.


Idée rejetée : envoi des résultats directement depuis l'espace temporaire vers la machine d'intégration continue.


Explication : l'espace temporaire n'a pas à connaître la machine d'intégration continue, à y avoir posé sa clef publique, etc.


Idée rejetée : récupération des résultats par la machine d'intégration continue auprès de l'espace temporaire.


Explication : la machine d'intégration continue n'a pas à savoir qu'il existe un espace temporaire (en plus, comment s'y connecter s'il n'est pas résiduel ?)


Variante possible

Une variante qui semble être digne d'intérêt, consiste à stocker les résultats des contrôles et mesures dans les référentiels, et que la machine d'intégration continue y accède.


Quelques avantages :

• l'ordonnanceur n'a plus à connaître la topographie de la machine d'intégration continue
• les résultats des contrôles et mesures sont archivés
• on s'appuie sur le lien de l'ordonnanceur vers la machine référentiel, qui existe déjà
• on s'appuie sur le lien de la machine d'intégration continue vers la machine référentiel, qui existe déjà
• les tests sur les résultats peuvent être lancés depuis n'importe quel environnement qui a accès au référentiel, pas seulement depuis la machine d'intégration continue (donc, pratique pour développer ces tests)
  

Quelques inconvénients :

• le référentiel augmente de façon automatique et ininterrompue, or ce référentiel est lui-même destiné à être sauvegardé et archivé, donnant lieu à des contrôles, qui seront injectés dans le référentiel, etc.
  Certes l'augmentation est d'1 Ko par jour, ce qui est dérisoire, mais techniquement, le principe du mécanisme croissant qui s'alimente lui-même n'est pas bon.
• d'un point de vue fonctionnel ce serait mélanger production et décisionnel.
  Production = référentiel Subversion.
  Décisionnel = tests en intégration continue après extraction de mesures.