Si vous administrez des serveurs Linux vous vous êtes déjà probablement interrogé sur la meilleure façon de sauvegarder vos systèmes et données. La télé-sauvegarde est une option particulièrement intéressante. Bien que Rsync paraîsse naturellement le dispositif le mieux adapté à cette tâche une autre solution existe : Rdiff-backup.
Moins connu, ce dernier présente de nombreux avantages : une gestion optimisée des incréments, la création d’un miroir de fichiers ou de répertoires, la gestion automatisée de l’effacement des anciens incréments, la compression des données transférées … Rdiff-Backup est utilisable en “local” mais également dans le cadre d’un système de télé-sauvegarde. Dans ce cas les échanges sont cryptés en utilisant (de manière transparente) le protocole SSH.
L’objectif de ce how-to est de présenter une méthode permettant de réaliser une sauvegarde à distance, sécurisée, automatisée, sans aucune intervention de la part de l’administrateur (les procédures d’authentification reposant sur un système de clés asymétriques).
La distribution utilisée pour la création de ce how-to est une “Ubuntu 10.04 LTS server“, mais il ne devrait pas y avoir beaucoup de différences si vous utilisez un autre Linux. Un serveur SSH doit également être présent sur les 2 machines.
Dernière précision : afin de simplifier cette procédure j’utilise volontairement l’utilisateur “root” pour réaliser la sauvegarde. Pour optimiser la sécurité, les “puristes” pourront bien entendu adapter cette méthode avec un autre compte utilisateur …
Dans le cadre de ce tutoriel nous allons utiliser deux serveurs :
- “srv-prod “: qui correspond au serveur “à sauvegarder” (IP dans ce how-to : 192.168.0.157)
- “srv-backup” : qui correspond au serveur destiné à héberger la sauvegarde de srv-prod
On procède tout d’abord à l’installation de “Rdiff-Backup” en lançant (sur les 2 serveurs) la commande
apt-get install rdiff-backup
On va ensuite générer les clés SSH nécessaires à l’authentification de “srv-backup” auprès de “srv-prod”. Créez (si ce n’est pas déjà fait) sur “srv-backup” un répertoire nommé “/root/.ssh/“. On lance ensuite (sur ce même serveur) la commande suivante :
ssh-keygen -t rsa -b 4096
Répondez de la manière suivante aux questions posées par l’application :
Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/rdiff_id_rsa
Ne rien mentionner en réponse à la question “Enter passphrase (empty for no passphrase):”. Idem pour “Enter same passphrase again:“
Suite à cette opération, vous trouverez 2 fichiers au sein du répertoire “/root/.ssh” :
- rdiff_id_rsa : qui correspond à votre clé privée
- rdiff_id_rsa.pub : votre clé publique (qui devra, par la suite, être positionnée sur le serveur de production …
Pour ce faire il est nécessaire d’éditer le fichier “rdiff_id_rsa.pub” (avec un petit “cat /root/.ssh/rdiff_id_rsa.pub” par exemple). Vous devriez obtenir une chaîne de la forme :
Bien entendu le contenu de votre fichier sera différent car il s’agit de clés générées aléatoirement (heureusement … )
Copiez ensuite cette chaîne de caractères afin de pouvoir la coller dans le fichier “/root/.ssh/authorized_keys2” du serveur de production (“srv-prod”). Dans l’hypothèse où ce répertoire (“.ssh”) et ce fichier (“authorized_keys2″) n’existent pas il sera nécessaire de les créer manuellement. Attention aux droits à appliquer sur le fichier “authorized_keys2” qui doivent être positionnés à 644 (“chmod 644 /root/.ssh/authorized_keys2“). Il faut également s’assurer de copier la chaîne de caractères tel-quel sans y ajouter aucun caractère n’y retour chariot.
Une fois la clé copiée, il est nécessaire d’y ajouter (sur “srv-prod“) certaines options comme illustré dans l’exemple ci-dessous :
Les directives à placer devant la clé sont les suivantes (il ne vous reste plus qu’à copier / coller …) : “command=”rdiff-backup –server –restrict-read-only /”,no-port-forwarding,no-X11-forwarding,no-pty “. Il s’agit de mesures de sécurités complémentaires. En effet le serveur de backup s’authentifiant de manière automatisée, il est intéressant de limiter les opérations réalisables avec ce compte (pas de terminal, opération en lecture seule uniquement, pas de forward de ports …).
Sur le serveur “srv-backup” créez le fichier “/root/.ssh/config“. Ce dernier va intégrer les éléments nécessaires à la connexion automatique au serveur de production. Le contenu de ce fichier est le suivant :
host 192.168.0.157
hostname 192.168.0.157
user root
identityfile /root/.ssh/rdiff_id_rsa
compression yes
protocol 2
Bien entendu vous devez remplacer l’IP (192.168.0.157) par l’adresse de votre serveur de prod (ou bien par son nom pleinement qualifié). Vous pouvez également modifier le paramètre “compression” en le passant à “no” si vous ne souhaitez pas compresser les données échangées entre les deux serveurs.
Créez ensuite, sur “srv-backup” un répertoire au sein duquel seront stockées les données sauvegardées. Par exemple “mkdir /backup“
Il ne reste plus qu’à essayer de générer une sauvegarde d’un des répertoires du serveur de production (“/etc” par exemple) en utilisant une commande du style :
rdiff-backup -v 5 [email protected]::/etc /backup/etc
Vous allez voir apparaître un message du type :
The authenticity of host ’192.168.0.157 (192.168.0.157)’ can’t be established.
RSA key fingerprint is 60:6b:12:0a:6f:bf:98:da:83:5c:43:16:f2:72:3c:29.
Are you sure you want to continue connecting (yes/no)?
répondez “yes” (cette question ne sera plus posée par la suite). Vous devriez voir la sauvegarde se réaliser. Un petit contrôle du répertoire “/backup/etc” confirme la présence des fichiers.
Vous pouvez automatiser (via le crontab) cette tâche de sauvegarde en vous inspirant, après adaptation, de ce script (merci à @ledeuns pour sa contribution ) :
#!/bin/bash</p> RETCODE="" ### Sauvegarde ### /usr/bin/rdiff-backup [email protected]::/var /backup/var if [ $? -ne 0 ]; then RETCODE="VAR;"; fi /usr/bin/rdiff-backup [email protected]::/etc /backup/etc if [ $? -ne 0 ]; then RETCODE="ETC;$RETCODE"; fi /usr/bin/rdiff-backup [email protected]::/home /backup/home if [ $? -ne 0 ]; then RETCODE="HOME;$RETCODE"; fi /usr/bin/rdiff-backup [email protected]::/root /backup/root if [ $? -ne 0 ]; then RETCODE="ROOT;$RETCODE"; fi /usr/bin/rdiff-backup [email protected]::/usr /backup/usr if [ $? -ne 0 ]; then RETCODE="USR;$RETCODE"; fi ### Effacement des increments datant de plus de 2 semaines (2W) ### /usr/bin/rdiff-backup --force --remove-older-than 2W /backup/var/ if [ $? -ne 0 ]; then RETCODE="DELVAR;$RETCODE"; fi /usr/bin/rdiff-backup --force --remove-older-than 2W /backup/etc/ if [ $? -ne 0 ]; then RETCODE="DELETC;$RETCODE"; fi /usr/bin/rdiff-backup --force --remove-older-than 2W /backup/home/ if [ $? -ne 0 ]; then RETCODE="DELHOME;$RETCODE"; fi /usr/bin/rdiff-backup --force --remove-older-than 2W /backup/root/ if [ $? -ne 0 ]; then RETCODE="DELROOT;$RETCODE"; fi /usr/bin/rdiff-backup --force --remove-older-than 2W /backup/usr/ if [ $? -ne 0 ]; then RETCODE="DELUSR;$RETCODE"; fi ### Envoi du rapport par mail ### if [ -z $RETCODE ]; then echo "" | mail -s "Sauvegarde effectuee" [email protected] else echo "$RETCODE" | mail -s "Sauvegarde en erreur" [email protected] fi
Ce how-to n’ayant pas vocation à décrire d’une manière exhaustive le fonctionnement de Rdiff-Backup, je vous invite à consulter le manuel détaillé disponible à cette adresse (vous pourrez y découvrir l’ensemble des commandes et options disponibles) !
- Le site officiel est disponible ICI