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.

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 sophistiqué pour les données qui changent régulièrement. Dans ce cas, l'idéal est une sauvegarde gross-modo permanente avec 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 :

#! /bin/sh

# inclusion de la librairie de backup
BASE_PATH=$(dirname $(readlink -nf $0))
. $BASE_PATH/backup_library.sh

# démarrage d'une session de sauvegarde
use_storage /backup/current

# rotation du dossier de stockage
rotate_storage

# on rentre dans un bloc "machine" qui va vérifier si elle est "vivante" et
si oui, commencer la sauvegarde
process_host 'machine_distante' && {
  # sauvegarde de la configuration /etc en utilisant les exclusions "etc"
  synchronize /etc  etc

  # arrête du serveur IMAP et sauvegarde de tous le courriers, puis
  # redémarrage du serveur
  services stop cyrus-imapd
  synchronize /mails
  services start
}

# libère l'espace de backup
release_storage

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. Ensuite nous utilisons la fonction rotate_storage qui va opérer une rotation des dossiers qui se trouve dans cet espace de stockage. C'est la base de notre historisation.

Maintenant que l'espace de stockage est préparé, nous utilisons la commande process_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

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. :

# Affiche une trace
function trace {
  if [ $TERM == "dumb" ] ; then
    logger $*
  else
    echo $*
  fi
}

# verrouillage de la session. Si une précédente session est en train de tourner, on quitte.
function use_storage {
  export storage_path=$1
  mkdir -p $storage_path
  while [ -f $storage_path/lock ] ; do
    trace "'$storage_path' is locked !! waiting..."
    sleep 5
  done
  > $storage_path/lock
}


# déverrouillage de la session
function release_storage {
  trace "releasing storage $storage_path"
  rm -rf $storage_path/lock
}  

backup_librarie.sh

On introduit au passage la fonction trace qui comme son nom l'indique est là pour faire causer notre script. La petite magouille avec $TERM est juste là pour différencier si le script est lancé par CRON ou à la main. Dans le premier cas, on préfère alors causer dans syslog.

Historisation

Le principe de base de cette fonction est repris de cet article. Je ne reviens donc pas dessus. Cependant la manière d'utiliser ic 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. Le nombre de dossier que l'on souhaite conserver est indiqué par la variable BACKUP_ROTATION_MAX_FOLDERS.

Si vous lancez le script de sauvegarde toutes les 15 minutes et que vous avez spécifié 100 comme valeur, vous disposez donc de la possibilité de remonter en arrière dans le temps de 50 heures par tranches de 15 minutes. A vous de régler cette valeur et la periode de rotation à votre convenance (par exemple 200 dossiers, toutes les heures). Personnellement j'ai opté pour une rotation par heure et une semaine d'historisation, soit donc 24*7=168 dossiers.

export BACKUP_ROTATION_MAX_FOLDERS=168

# opère une rotation des dossiers historisés
function rotate_storage {
  trace "Backup Storage Rotation for $storage_path"

  # transfert de l'ancien "current" dans "history"
  currentDate=$(stat $storage_path -c "%Z")
  currentDate=$(date -d "1970-01-01 ${currentDate}sec GMT" +"%y-%m-%d_%H-%M-%S")
  history_path=$storage_path/../history
  mkdir -p $history_path
  cp -al "$storage_path/." $history_path/$currentDate
  cd $history_path

  # réduction du nombre de dossier au nombre maximum définit par défaut
  local iFolder=0
  local folder
  {
    local folder
    find . -maxdepth 1 -type d| grep "./" | while read folder; do
      stat $folder -c "%Z %n"
    done | sort -rn -k1 -t' ' | awk '{print $2}'
  } |    
  while read folder ; do
    if [ $iFolder -gt $BACKUP_ROTATION_MAX_FOLDERS ] ; then
      trace "Deleting too old history folder : $folder"
      rm -rf "$folder"
    fi
    let iFolder=$iFolder+1
  done
  cd  ..


  # finalisation
  touch $history_path
}

backup_library.sh

Notez bien que le gros avantage de la méthode hardlink est que les fichiers identiques prennent la même place sur le disque que vous ayez une profondeur temporelle de 1 ou de 10000. Après cela, en cas de problème, il vous suffit d'aller dans le dossier history pour chercher une date avant l'incident et ainsi récupérer vos données.

