Ce petit article indique comment faire des sauvegardes complètes avec une rotation.

Il n’y a rien de bien compliqué, c’est simple à mettre en place et très fiable. Je l’utilise depuis des années sur certains de mes serveurs.

Sauvegarde

Identifier la source

La première chose à faire et d’identifier ce que l’on veut sauvegarder.

Accès aux données

Selon le type de source (une base SQL, un dossier, quelques fichiers, un serveur complet, …), la méthode et les outils d’archivages peuvent différer.

Par exemple pour une base MySQL, on peut utiliser la commande « mysqldump », alors que pour un dossier, le plus efficace est souvent d’utiliser dar (équivalent de tar, mais plus adapté aux sauvegardes sur disque, permet, entre autre, les sauvegardes différentielles).

Types de données

Ensuite selon le contenu de ce que l’on va sauvegarder, il peut être intéressant de compresser les données (par exemple un dossier plein de fichiers de configuration, comme /etc), dans certains cas au contraire, la compression ne sert qu’à consommer des ressources et ne fait pas gagner de place (un dossier plein d’images png).

Automatiser la sauvegarde

Création d’un script

Une fois la méthode de sauvegarde bien identifiée, on en fait un petit script.

On rend le script exécutable par l’utilisateur qui va le lancer (cet utilisateur doit bien entendu avoir le droit de lire se qu’il va sauvegarder !!) et on place les droits de lecture qui vont bien (il peut y avoir des mots de passe, donc ce fichier ne doit pas être lisible par n’importe qui).

L’objectif est d’obtenir un fichier unique contenant nos données.

Exemples de scripts

Voici quelques exemples de scripts. Ils sont à adapter en fonction de vos besoins et de vos outils.

Toutes les bases d’un serveur MySQL

#!/bin/bash
pwd=`pwd`
bkp_serveur='adresse_du_serveur_mysql'
bkp_user='compte_mysql_avec_les_bons_droits'
bkp_password='son super password bien compliqué'
bkp_dossier_destination='/backups/mysql'
bkp_fichier_destination=$bkp_dossier_destination/all-databases.sql.gz
cmd_archive='/bin/gzip'
cmd_mysqldump='/usr/bin/mysqldump'

mkdir -p $bkp_dossier_destination
cd $bkp_dossier_destination
$cmd_mysqldump -h $bkp_serveur -u $bkp_user -p$bkp_password --all-databases | $cmd_archive --rsyncable > $bkp_fichier_destination
chmod 600 $bkp_fichier_destination
cd $pwd

Un dossier complet avec tar

#!/bin/bash
pwd=`pwd`
bkp_source='/chemin/de/la/source /une/autre/source'
bkp_exclude='--exclude /chemin/de/la/source/temp'
bkp_dossier_destination='/backups/documents_importants'
bkp_fichier_destination=$bkp_dossier_destination/documents_importants.tgz
cmd_archive='/bin/tar'

mkdir -p $bkp_dossier_destination
cd $bkp_dossier_destination
$cmd_archive zcf $bkp_fichier_destination $bkp_source $bkp_exclude
chmod 600 $bkp_fichier_destination
cd $pwd

Un dossier complet avec dar

#!/bin/bash
pwd=`pwd`
bkp_source='/chemin/de/la/source'
bkp_dossier_destination='/backups/documents_importants'
bkp_fichier_destination=$bkp_dossier_destination/documents_importants.dar
cmd_archive='/usr/bin/dar'

mkdir -p $bkp_dossier_destination
cd $bkp_dossier_destination
$cmd_archive -c $bkp_fichier_destination -R $bkp_source -w -y -P 'dossier_temporaire' -X '*.tmp' -Z '*.gz' -Z '*.png'
chmod 600 $bkp_fichier_destination
cd $pwd

Tester nos scripts

Avant de rendre tout ça automatique, on test nos différents scripts afin de vérifier que tout fonctionne.

