La plupart du temps il est intéressant de chercher l'outil qui permet de répondre à un besoin plutôt que d'en bidouiller un dans son coin. Mais il y a des cas où les outils sont juste sur-dimensionnés par rapport à l'usage, surtout lorsque l'usage concerne son réseau domestique. Et s'il ne sont pas sur-dimensionnés, on se retrouve en permanence à cherche comment faire ceci ou cela...

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 tutoriel est donc nous 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, ssh et Bash.

rdiff-backup ?

Jusqu'à hier j'utilisais rsync pour faire mes sauvegarde, jusqu'à que AP attire mon attention sur rdiff-backup. Je l'en remercie chaudement et c'est entre autre ce genre de pointeurs qui me donne envie de poursuivre ce site.

Pour revenir à rdiff-backup, il s'agit d'un programme écrit en python qui utilise la librairie de rsync pour la constitution des deltas. L'idée de base est donc, comme pour rsync, de synchroniser deux dossiers distants, mais à la différence de rsync, rdiff-backup historise à chaque sauvegarde les deltas récupérés. Le résultat est que non seulement les données sont sauvegardées, mais que l'on dispose aussi d'un historique permettant de remonter dans le temps pour le même coût machine et réseau.

Pour mémoire, mon ancienne méthode d'historisation passant par des par des hardlinks a été déplacée ici.

Sauvegarder pour quoi faire ?

Le meilleur moment dans la vie où l'on peut se poser cette question, est celui où notre disque vient de se faire uriner dessus par le chat du voisin et qu'il se met à crépiter comme un joyeux feu de la Beltane. Ca vous apprendra à laisser votre PC les tripes à l'air... le super magnifique SATA II Tera, gavé à bloc des photos et vidéos du petit dernier, 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.... Là, on se fait généralement la remarque qu'une sauvegarde automatisée aurait été bien utile...

Car c'est connu, 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. Alors si vous avez deux trois connaissances en Bash, voilà comment faire.

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. On peut cependant 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 par 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. En revanche il nous faut quelque chose de plus régulier, comme toutes le 1/4 d'heures. Et dans tous les cas, l'idéal est la possibilité de remonter dans le temps. En gros, juste avant que votre progéniture n'ait effacé du disque dur le dossier BétaDur que vous étiez sur le point de livrer au client, ou juste avant la mise à jour dans laqelle 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... C'est à ce genre de mésaventure que répond l'historisation que nous allons découvrir plus loin.

L'approche Bash

Je prend un peu d'avance sur les 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.

L'approche est donc de se fabriquer une librairies très simple (toujours, au début...) de fonctions écrite BASH 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. Cet outil permet de synchroniser via SSH deux dossiers (local et distant) en ne faisant circuler sur le réseau que ce qui est différent. Un petit coup de man rsync pour avoir plus d'idée sur le sujet.
• L'historisation est rendue possible grâce aux hardlinks. Là aussi, si cela ne vous parle pas, allez faire un tour sur cet article, au chapitre \"Une application du hard-link, l'historisation du pauvre\" pour de plus amples détails sur cette méthode.

Maintenant, histoire de savoir où l'on avance, je vais commencer par la fin, avec ce à quoi ressemblerait un script de sauvegarde :

Le premier bloc de ligne inclus juste le fichier .sh contenant notre future librairie de sauvegarde. Ensuite nous utilisons une fonction de cette librairie use_storage pour déclarer un espace de sauvegarde qui va recevoir des données.

Maintenant que l'espace de stockage est préparé, nous utilisons la commande check_host qui va aller faire un ping sur la machine distante et exécuter le bloc si elle est vivante. Après c'est la fonction synchronize qui va recopier le dossier /etc de la machine distante dans notre espace de stockage. La même chose est faite pour le dossier mails avec comme action préalable d'arrêter le service qui l'utililise et de le relancer lorsque c'est terminé.

Pas si compliqué non ? Maintenant voyons ce que nous avons dans la boîte à outils.

Ecriture de la boîte à outils

Les traces

