Client linux

Voyons à présent comment sauvegarder et relire nos données situées sur un client Linux.

Sauvegarde

Supposons pour l’exemple que l’on désire sauvegarder notre répertoire /home vers le serveur. On aura pris soin auparavant de copier sur notre client la clé SSH privée générée sur le serveur. On créera alors un script du type :

btrbackup_client1.sh :

#!/bin/bash
rsync -e "ssh -l client1 -p 222 -i /chemin/vers/client1_sshkey" -a --no-specials --numeric-ids --inplace --delete --delete-excluded -v --stats \
--exclude "/home/*/.local/share/Trash/files/**" \
--exclude "/home/*/.thumbnails/**" \
--exclude "/home/*/.mozilla/firefox/*/Cache/**" \
/home server::backup

if [ $? -eq 0 ]; then
 rsync -e "ssh -l client1 -p 222 -i /chemin/vers/client1_sshkey" server::backup/bogus /tmp >/dev/null 2>&1
fi

La commande rsync est un peu modifiée par rapport à la syntaxe de base que nous avons vue. Les options suivantes ont été ajoutées :
--numeric-ids : par défaut rsync tente de faire correspondre les utilisateurs de la machine cliente à ceux de la machine serveur, même s’ils ont des id différents sur chacune. Cela peut être utile si les fichiers peuvent être accédés localement sur le serveur par leurs propriétaires légitimes. Ce ne sera pas le cas ici. De plus, le serveur ne peut pas effectuer cette correspondance s’il est configuré en chroot, à moins d’avoir une copie des fichiers /etc/passwd et /etc/group dans son répertoire, ce qui peut être lourd à maintenir. rsync se contente alors de copier les identifiants numériques, sans se soucier de la correspondance avec les noms des utilisateurs. Avec notre serveur en chroot, l’option --numeric-ids qui force ce comportement est donc implicite mais ça ne coûte rien de la spécifier pour mémoire.
--no-specials : désactive le --specials impliqué par -a (les sockets et fifos n’ont pas d’intérêt et seront recréés par les programmes qui les utilisent).

On voit que le script teste le code retour de rsync, et que si celui-ci est OK (ie égal à 0) il lance un nouveau rsync – cette fois-ci en lecture, avec des arguments bidons – ce qui a pour effet de déclencher le snapshot sur le serveur. Comme ce dernier rsync renvoie forcément une erreur (c’est conçu pour), on redirige sa sortie vers /dev/null pour ne pas se faire peur…

Testez ce script à la main dans un terminal au moins une fois pour enregistrer la clé SSH du serveur et corriger les inévitables éventuelles erreurs, puis placez-le dans la crontab de votre client pour qu’il soit exécuté régulièrement.

Restauration

Le serveur est configuré pour que le client puisse accéder à ses sauvegardes via le protocole SFTP sur le port 223, au moyen du même identifiant et de la même clé que ceux utilisés pour effectuer les sauvegardes. On pourrait donc restaurer nos données grâce à un programme comme FileZilla en mode graphique, ou même directement en ligne de commande ainsi :

sftp -P 223 -i /chemin/vers/client1_sshkey client1@server

Nous avons néanmoins opté pour une solution qui rend la relecture des sauvegardes encore plus aisée : SSHFS. Techniquement, il s’agit d’un système de fichiers de type FUSE (Filesystem in User Space) implémenté au-dessus du protocole SFTP. En clair, il permet d’accéder aux données situées sur un serveur SFTP comme s’il s’agissait de données locales.

Une fois SSHFS installé sur votre système, ajoutez la ligne suivante dans le fichier /etc/fstab de votre client :

sshfs#client1@server:/  /restore/client1  fuse  delay_connect,reconnect,allow_other,port=223,IdentityFile=/chemin/vers/client1_sshkey  0 0

Puis créez le point de montage et montez ce nouveau système de fichiers :

mkdir -p /restore/client1
mount /restore/client1

Vous pouvez maintenant parcourir vos sauvegardes en vous rendant dans le répertoire /restore/client1, aussi bien en ligne de commande qu’avec votre gestionnaire de fichiers préféré. Restaurer un fichier est désormais aussi simple qu’un glisser/déposer vers son emplacement d’origine.

Visualisation des sauvegardes avec Nautilus