Un domaine doté d'un nombre impressionnant d'outils libres est celui de la sauvegarde. Et pourtant, lorsque l'on fait tourner sa petite toutouille perso, des monstres comme Amanda font l'effet de massues à écraser les mouches. L'objectif de ce billet est donc le même que ça précèdent version : permettre de faire nos sauvegardes en tout simplicité, en mettant en oeuvre des concepts professionnels (synchronisation distante, mirroring, historisation) mais simplement armé des outils basiques que sont rsync et ssh.

avant-propos

Ce type de sauvegarde ne convient qu'au contexte d'une architecture domestique ou approchant (TPME, Indépendant, etc.). Pour tous les autres, il existe des outils tout faits et même dans certains cas plus ergonomiques (typiquement pour la sauvegarde de son seul poste de travail).

Je devance donc un peu certains commentaires : ce n'est pas la peine de me dire qu'il existe des outils faisant tout cela très bien car le but ici est justement de faire le sien aux petits oignons, adapté au plus prés de nos besoins. L'avantage est qu'un outil que l'on connaît est plus facile à mettre au point qu'une usine à Gaz qui change à chaque version. De plus il vous sera possible d'ajouter des petits détails propres à votre installation qu'un système de sauvegarde trop simple ne saura pas gérer.

Principe de l'historisation

Le principe d'historisation est repris de cet article. Je ne reviens donc pas dessus. Cependant la manière d'utiliser ici les hardlinks est un peu différente. L'idée est d'avoir dans notre dossier de stockage, deux sous dossiers current et history. A chaque rotation, le dossier current, qui contient les dernières données sauvegardées est hardlinké de manière récursive dans un sous-dossier de history portant comme nom la date et l'heure de la rotation. Ensuite on ne va garder que les N dossiers les plus récents en détruisant les plus anciens.

Ainsi, si vous lancez une sauvegarde toutes les 15 minutes et que l'on garde, disons 100 rotations, vous disposez de la possibilité de remonter en arrière dans le temps de 50 heures par tranches de 15 minutes.

Dans la précédente version de ce tutoriel, j'avais utilisé rdiff-backup pour effectuer ce travail. L'expérience m'a prouvé qu'utilisé massivement, cet outil n'est juste pas fiable. A deux reprises je me suis retrouvé avec des deltas corrompus et l'impossibilité de revenir en arrière dans le temps. De plus le système par hard-links permet de récupérer très simplement un snapshot en faisant un rsync. Avec rdiff-backup, on doit passer par divers paramètres pour arriver d'une utilisation beaucoup moins évidente, même s'il s'agit là d'une question d'habitude.

Sauvegarder pour quoi faire ?

Le meilleur moment dans la vie pour prendre conscience de l'intérêt d'une sauvegarde est celui où notre disque se met à crépiter tel un joyeux feu de la Beltane. Un tera gavé à bloc des photos et vidéos du petit dernier qui n'est alors plus qu'une brique aussi fumante que votre compagne qui vous interroge de cet air redoutablement inquiet : T'as bien une copie quelque part, dis.... A ce stade, on se fait généralement la remarque qu'une sauvegarde automatisée aurait été bien utile... Car c'est reconnu par une utilisation quelque peu foireuse de la loi de Murphy : la sauvegarde automatique est réputée pour éloigner le mauvais oeil et allonger la durée de vie des disques durs...

Sauvegarder quoi ?

La bonne réponse est tout !!!. Du moins tout ce qui n'est pas installable : documents de travail, photos, vidéos, configurations, etc. Mais il est possible de distinguer trois catégories dans ce "tout"

• Les données qui changent régulièrement : documents de travail, configuration de machines, etc...
• Les bases de données au sens large : courriels d'un serveur IMAP, base mySql ou PostgreSQL, gestionnaire de version (CVS, Subversion, etc.).
• Les données lourdes qui changent peu mais qui augmentent en de grandes portions : vidéos, photos, ressources en tout genre.