On exécute les différents scripts puis on vérifie que les données résultantes sont bien sauvegardées et intègres (une sauvegarde qui n’est pas utilisable ça ne sert pas à grand chose).

Planification des sauvegardes

Rien de plus simple, on créer une tache planifiée qui va s’occuper de lancer nos scripts de manière périodique => une simple tache cron fera très bien l’affaire

Il faut bien entendu avoir une bonne idée de la périodicité à utiliser (tous les jours, toutes les semaines, …).

La méthode présentée ici ne sait (directement) travailler qu’avec les unités de temps suivantes : jour, semaine, mois.

Exemples :

@daily /mon/script/qui/se/lance/touslesjours.sh
@weekly /mon/script/qui/se/lance/touteslessemaines.sh

Rotation

On va faire simple, plutôt que d’écrire un script qui va gérer la rotation de nos sauvegardes, on va utiliser un outil standard et éprouvé : logrotate

De base dans tous les systèmes Linux, cet outil permet de faire une rotation des fichiers de logs dans /var/log et donc d’éviter de se retrouver avec des fichiers de plusieurs To (déjà vu).

Fonctionnement

Comme un bon exemple vaut mieux qu’un long discours, voici comment logrotate traite le fichier /var/log/syslog :

1. /var/log/syslog.3.gz -> /var/log/syslog.4.gz
2. /var/log/syslog.2.gz -> /var/log/syslog.3.gz
3. /var/log/syslog.1 -> /var/log/syslog.2.gz
4. /var/log/syslog -> /var/log/syslog.1
5. création d’un fichier vide /var/log/syslog (il demande au daemon syslog de le faire)

Utilisation avec nos sauvegardes

Pour que logrotate travail avec nos sauvegardes, il faut simplement les déclarer dans sa configuration (le fichier de configuration accepte d’inclure d’autres fichiers de configuration définis avec « include »).

Voici un exemple de configuration (beaucoup des paramètres sont ceux par défaut, donc peuvent être retirés) :

/backups/mysql/all-databases.sql.gz {
    daily
    dateext
    rotate 56
    nocompress
    nocopytruncate
    ifempty
    nomissingok
    nocreate
    noolddir
    nomail
    extension .sql.gz
}

Les actions réalisées sont les suivantes :

• daily : la rotation doit être effectuée tous les jours
• dateext : au lieu d’avoir un nombre (1, 2, 3, …), on demande d’utiliser une date (par défaut au format YYYYMMDD)
• rotate n : nombre de versions à conserver (ici 56 jours)
• nocompress : on demande de ne pas compresser les versions
• nocopytruncate : ne pas réduire le fichier à zéro après la copie
• ifempty : fait la rotation même si le fichier est vide
• nomissingok : déclenche une erreur (non bloquante) si le fichier n’existe pas, ça peut être utile pour détecter une sauvegarde qui ne s’est pas effectuée
• nocreate : on ne recréé pas le fichier d’origine (/backups/mysql/all-databases.sql.gz dans mon exemple)
• noolddir : on ne déplace pas les versions dans un autre dossier
• nomail : ne pas envoyer les nouvelles versions par mail (ça risque de faire de gros messages sinon)
• extension .sql.gz : permet de conserver l’extension du fichier à la fin du nom (par défaut fichier.toto devient fichier.toto-YYYYMMJJ)

Vous pouvez (devez ?) les adapter en fonctions de vos besoins, il existe plusieurs autres paramètres, je ne vais pas les lister ici, le man est suffisamment explicite.

Certains paramètres peuvent être utiles comme « compress » (qui permet de compresser les versions), ou « prerotate » et « postrotate » (qui permettent de lancer des commandes avant et après la rotation).

Ils peuvent aussi être gênants, voir dangereux si ils sont mal utilisés. Le paramètre « compress » par exemple, si on demande à logrotate de compresser une sauvegarde de plusieurs centaines de Go, le processus de rotation va prendre un temps certain (cela va décaler la rotation des logs suivants de plusieurs minutes, voir de plusieurs heures si vos disques ne suivent pas).

