Validation de backups

OK, on fait tous des sauvegardes, ou backups, automatisés.

Un des risques est qu'un grain de sable s'immisce dans le processus de backup, et que le fichier de sauvegarde soit au final invalide, c'est-à-dire qu'il ne puisse plus servir à la restauration des données. Pas très pertinent, du coup.

Pour gérer ce risque, on peut disposer d'une machine jumelle, sur laquelle on va régulièrement procéder à une restauration de l'environnement qui a été sauvegardé. Mais il s'agit là de tâches « bas niveau », comme dirait un administrateur système de mes connaissances, et elles ne valident que le processus de restauration, non pas que les données ont été réinstallées avec succès.

Pour illustrer ce risque, imaginons que telle procédure de backup consiste à créer l'archive d'un répertoire. Et que pour un bête problème de configuration qui change, se retrouve archivé un mauvais répertoire ou un répertoire vide. Toutes les opérations techniques de sauvegarde, copie, transfert, et restauration, se passeront bien, mais les données issues de la restauration n'auront aucun intérêt. Et on ne s'en apercevra qu'en cas de besoin... (Ne rigolez pas, ça m'est arrivé).

J'ai donc pensé à automatiser une validation « applicative » de la restauration quotidiennne de mes données sauvegardées.

Prenons l'exemple d'un repository Subversion, qui est le cas le plus critique pour le développement. À intervalles réguliers, j'ai un processus qui :

1. récupère sur une machine dédiée la dernière version du backup du repository
2. extrait les fichiers
3. les installe en tant que repository temporaire, et démarre une instance svnserve (serveur Subversion)
4. simule un client (un poste de travail de développeur), et se connecte au serveur démarré pour rapatrier tous les fichiers
5. fait quelques mesures et validations sur les fichiers ainsi rapatriés : le nombre de projets est supérieur à 10, etc.
   

Au fil du temps, je vérifie que les restaurations de backups vérifient certains critères, comme :

• le numéro de révision Subversion ne cesse de croître avec le temps (non-réversibilité)
• le nombre de projets ne cesse de croître avec le temps (loi d'entropie du développement Java)
  
• la taille de l'archive croît grosso modo avec le temps (avec une tolérance de -2 %, car cela dépend de la compression)

Je pourrais aussi vérifier que :

• le numéro de révision Subversion rapatriée correspond à peu près (à 100 près, par exemple) à la révision Subversion qui est active sur la machine de production
  

J'ai une console qui me permet de suivre ces évolutions.

L'architecture technique que j'utilise est la suivante :

• Le serveur « ref » contient les données de référence, en l'occurrence le repository Subversion utilisé en développement
• [1]. À minuit (0:00), une hot copy est créée localement, compressée, et envoyée par FTP vers le serveur « ftp », qui est une sorte de sas.
  
• [2]. À 1:00, l'archive est récupérée et copiée localement sur « bkp », qui collecte une copie de tous les fichiers de sauvegarde de l'architecture.
• [3]. À 2:00, l'archive est récupérée et copiée localement sur « ci », qui est vu comme un serveur d'intégration continue (Continuous Integration).
• Les fichiers de l'archive sont extraits, installés en tant que repository local, svnserve est démarré, des tests sont passés, etc.
• Un rapport est émis, qui pourra être agrégé aux autres et servi par un Web Service.
  

Une console agrège ensuite les différentes informations. Voici un exemple de tableau de bord :

• La console présente les noms des derniers fichiers de sauvegarde, leur date, leur « âge » en jours, leur taille, et indique s'ils ont fait l'objet d'une restauration ou non.
• La mention « restored » indique que la restauration du fichier a réussi.
• La mention « NO » indique que la restauration n'a pas eu lieu (il y a quelques progrès à faire, visiblement)
• Les mentions « -1 », « -2 », etc. indiquent que le dernier fichier de sauvegarde n'a pas encore fait l'objet de restauration, et que la dernière restauration pour ces données a eu lieu sur l'avant-dernière sauvegarde, l'antépénultième, etc.
  

L'intérêt de la machine sas « ftp » est de pouvoir interdire les accès directs de « ref » vers « bkp », dans le cas de réseaux différents par exemple. Dans le cas où tout ce beau monde est sur le même réseau, on peut s'en passer.

La machine « bkp » a bien comme responsabilité de centraliser tous les backups de l'architecture. On pourrait avoir par exemple :

Une remarque :

• il est intéressant d'imposer que les données de référence soient systématiquement versionnées en amont (exemples : Subversion, un wiki, etc.). Une réflexion à mener pour les données métier si vous voulez mon avis...
  

Bon, je suis bien content. Ça fait longtemps que je souhaitais implémenter ce système.

Et vous ? Quelle garantie vous offrez-vous sur la pertinence de vos backups ? Vous contentez-vous de faire confiance à vos logiciels utilitaires ?

Cela vous paraît un peu compliqué ?... ;-)