Les deux derniers cas, s'accommodent généralement assez bien d'une sauvegarde journalière simple, sans historisation. En revanche pour la première catégorie, il nous faut quelque chose de plus régulier avec la possibilité de remonter dans le temps. Cela permet de tordre le cou au cas classique de l'effacement accidentel du dossier BétaDur que vous étiez sur le point de livrer au client, ou celui de la mise à jour pour laquelle les mainteneurs de la Mandriva ont décidés pour dieu sait quelle raison que la configuration de votre PostFix était toute pourrie et qu'il fallait impérativement vous la pourrir plus encore plus...

L'approche Perl

La précédente version de ce tuto utilisait bash (elle est encore disponible en révision). Le problème de bash c'est que l'on est vite gêné aux entournures, obligé à faire de terribles jonglages à coup de tubes, awk et autres sed. Perl est donc devenu peu à peu mon langage de script favoris. Sa syntaxe permet d'écrire à peu prés aussi rapidement qu'en bash avec plus de rigueur, et donc moins d'effets de bord. Enfin ses librairies sont tellement nombreuses qu'il est rare de ne pas en trouver une qui colle parfaitement à un besoin.

Notre but est donc de fabriquer une librairies Perl très simple que nos scripts de sauvegarde utiliseront. Pour ce faire nous allons utiliser quelques concepts clef qui convient de bien comprendre :

• Utilisation de SSH pour aller chercher les données à sauvegarder sur les autres machines que celle qui fait physiquement la sauvegarde. Pour cela nous "lions" les machines les unes aux autres grâce à des clefs publiques/privées. Notre librairie n'aura donc besoin d'aucun mot de passe car elle sera utilisée par "root". Si le serveur SSH utilise un port non standard, ce qui est conseillé pour une machine accessible du réseau publique, le fichier /etc/ssh_config sera paramétré pour que l'accès se fasse sans avoir à spécifier le port. Si vous ne vous sentez pas à l'aise avec tout cela, allez faire un tout ici
• Le transport des fichiers d'une machine à l'autre utilise rsync selon que l'historisation est nécessaire ou pas. Ces deux outils permettent de synchroniser via SSH deux dossiers (local et distant) en ne faisant circuler sur le réseau que ce qui est différent. Faites un petit coup de man rsync pour avoir plus d'idée sur le sujet.

Maintenant, histoire de savoir où l'on avance, nous allons commencer par la fin, avec ce à quoi ressemblerait un script de sauvegarde "live", c'est à dire celui correspondant à notre première catégorie de choses à sauvegarder : les données qui changent souvent.

Pas si compliqué n'est-ce pas ? Voyons un peu comment tout cela se goupille.

La librairie

L'idée n'est pas ici de donner un cours de perl, je ne vais donc pas coller le code de la dizaine de procédure que la librairie contient mais plutôt en expliquer l'utilisation. Les sources sont dans tous les cas disponibles ici.

Préparation et libération du stockage

La fonction use_storage et release_storage ne font rien d'extraordinaire. La première va juste créer du dossier cible et surtout y coller un fichier vide, lock pour éviter que la procédure soit ré-entrante. Ainsi si un autre programme travaille sur notre dossier de stockage, la procédure user_storage va nous bloquer jusqu'à ce que le précédent programme ait terminé. release_storage détruit donc ce lock.

Définition des machines

Une fois le stockage définit, l'idée est de vérifier que la machine que l'on cherche à backuper est bien présente sur le réseau. Pour cela nous utilisons la fonction check_host qui exploite la libraire Net::Ping. La seule astuce est de régler le protocole à icmp. En effet par défaut cette librairie fait un ping via tcp, ce qui n'est pas compatible avec une machine ayant un firewall qui restera du coup invisible à la sauvegarde.