Notre espace réel de stockage après rotation est donc le dossier current.

Lancement du backup sur les machines vivantes

Notre script doit pouvoir gérer non seulement les sauvegardes locales mais aussi, et surtout, les machines distantes de notre réseau domestique. Pour cela faut il encore détecter que la machine en question est en route, ou pas. C'est l'objectif de la fonction process_host qui renvoie un code d'erreur si la machine ne répond pas au PING. Dans le cas contraire, elle va créer dans notre stockage un sous-espace portant le nom de la machine distante.

  # vérifie que la machine cible est allumée et initialize la sauvegarde
function process_host {
  export host_name=$1;

  # on vérifie que le host est bien UP
  ping -c 1 $1 > /dev/null 2>&1
  if [ $? -ne 0 ] ; then
    # le host est down, rien à faire de plus
    trace "'${host_name}' is DOWN, leaving..."
    return 1
  fi

  # on sauve le chemin vers le stockage global et on l'affine pour notre host
  export host_storage_path=$storage_path/${host_name}
  mkdir -p $host_storage_path
  trace "Processing '${host_name}' => $host_storage_path"
  return 0
}

backup_library.sh

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 :

export SETTINGS=/etc/backup
export RSYNC_TEMP=/tmp

  # fonction utilitaire générale de synchronisation utilisé pour les dossiers distants et locaux