Commençons par le plus simple, quelques fonctions nous permettant d'afficher des traces dans la consoles. Il s'agit de traces colorisées utilisant des codes ANSI . Cependant la procédure _trace à laquelle toutes les autres font appel est normalement assez intelligente pour injecter ces données dans syslog dés que le script est lancé par CRON.

Préparation du stockage

Là rien d'extraordinaire, juste la création du dossier cible avec l'utilisation d'un fichier 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 le lock. :

Au final, la fonction use_storage va définir une variable storage_path utilisable par les autres parties de notre sauvegarde.

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

Lorsque la machine est présente, la fonction renvoie un code de retour 0, sinon c'est le code d'erreur 1. Du coup, nous pouvons lier la sauvegarde très facilement à la présence effective de la machine :

Outre cette vérification, la procédure défini trois variables qui vont être utilisable plus tard. host_name qui est le nom de la machine, host_url qui est l'URL d'accès à la machine. Par défaut étant une machine distante nous lui donnons pour valeur $host_name:: qui indiquera à rdiff-backup qu'il s'agit d'une machine accessible par SSH. Et enfin host_storage_path qui est par défaut le storage_path défini par la fonction use_storage simplement augmentée du nom du host.

Si notre machine est locale, c'est à dire si l'on cherche à sauvegarder des données présente sur le serveur de sauvegarde lui-même, il serait bébête de passer par SSH plutôt que de fonctionner en local directement. C'est à cela que sert la fonction set_host_as_local. En interne il s'agit simplement de mettre à vide la valeur de host_url, rien de sorcier donc. Du coup, le chemin de la source ne sera plus machine::/chemin mais simple /chemin.

La même technique d'altération de l'url du host sera utilisée plus tard pour rendre notre système compatible avec les partages Windows.

Synchronisation

Nous somme maintenant au coeur de notre sauvegarde et allons introduire dans la librairie, la synchronisation d'un dossier distant avec notre espace de stockage. Grâce à rdiff-backup, cette fonction est assez raccourcie.

Et elle s'utilise comme cela :

Le premier paramètre est le chemin sur le host courant qu'il faut synchroniser avec rdiff-backup dans notre storage. Par défaut les historiques vieux de plus de deux semaines sont supprimés après la sauvegarde. Le second paramètre est un filtre d'exclusion qui sera directement passé à rdiff-backup. Vous pouvez donc aller voir sur la documentation de ce dernier pour voir de quoi il en retourne.

Le cas Windows

Il peut être aussi utile de pouvoir backuper une machine Windows qui elle ne dispose pas d'accès SSH. Alors évidement on peut installer SSH sous Windows et utiliser du coup la même mécanique que précédemment. Ou alors, on définit sous Windows un partage sur le disque C (par exemple) avec tous les droits qui vont bien, pas pour tout le monde, et en lecture seulement. Ensuite il suffit de faire un montage CIFS (le protocole de partage sous Windows) et de synchroniser comme plus haut ce dossier une fois "monté".

Pour faire cela sans modifier notre système, nous allons tout simplement créer une procédure qui va modifier la variable host_url et y injecter le nom du montage CIFS :

Ensuite pour utiliser cette fonction, il suffit de l'appeler avant de faire la synchronisation :

Le premier paramètre est la ressource partagée sous Windows, et le second, une option standard directement ajoutée à mount.cifs. Ici nous passons en paramètre un fichier contenant le login et le mot de passe du partage :

On aurait aussi pu remplace ce paramètre par user=gaston,password=secret mais c'est un peu moins sérieux. Ceci fait, nous pouvons utiliser synchronize comme d'habitude en lui passant un chemin dans le partage :

Les services

Pour sauvegarder des choses comme la base courrier d'un serveur IMAP, ou les données d'une base de donnée mySQL ou PostgreSQL, nous avons deux approches. Soit nous utilisons une méthode dite "à chaud", c'est à dire sans éteindre le service. Soit nous éteignons le service et nous copions ses données tout simplement.

Le problème de la méthode "à chaud" est qu'elle est différente pour chaque application, si elle existe. Pour simplifier nous allons donc utiliser la méthode par arrêt de service qui fonctionne dans tous les cas avec comme inconvénient de ne plus pouvoir accéder aux courriers ou à la base pendant la sauvegarde. Inconvénient très limité si l'on fait la sauvegarde à 3h du matin.