Rotations plus rapides

Plus haut j’ai indiqué que logrotate travaillait au mieux une fois par jour. Ce comportement est simplement du au fait qu’il est lancé par une tâche cron de type @daily, donc qui s’exécute une fois par jour.

La commande logrotate peut aussi être appelée directement :

• dans une tâche cron planifiée toutes les n minutes
• dans une tâche incron qui détecte la création de votre nouvelle sauvegarde
• directement dans le script de sauvegarde
• …

Il suffit de définir vos paramètres de rotation dans un fichier de configuration séparé et d’appeler ce fichier en paramètre de logrotate. Par exemple :

logrotate /usr/local/etc/rotationsauvegardes.conf

Le plus important pour la fin

Tester ses sauvegardes

Une sauvegarde qu’on ne peut pas restaurer n’est pas une sauvegarde => testez régulièrement vos sauvegardes.

Voici quelques exemples :

• base de données : le plus simple reste de restaurer le dump sur un autre serveur puis de comparer les données
• archive générique : une extraction partielle (ou complète) sur un autre support et une comparaison des données (diff est très bien pour ça) permet de faire le test
• archive tar ou dar : les 2 commandes disposent d’options permettant de tester l’intégrité d’une archive

Exporter ses sauvegardes

Une sauvegarde qui reste au même endroit que sa source (même machine, ou pire, même disque) n’est pas fiable. Si votre serveur est effacé (accident, malveillance, …), vos sauvegardes le seront aussi.

A titre d’illustration, au travail nous procédons comme suit :

1. sauvegardes locales : la plupart des serveurs font eux mêmes leurs sauvegardes, qu’ils stockent en local (pratique pour faire une restauration rapide en cas de perte de données)
2. copie distante : certains serveurs copient la dernière sauvegarde sur un autre serveur (situé dans une autre salle machine, ce serveur est aussi sauvegardé à l’étape suivante)
3. sauvegarde distante : tous les serveurs importants sont aussi sauvegardés par un système autonome constitué de plusieurs répliques (situées dans des salles machines différentes)
4. sauvegardes critiques : en complément, les données les plus critiques sont aussi copiées hors site et hors ligne (la bonne vieille méthode des bandes/dat/… que l’on met au coffre)

Donc toutes nos données importantes existent au moins en 3 exemplaires (active, sauvegarde locale et sauvegarde distante), certaines de nos données se retrouvent en 6 exemplaires (3+copie distante, sauvegarde de la copie distante et coffre), sans compter les différentes versions !

Pour une utilisation plus « raisonnable », vous pouvez, dans la plupart des cas, vous contenter de faire régulièrement des sauvegardes distantes de vos sauvegardes locales.

A titre personnel, j’utilise beaucoup rsync pour ça, mais un simple serveur ftp peut faire le travail.

Conclusion

Il existe bien sur plein d’autres manières de faire. Vous devriez par exemple faire vos sauvegardes sur un autre système (mount, rsync, ssh, … le permettent très facilement). Au lieu de faire des sauvegardes complètes, l’utilisation de l’incrémental (à utiliser avec précaution si on fait des rotations) ou du différentiel (idem) peut s’avérer plus efficace (moins consommateur en espace disque et généralement plus rapide).

De même vous pouvez utiliser des outils dédiés (bacula, TimeNavigator, Back In Time, …) qui vont souvent bien plus loin mais qui sont aussi souvent assez complexe à utiliser (pour ne pas dire indigeste, ex : TimeNavigator).

Faire des sauvegardes n’a rien de compliqué et ne nécessite pas nécessairement l’utilisation d’outils complexes.

Les systèmes Unix, Linux en particulier, sont suffisamment souples pour permettre toutes sortes d’automatisations alors il ne fait pas s’en privé.