function _synchronize {
  local profile=""
  if [ $# -gt 2 ] ; then
     local profileFile=$SETTINGS/$3.exclusions
    if [ ! -f "$profileFile" ] ; then
      trace "Unable to load profile '$profileFile'"
      return 1
    else
      profile=--exclude-from=$profileFile
    fi
  fi
  mkdir -p "${host_storage_path}$2"
  trace "Starting synchronization [$host_name] $1 -> ${host_storage_path}$2"
  rsync \
    -azv \
    --temp-dir=$RSYNC_TEMP \
    --delete --delete-excluded \
      $profile \
      "$1/" \
      "${host_storage_path}${2}" |
      # simple formatage de la sortie de rsync
      {
        grep -Pv "(receiving|speedup|received)" | sed -e '/^[ ]*$/d'| \
        while read line ; do
          trace [$host_name] $line
        done
      }
}

backup_library.sh

Notre fonction est en deux morceaux car nous allons la réutiliser pour une autre fonction un peu plus loin. La syntaxe en elle-même est assez simple, il suffit de lui passer en paramétre le dossier distant à synchroniser, éventuellement suivi du nom d'un profil d'exclusion.

Le profil d'exclusion n'est rien d'autre qu'un fichier stocké dans /etc/backup et qui cintient une liste de motifs de nom de fichiers à exclure de la sauvegarde. Un profile homes fait ainsi référence au fichier /etc/backup/homes.exclusions qui peut ressembler à cela :

core.*
.mplayer/DVDKeys/
firefox/*.default/extensions/
firefox/*.default/chrome/
.wine*/
.Trash-*/
.cddb/
.icons/
.xsession-errors
tmp/
workspace/
Desktop/
Cache/
icons/

/etc/backup/homes.exclusions

Pour plus d'informations sur les exclusions, reportez-vous au manuel de la commande rsync et du paramétre --exclude-from. Maintenant pour notre fonction de synchronisation dans le le script, nous procédons comme suit :

synchronize /home homes

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é". Cela nous donne la fonction suivante :

# synchronisation d'un resource Windows.
function win_synchronize {
  mount_point=/mnt/${host_name}_$1
  mkdir -p $mount_point
  mount -t cifs "//$host_name/$1" $mount_point -o credentials=$SETTINGS/credentials_${host_name}_${1},ro,iocharset=utf8 && {
    synchronize "${mount_point}/$2/" "$2" windows
    umount ${mount_point}
  }
}

backup_library.sh

Pour que cette fonction soit utilisable il faut définit dans le dossier /etc/backup un fichier contenant le login et le mot de passe à utiliser par mount.cifs pour se connecter à la ressource. Le nom de ce fichier est composé du nom de la machine et du nom de la resource, par exemple pour la machine gaston et la ressource C, nous donnent le fichier /etc/backup/credential_gaston_C ayant comme contenu :

username=gaston
password=secret

credential_gaston_C

Ensuite la fonction s'utilise très simplement dans notre script de sauvegarde :

win_synchronize C '/Users/Gadton/Documents'

On peut ici aussi rajouter un paramétre avec un profile d'exclusion.

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 :

# Arrêt et démarrage de services distants
function services
{
  local port="22"
  local command=$1
  shift
  if [ $command == "stop" ] ; then
    services="$*"
  fi
  ssh -x $host_name "\
     for service in $services ; do \
       /etc/init.d/\$service $command ; \
     done" |  {
        sed -e '/^[ ]*$/d'| \
        while read line ; do
          trace [$host_name] $line
        done
     }
}

backup_library.sh

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

# arrête le service cyrus-imapd
services stop cyrus-imapd

# copie des données
synchronize /mails

# redémarrage des dernières services qui ont été arrêtés
services start

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.

Pour faire cette sauvegarde diablement efficace nous allons en réalité écrire deux scripts. Le premier va être lancé toutes les heures et va juste effectuer la rotation des dossiers d'historisation. Du coup, on obtient une historisation par heure tout en ayant un contenu à jour au quart d'heure prés. En d'autre termes les données sont écrasées 4 fois avant d'être historisées.

Outre une plus grande sécurité, cette approche nous permet de détecter rapidement les machines qui viennent de se connecter sur le réseau, typiquement les portables en WIFI, et ainsi ne pas attendre 1h avant de leur sauver leurs données.

Commençons donc par le script chargé de la rotation :

#! /bin/sh

BASE_PATH=$(dirname $(readlink -nf $0))
. $BASE_PATH/lib/backup.sh

# démarrage d'une session de sauvegarde
use_storage /backups/current

# rotation du dossier de stockage
rotate_storage

# libère l'espace de backup
release_storage

backup-live-rotate.sh

Rendez ce script exécutable et testez le, cela va au passage créer l'espace de stockage initial.

Ajoutons maintenant celui de la sauvegarde à proprement parler :

#! /bin/sh

BASE_PATH=$(dirname $(readlink -nf $0))
. $BASE_PATH/lib/backup.sh

# démarrage d'une session de sauvegarde
use_storage /backups/current

process_host 'machine_de_travail' && {
  synchronize /etc  etc
  synchronize /home homes
}

process_host 'machine_windows' && {
  win_synchronize C '/Users/Gadton/Documents' windows
}

# libère l'espace de backup
release_storage

backup-live.sh

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 nos deux scripts. Je pars ici du principe que ces scripts, comme backup.cron, ont été rendus exécutables par un chmod +x .. et qu'il sont tout deux, avec la librairie, dans le dossier /usr/bin :

#!/bin/bash
# /etc/cron.d/backup: crontab fragment for backup

# Live backup every 15 minutes
01   * * * *  root /usr/bin/backup-live.sh

# Rotation of live context every hours
*/15 * * * * root /usr/bin/backup-live-rotate.sh

/etc/cron.d/backup.cron

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.

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.

#! /bin/sh

BASE_PATH=$(dirname $(readlink -nf $0))
. $BASE_PATH/lib/backup.sh

# montage du disque de sauvegarde en lecture-écriture
mkdir -p /mnt/backup
options="rw"
if mount|grep /mnt/backup > /dev/null ; then
  options="remount,$options"
fi
mount /dev/disk/by-label/backup /mnt/backup -o $options

# démarrage d'une session de sauvegarde
use_storage /mnt/backup/mirroring

# backup du serveur
process_host 'serveur' && {
  # copie des bases de données
  services stop cyrus-imapd postgresql ldap
  synchronize /storage/databases/
  services start

  # copie des données lourdes
  synchronize /mes_videos
  synchronize /mes_photos

  # copie de nos historisations
  syncronize /backups
}

# libère l'espace de backup
release_storage

# on remonte le disque en lecture seule
mount /dev/disk/by-label/backup /mnt/backup -o remount,ro

backup-daily.sh

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 :

02   4 * * *  root /usr/bin/backup-daily.sh

Et voilà pour notre sauvegarde journalière.

Conclusion

En tout et pour tout, notre librairie fait 150 ligne de code Bash et répond à des besoins simples mais préçis de sauvegarde. Les scripts 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...