Le blog du Fred
• • • • •

1. Introduction

On ne le répètera jamais assez, il est important en informatique d’effectuer régulièrement des sauvegardes de ses données. Dans le cas présent (sauvegarde de données sur un serveur “perso”), ces sauvegardes également sont importantes. Un crash disque est si vite arrivé … Dans cet article, nous allons voir quels sont les répertoires à prendre en compte, les différentes alternatives de sauvegarde, et enfin comment mettre en œuvre la solution retenue.

Nous utilisons dans cette exemple une installation assez “light” d’une Debian unstable, effectuée par net install, sans serveur X. La machine est utilisée comme serveur web (Apache 2.55) , serveur de base de données (MySQL), ainsi que pour des partages de fichiers avec d’autres hôtes Windows (Samba).

2. Que prendre en compte

La solution de facilité consisterait à dire “Je sauvegarde toute la machine”. Néamoins, il faut bien se rendre compte que cette solution est impossible … Partons du cas le plus grave qui puisse arriver, la perte de la totalité de la machine, dûe à un crash disque par exemple. De quoi avons nous besoin pour remettre la machine et les services sur pied ?

La configuration de la machine avant le crash : sous Linux, tous les fichiers de configuration sont stockés dans un répertoire commun : /etc. Ce répertoire sera donc entièrement à prendre en compte lors de la sauvegarde.

Les données et fichiers utilisés par les différents services de la machine (notamment web et sql) : leur emplacement peut varier selon la distribution utilisée. Dans le cas présent (Debian), les documents d’Apache sont stockés par défaut dans /var/www. Le répertoire sera à adapter selon votre configuration. Ce répertoire, ainsi que tout son contenu sera pris en compte dans la sauvegarde. Pour MySQL, nous procéderons un peu différement : les données ne seront pas sauvegardées sous forme de fichier brut, mais sous forme SQL.

Les fichiers des utilisateurs : si votre machine comporte plusieurs comptes utilisateurs (hébergement de site amis par exemple, accessibles via www.votredomaine.com/~utilisateur ), ceux çi seront à inclure dans le processus de sauvegarde. L’emplacement est standard sous les systèmes Unix : /home pour les utilisateurs standards, /root pour le super utilisateur.

3. Où effectuer la sauvegarde

Nous aborderons ici uniquement le cas d’une machine “simple”, qui ne comporte pas de lecteur de bandes comme il est possible d’en trouver sur des serveurs plus élaborés. Trois solutions principales sont possibles : la sauvegarde sur un autre disque dur dans la machine, la gravure des données sur un média optique (CD-R par exemple), ou le transfert des données sur un hôte de sauvegarde (serveur ftp sur Internet ou rsync).

La solution traitée dans cet article est la prèmiere, la sauvegarde sur un autre disque dur. Ce disque est constitué d’une seule et unique partition, montée dans le répertoire /var/backup. Il est possible de trouver facilement sur le web des pages et articles traitant des autres solutions.

4. A propos du temps

Les données étant ammenées à changer assez régulièrement, la sauvegarde devra être quotidienne. Néanmoins, afin de gêner le moins possible les utilisateurs de la machine, la sauvegarde sera exécutée durant la nuit, tard le soir ou tôt le matin. Pour ce faire, le script est appelé par le daemon cron : appeler, en root, la commande crontab -e, et ajouter une ligne du type :

42 5 * * * /usr/local/backup.sh

Le rôle de celle çi est d’exécuter le script de sauvegarde (placé dans /usr/local) tous les jours à 5h42 du matin.

5. Outils utilisés

Afin d’être le plus générique possible dans l’élaboration du script de sauvegarde, nous n’utiliserons que des outils et commandes standard, installées par défaut dans la très vaste majorité des distributions Linux :

• Bash : le shell par défaut sur la Debian;
• Echo : affichage d’une chaîne de caractères sur la sortie standard;
• Find : recherche de fichiers dans une arborescence;
• Xargs : création de ligne de commandes à partir de l’entrée standard;
• Tar : compression;
• Mysql : client MySQL en ligne de commande.

6. Les différentes solutions

Nous avons déterminé lors du second chapitre les différents éléments qui seront pris en compte lors de la sauvegarde. Se pose la question désormais du volume de données à sauvegarder. Voici la taille des données dans notre cas de test :

Nous voyons ici que le volume global à sauvegarder est d’environ 185 Mo. A cela viendra s’ajouter les données de MySQL. Selon la configuration de la machine, plusieurs alternatives sont possibles : soit la sauvegarde de l’intégralité de ces répertoires, soit la sauvegarde incrémentielle. Dans notre exemple, c’est cette seconde solution qui a été retenue.

7. Sauvegarde de l’intégralité des cibles