Du coup, la seule chose qui nous manque maintenant est une fonction qui arrête les servicesà distance et qui les relance ensuite :

Il s'agit là d'une utilisation très basique de ssh pour lancer une commande distante. Pour l'utiliser c'est assez simple :

Voilà donc le premier jus de notre librairie achevé, reste à écrire les scripts de sauvegarde à propement parler.

Utilisation de la librairie

Sauvegarde \"live\"

Ce script de sauvegarde cible les données qui bougent souvent et qui nécessite une mise à jour régulière et une historisation. On utilise ici l'historisation intégrée à rdiff-backup pour bénéficier d'une profondeur de 2 semaines.

Une fois le script créé, je vous conseille de le lancer une première fois à la main histoire de le tester mais aussi de faire la première recopie qui sera toujours la plus longue.

Ceci fait, il nous suffit de créer un fichier /etc/cron.d/backup.cron qui indiquera au service CRON quant lancer notre scripts. Je pars ici du principe que ces scripts, comme backup.cron, ont été rendus exécutables par un chmod +x .. et qu'il est, avec la librairie, dans le dossier /usr/bin :

Voilà, un petit coup de /etc/init.d/cron restart (je suis même pas sur que ce soit nécessaire) et le tour est joué. Scrutez un peu les logs pour voir les scripts se lancer. Le CRON va lancer le script toutes les 15 minutes et ainsi nous assurer une historisation optimum. De plus le fait de le lancer tous les 1/4 d'heures, permet d'attraper au vol les machines mobiles qui se connectent par WIFI.

Sauvegarde "journalière"

Dans la sauvegarde journalière, nous pouvons caser des opérations un peu lourdes. A deux heures du matin il est rare que cela pose problèmes aux honnêtes gens. Les données que nous allons inclure dans ces sauvegardes sont donc les bases de données et les fichiers volumineux (vidéo, photos, etc..).

Après le tout est d'être malin et de maximiser la sécurité et l'espace de stockage. En effet la sagesse et les bonnes pratiques nous dictent que d'une manière ou d'une autre les données doivent être sur un média séparé. Cela implique donc qu'une fois que nous avons tout bien sauvegardé, il nous reste encore à mirrorer toutes nos sauvegardes (historisées et journalières) sur un média externe qui peut être un site distant (le top), un DVD-RAM (contraignant) ou, ma solution préférée, sur un disque externe reliée en USB.

Donc pour être malin, autant ne pas gaspiller d'espace et directement faire notre sauvegarde "journalière" sur ce support externe. Cela inclus donc les historisations, les bases de données et les fichiers lourds. Et pour être le plus serieux possible, il faut monter ce support externe, écrire dessus, puis le démonter après usage de sorte à le rendre totalement inaccessible le reste du temps.

Pour le montage du disque en utilisant /dev/disk/by-id, je conseille d'aller regarder cette , c'est vraiement très pratique.

Comme pour les scripts précédent, il est sage de lancer d'abord ce script à la main pour en vérifier le fonctionement, surtout qu'il risque d'être assez long au démarrage.

Ensuite nous pouvons rajouter dans notre /etc/cron.d/backup.sh la ligne qui le lance toutes les nuits à 2h du matin :

Et voilà pour notre sauvegarde journalière.

Conclusion

A l'origine ma librairie de backup faisait 150 lignes. Aujourd'hui, en grande partie grâce à rdiff-backup, elle n'en fait plus que 94... Et le tout font ce qu'on leur demande sans broncher, et sans prendre plus de resources que nécessaires.

Après le concept de "mini agents" via SSH peut être étendu à d'autres secteurs tout aussi simplement, par exemple en dévoyant les plugins de nagios pour récupérer des valeurs (état des disques, mémoires, cpu, etc..) sur les machines du réseau et en stockant le tout dans une base type "Round-Robin" pour l'exploiter avec Cacti. Mais ça, c'est une autre histoire...

Les sources

Les sources de cette librairie est disponible par un :

Où si vous n'avez pas subversion, allez simplement ici.

Commentaires