L'autre objectif de la fonction check_host est de définir la machine source tout d'abord par son nom usuel (name) puis optionnellement par son adresse IP (address). Si l'adresse IP est mise, c'est le nom de la machine qui est utilisé.

Dans tous les cas un sous-dossier du nom de cette machine va être créé sous celui défini dans use_storage. C'est là que ce feront toutes les sauvegarde. Lorsque la sauvegarde se fera, la structure complète du dossier à sauvegardé sera créé en dessous de se sous-dossier. Le paramètre root permet quant à lui de tronquer une partie du début du chemin en indiquant une racine distante de sauvegarde. Ainsi dans le cas d'une sauvegarde CIFS (windows), la racine indique de ne pas prendre en compte le C mais de commencer directement avec le début du chemin à sauvegarder.

La paramètre fs permet de nuancer la manière dont est vue la machine. Par défaut c'est ssh, signifiant que ssh sera utilisé pour se lier à la machine distante. La méthode local indique quant à elle que nul n'est besoin de SSH, qu'il faut faire une copie local. Enfin nous avons la méthode cifs qui va consister à monter le dossier windows avant de sauvegarder et ftp qui va utiliser wget plutôt que rsync-backup.

Enfin le paramètre method définit l'outil utilisé pour la synchronisation. Il peut s'agir rsync (par défaut).

Synchronisation

La définition de la machine faire par la commande check_host permet de simplifier au maximum la syntaxe des dossier à sauvegarder. La librairie sait en effet déjà quelle est l'adresse de la machine, la destination de sauvegarde, le type de système de fichier (local, ssh, ftp ou cifs) et l'outil de synchronisation à utiliser (rsync). Il ne reste plus donc qu'à donner les dossiers à sauvegarder par la commande add_folder.

add_folder prend en premier paramètre le chemin local sur la machine à sauvegarder et en second, optionnellement, un nom de fichier d'exclusions. Ce fichier utilise le format natif de la commande de synchronisation utilisé (rsync) et doit se trouve dans le dossier /etc/backup, dans un fichier nommé nom_exclusion.exclusions. Les exclusions portent ici assez mal leur nom car ces fichiers permettent aussi de force la sauvegarde d'un fichier. Par exemple pour un dossier home, cela donne :

Mirroring

Comme nous l'avons vu en introduction, nous allons avoir deux types de sauvegardes. Celles effectuées très souvent, contenant les dossiers qui changent régulièrement. Et celles que l'on fait chaque nuits, contenant les bases de données (mail, postgresql, etc.) et les données lourdes (photos, vidéo, etc.).

Chacune de ces deux sauvegardes va donner lieu à un script en perl comme celui montré plus haut. Celui de la sauvegarde régulière va être très simple et demande à peu prés aucune adaptation. Celui de la sauvegarde journalière est un peu différent car nous allons rsync car historiser les changements sur des photos ou des bases de données n'a que peu d'intérêt (à vous de voir ceci dit).

Ensuite la sauvegarde n'est pas faite en local, mais sur un disque USB. Cette approche permet de limiter les risques électriques entres le serveur et le disque dur externe. Ceci dit ce n'est pas encore le top, et le mieux serait un petit montage qui allume physiquement le disque au moment de la sauvegarde, un électronicien avec une idée simple à mettre en oeuvre ?

Dernier aspect, cette grosse sauvegarde va comprendre nos bases, nos fichiers lourds mais aussi notre précédent dossier de sauvegarde régulière. Ainsi nos fichiers qui changent souvent sont non seulement historisés en local, mais aussi recopiés sur le disque USB pour plus de sécurité.

CRON

Dernière étape une fois que nos deux scripts sont écrits et testés, les mettre en musique en passant par un planning cron :

Conclusion

La librairie de backup fait en 150 lignes tout ce que je lui demande, sans broncher, et sans prendre plus de ressources que nécessaires avec une adaptation à un besoin particulier très rapide à mettre en oeuvre.

Commentaires