Dans le cas d’une machine assez généreuse au niveau matériel et notamment de l’espace disque, il est envisageable de sauvegarder l’intégralité des données. Il faut aussi estimer l’évolution du volume des données dans le temps. Pour cela, nous utilisons les différentes commandes listées plus haut. Mis à part pour la partie MySQL, le même traitement est effectué sur tous les répertoires cibles. Le script bash de sauvegarde va être constitué de différents groupes de lignes, basé sur le même modèle, adapté selon le répertoire sur lequel le script s’applique.

OF=/var/backups/www-$(date +%Y%m%d).tar.gz
echo “Backing up web directory to $OF”
tar -czf $OF /var/www
echo “Done !”

Nous commençons par créer une variable nommée OF (OutputFile), qui va contenir le nom du fichier de destination de la sauvegarde. Ici, la date du jour va être intégrée directement dans le nom du fichier. Ce dernier sera donc du type www-20060929.tar.gz, pour la sauvegarde du 29/09/2006.

Ensuite, affichage sur la sortie standard de ce qui est en train de se passer.

Ensuite, l’opération de sauvegarde proprement dite, grâce à la commande tar. Les trois options utilisées permettent de créer une archive (c), compresser l’archive grâce à gzip (z), et de spécifier le fichier de destination (f). Nous indiquons ensuite à tar le nom de fichier, et le répertoire à sauvegarder.

Une fois que l’opération est achevée, un message sur la sortie standard informe de la bonne exécution du processus.

Comme nous avons écrit plus haut, ce processus est appliqué sur les différents répertoires à sauvegarder. Le cas de MySQL sera traité ultérieurement.

8. Sauvegarde incrémentielle

Dans notre cas d’étude, la machine dispose de deux disques durs, de 5 et 10 Go. Le premier d’entre eux est utilisé pour le système, et le second comme disque de stockage des sauvegardes. Nous avons vu au chapitre 3 que le disque est monté dans le répertoire /var/backup. Etant donné l’assez petite taille du disque et du volume de données à sauvegarder quotidiennement, la sauvegarde complète des cibles aurait occupé la totalité du disque dur en moins de 60 jours, voire moins si le volume de données grossit ou si le disque est utilisé pour stocker d’autres données.

Pour économiser de l’espace disque, nous avons choisi une méthode qui diffère de celle vue dans le chapitre précédent. Ne seront sauvegardées uniquement ladifférence dans les cibles entre le jour J et le jour J-1. Afin de créer la liste des fichiers crées ou modifiés durant les dernières 24 heures, nous utilisons la commande linux find. Le groupe de ligne se présente donc de la manière suivante :

OF=/var/backups/www-$(date +%Y%m%d).tar.gz
echo “Backing up web directory to $OF”
find /var/www/ -type f -mtime -1 -print|xargs tar -czf $OF
echo “Done !”

Les commandes sont les mêmes que pour la sauvegarde totale, excepté pour la troisième ligne : notre script va, pour le répertoire en cours, trouver les fichiers modifiés lors des dernières 24 heures, et les afficher sur la sortie standard. Ils sont ensuite interceptés par xargs, qui va les réinjecter dans la ligne de commande de tar. Ce dernier va donc ensuite prendre en compte uniquement les fichiers trouvés par find ! De ce fait, le volume de données à sauvegarder se trouve fortement réduit.

Dans notre exemple, le volume de données sauvegardées quotidiennement est passé de 185 à moins d’1 Mo. Néanmoins, il serait sage de faire assez régulièrement (de façon hebdomadaire par exemple) une sauvegarde intégrale des cibles. Ce cas n’est pas géré ici, mais il est très facile de le mettre en place en jouant avec les options de cron.

9. MySQL

Pour MySQL, le cas est un peu différent : en effet, il serait possible de procéder de la même manière que pour les cibles précédentes, mais la remise en place des fichiers et des tables serait difficile en cas de crash. Nous allons utiliser le client MySQL en ligne de commande, afin d’extraire toutes les informations de la base de données.

OF=/var/backups/mysql-$(date +%Y%m%d).sql.gz
echo “Backing up MySQL data files to $OF”
mysqldump –all-databases -u root –password=”foobar” –default-character-set=latin1 | gzip>$OF
echo “Done !”

Le nom de fichier est construit sur le même modèle que pour les cas précédents. Ensuite, nous appelons la commande mysqldump, qui va permettre de sortir (dumper) toutes les lignes de toutes les bases de données (option –all-databases). Ne pas oublier de préciser ici le compte utilisateur à utiliser et le mot de passe associé. On parle ici du compte utilisateur MYSQL, et non LINUX ! Les lignes renvoyées par mysqldump sont compressées grâce à gzip, puis envoyées dans le fichier de sortie.

10. Idées d’évolution

Nous avons ici vu deux exemples très simples de scripts. Il est possible, moyennant un peu de recherche et de tests, de sauvegarder les données sur un média réinscriptible (grâce à cdrecord) ou d’enregistrer les données sur un serveur sur internet (ftp ou rsync).

11. Téléchargement

Script de sauvegarde complète (581 octets)

Script de sauvegarde incrémentielle (690 octets)