www.lalitte.com - Réseau |
|
|
Mise en place d'une solution de sauvegarde incrémentale sécurisée
Pour commencer, il est bon à mon avis de donner une petite explication de ce que je peux entendre par "sauvegarde incrémentale" Il s'agit d'une sauvegarde qui se déroule tous les x temps (tous les jours par exemple) mais qui ne copie pas l'ensemble d'un disque ou répertoire, mais seulement les modifications et fichiers effacés. Ainsi, si vous voulez sauvegarder un disque de 30Go de données, sur lequel chaque jour des gens travaillent, il vous faudra le premier jour rappatrier l'ensemble des 30Go du disque, puis seules les modifications journalières seront copiées, nécessitant ainsi très peu de temps lors des transferts, plutôt que le temps de copier 30Go à chaque fois :-) Il sera aussi très facile de retrouver les dossiers ou fichiers perdus par quelqu'un. Sommaire:1- Pourquoi ce document ? 2- Comment ça marche ? 3- L'installation de rsync 4- Mise à jour d'une synchronisation 5- Synchronisation à distance 6- Mise en place de la sauvegarde incrémentale 7- Sécurisation de la solution 8- Industrialisation de la solution 1- Pourquoi ce document ?Il existe une foultitude de documentations sur Internet sur l'application rsync utilisée pour les sauvegardes, mais aucune d'entre elles ne couvre à la fois la mise en place d'une solution de sauvegarde par rsync, et la sécurisation de celle-ci. On trouve des bribes d'information, certains sites très bien faits, mais je n'ai pas trouvé de site regroupant tout cela. Je me suis donc dis que ça vaudrait le coup d'essayer d'en faire un :-) 2- Comment ça marche ?Nous n'allons pas entrer dans les détails du fonctionnement de rsync, les personnes souhaitant plus d'information dur l'algorithme utilisé pourront les trouver sur le site officiel de rsync. Rsync est donc un outil qui permet de faire l'image d'une arborescence disque. Par exemple, si vous avez un répertoire /home/toto sur votre disque qui contient vos informations, vous pouvez en faire une parfaite copie, soit sur la même machine, soit sur une machine distante. Vous pourrez ainsi "synchroniser" les deux à l'aide de rsync (c'est très utile pour un site web que vous développez chez vous par exemple et que vous voulez mettre à jour facilement) De plus, rsync est capable de voir quels sont les fichiers ou répertoires qui ont été modifiés, et de ne copier que les modifications ! C'est là où il prend tout son intérêt. Fini les sauvegardes interminables qui occupent tout le réseau :-) Nous allons voir comment mettre en place une solution globale, permettant de faire chaque jour une sauvegarde incrémentale d'une partie de l'arborescence d'un disque, tout en sécurisant les transactions (vous ne voulez pas que tout le monde puisse voir le contenu de votre disque, hein ?) 3- L'installation de rsyncL'installation est des plus simple, du moins dans la configuration que je vous présente. Il faut d'abord télécharger les source les plus récentes (par exemple ici) Placez ensuite ces sources dans votre répertoire préféré et décompressez-les. # tar xvzf rsync-2.6.3.tar.gz Allez dans le répertoire créé. # cd rsync-2.6.3 Il ne vous reste plus qu'à compiler. # ./configure # make # make install Et hop, voilà rsync installé. Le binaire se trouve normalement dans /usr/local/bin/, si ce répertoire est dans votre PATH, il vous suffira de taper rsync pour l'executer, sinon vous pouvez soit ajouter /usr/local/bin à votre PATH # PATH=$PATH:/usr/local/bin soit entrer à chaque fois la commande précédée de /usr/local/bin/ Pour tester le bon fonctionnement de rsync, vous pouvez taper rsync, vous devriez avoir une jolie page d'aide qui commence ainsi: rsync version 2.5.6cvs protocol version 26 Copyright (C) 1996-2002 by Andrew Tridgell and others http://rsync.samba.org/ Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, IPv6, 64-bit system inums, 64-bit internal inums Si ce n'est pas le cas... il ne vous reste plus qu'à débugger :-( 4- Synchroniser un répertoire en localMaintenant que rsync est installé, nous allons pouvoir tester son fonctionnement. Pour cela, nous allons créer un répertoire "original" que nous allons essayer de copier dans le répertoire "copie" # mkdir /original # mkdir /copie # touch /original/toto Nous pouvons voir que le contenu de /copie est vide # ls -la /copie total 8.0k drwxr-xr-x 2 root root 4.0k Dec 13 10:00 ./ drwxr-xr-x 22 root root 4.0k Dec 13 10:00 ../ Nous allons maintenant synchroniser le contenu de "copie" sur le répertoire "original". # rsync -r /original /copie # ls -la /copie total 12k drwxr-xr-x 3 root root 4.0k Dec 13 10:06 ./ drwxr-xr-x 22 root root 4.0k Dec 13 10:00 ../ drwxr-xr-x 2 root root 4.0k Dec 13 10:06 original/ # ls -la /copie/original total 8.0k drwxr-xr-x 2 root root 4.0k Dec 13 10:06 ./ drwxr-xr-x 3 root root 4.0k Dec 13 10:06 ../ -rw-r--r-- 1 root root 0 Dec 13 10:06 toto Nous voyons que le répertoire "original" ainsi que son contenu ont été copiés. L'intérêt de cette manipulation est limité, sauf si vous possédez plusieurs disques durs et que vous voulez faire une copie de vos répertoires importants. En cas de crash d'un disque vous aurez toujours vos données sur l'autre. Pour ceux qui connaissent, c'est un peu le RAID du pauvre :-) 4- Mise à jour d'une synchronisationNous allons maintenant modifier notre fichier toto, ajouter un fichier tata et voir le résultat de la commande précédente. Nous allons aussi ajouter des options à la commande rsync pour avoir plus d'informations sur ce qui est fait. # touch /original/tata # echo test >> /original/toto # ls -la /original total 12k drwxr-xr-x 2 root root 4.0k Dec 13 10:46 ./ drwxr-xr-x 22 root root 4.0k Dec 13 10:46 ../ -rw-r--r-- 1 root root 0 Dec 13 10:46 tata -rw-r--r-- 1 root root 5 Dec 13 10:47 toto # rsync -rv /original /copie building file list ... done original/tata original/toto wrote 154 bytes read 52 bytes 412.00 bytes/sec total size is 5 speedup is 0.02 # ls -la /copie/original total 12k drwxr-xr-x 2 root root 4.0k Dec 13 10:50 ./ drwxr-xr-x 3 root root 4.0k Dec 13 10:06 ../ -rw-r--r-- 1 root root 0 Dec 13 10:50 tata -rw-r--r-- 1 root root 5 Dec 13 10:50 toto Apparemment, les fichiers tata et toto ont bien été copiés. Effectuons maintenant un ajout dans toto. # echo encore >> /original/toto # rsync -rv /original /copie # cat /copie/original/toto test encore Là encore les modifications ont bien été prises en compte. Supprimons maintenant le fichier tata et effectuons la synchronisation. # rm /original/tata # rsync -rv /original /copie # ls -la /copie/original total 12k drwxr-xr-x 2 root root 4.0k Dec 13 10:58 ./ drwxr-xr-x 3 root root 4.0k Dec 13 10:06 ../ -rw-r--r-- 1 root root 0 Dec 13 10:56 tata -rw-r--r-- 1 root root 12 Dec 13 10:58 toto Cette fois, le résultat est moins attendu, le fichier tata est toujours là ! Ce comportement est cependant le fonctionnement normal de rsync qui tente de préserver vos fichiers en cas d'erreur. Ainsi, vos fichiers ne seront jamais effacés si vous ne le spécifiez pas dans la commande par l'option --delete # rsync -rv --delete /original /copie # ls -la /copie/original total 12k drwxr-xr-x 2 root root 4.0k Dec 13 10:58 ./ drwxr-xr-x 3 root root 4.0k Dec 13 10:06 ../ -rw-r--r-- 1 root root 12 Dec 13 10:58 toto Cette fois-ci, le fichier a bien été effacé. Dans le mode de fonctionnement tel que nous l'utilisons ici, cela a peu d'intérêt d'effacer nos fichiers, et cela n'est pas négligeable de les garder en cas de mauvaise manipulation. Mais nous verrons par la suite que rsync permet de faire de conserver les modifications dans un répertoire séparé du miroir complet. Dans ce cas, l'utilisation de --delete sera intéressante car nous conserverons quand même une copie des fichiers effacés, et aurons un miroir identique au répertoire réel. 5- Synchronisation à distanceNous allons maintenant voir comment nous synchroniser avec un disque distant. Le fonctionnement est un peu plus complexe, mais reste très simple. L'application rsync fonctionne en client/serveur, c'est à dire qu'une des machine est en attente de connexions, et l'autre peut venir s'y connecter quand elle le désire. Il va donc nous falloir configurer l'application rsync qui doit écouter sur une des machines, et lancer notre commande rsync depuis l'autre. Pour que rsync soit en écoute sur une machine, il suffit de lui spécifier l'option --daemon. Nous allons donc faire nos tests sur une machine nommée serveur qui contient le répertoire à sauvegarder. Il faudra installer rsync dessus, comme précédemment. root@serveur # rsync --daemon root@serveur # netstat -anp | grep rsync tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 16534/rsync Nous voyons bien sur notre machine que rsync est maintenant en écoute sur le port 873. Nous allons créer sur cette machine le répertoire à synchroniser. root@serveur # mkdir /original root@serveur # touch /original/toto Il nous faut maintenant configurer rsync sur le serveur pour lui dire quels sont les répertoires qui peuvent être synchronisés, et de quelle façon le faire. Ceci se fait à travers le fichier de configuration de rsync qui est /etc/rsyncd.conf. Nous allons créer un nouveau fichier ou écraser l'existant. root@serveur # vi /etc/rsyncd.conf # Fichier de configuration de rsync uid = root gid = root log file = /var/log/rsyncd.log [original] path = /original comment = Le répertoire à copier list = yes read only = yes Tout d'abord, nous spécifions l'utilisateur et le groupe qui vont lancer le service. Dans notre cas, j'ai mis root.root, mais ce n'est pas une bonne façon de procéder. Cela dépend essentiellement des droits positionnés sur les fichiers et répertoires que vous aurez à copier. Il faudra que les droits du processus soient au moins aussi élevés. Dans le cadre de nos tests, je ne m'embarasse pas :-) Nous verrons par ailleurs par la suite que les connexions ne se feront plus directement sur le démon rsync, mais sur SSH, ce qui mitigera le problème de faire tourner rsync en root. Nous spécifions ensuite le fichier de log, ce fichier sera important pour débugger si vous avez des problèmes. Enfin, nous spécifions les répertoires qui peuvent être copiés en créant ce que l'on appelle des modules. Un module rsync est un ensemble d'informations qui spécifient l'accès à un répertoire, cela peut contient le chemin vers le répertoire, et des options qui précisent les droits d'accès ainsi que quelques options supplémentaires. Dans notre cas, nous créons le module "original" pour lequel le chemin d'accès est /original. Ce répertoire aura le droit d'être listé quand quelqu'un interrogera notre serveur pour avoir la liste des répertoires disponibles (list = yes) et nous n'autorisons pas de modifications de ce répertoire (read only = yes) Nous allons maintenant interroger notre serveur pour voir quels sont les modules disponibles. Nous nous plaçons sur la machine cliente. root@client # rsync serveur:: original Le répertoire à copier Nous voyons ici le module "original" avec sa description Pour nous synchroniser, nous lançons le même type de commande que précédemment. root@client # rsync -rv serveur::original /copie receiving file list ... done toto wrote 83 bytes read 126 bytes 139.33 bytes/sec total size is 12 speedup is 0.06 root@client # ls -la /copie total 12k drwxr-xr-x 2 root root 4.0k Dec 13 12:01 ./ drwxr-xr-x 22 root root 4.0k Dec 13 10:46 ../ -rw-r--r-- 1 root root 12 Dec 13 11:56 toto Pif paf ! Nous voyons cette fois-ci que le contenu du répertoire a bien été copié (et non pas tout le répertoire comme précédemment) Victoire ! Il ne nous reste plus qu'à améliorer notre solution et à la sécuriser ! 6- Mise en place de la sauvegarde incrémentaleMaintenant que nous arrivons à faire notre sauvegarde à distance, il nous reste à gérer la partie incrémentale. Pour cela, il nous suffit d'utiliser l'option --backup de rsync et --backup-dir pour spécifier où sauvegarder les modifications. Nous pouvons maintenant utiliser l'option --delete puisqu'une sauvegarde va normalement se faire dans /copie/backup. root@client # rsync -rv --delete --backup --backup-dir=/copie/backup serveur::original /copie root@client # ls -la /copie total 12k drwxr-xr-x 2 root root 4.0k Dec 13 10:58 ./ drwxr-xr-x 22 root root 4.0k Dec 13 10:46 ../ -rw-r--r-- 1 root root 12 Dec 13 10:54 toto root@serveur # rm /original/toto root@client # rsync -rv --delete --backup --backup-dir=/copie/backup serveur::original /copie root@client # ls -la /copie total 12k drwxr-xr-x 3 root root 4.0k Dec 13 12:11 ./ drwxr-xr-x 22 root root 4.0k Dec 13 10:46 ../ drwxr-xr-x 2 root root 4.0k Dec 13 12:11 backup/ root@client # ls -la /copie/backup total 12k drwxr-xr-x 2 root root 4.0k Dec 13 12:11 ./ drwxr-xr-x 3 root root 4.0k Dec 13 12:11 ../ -rw-r--r-- 1 root root 12 Dec 13 10:54 toto Nous voyons ici que le répertoire /copie ne contient plus le fichier toto, mais que celui-ci a bien été sauvegardé dans /copie/backup. Ainsi, pour faire une copie journalière, il nous suffira de lancer le script à heure régulière, par le fichier crontab par exemple, et de recréer à chaque fois un nouveau répertoire de backup avec la date du moment par exemple. Cela nous donnera un répertoire principal contenant une image identique au serveur, et des répertoires de sauvegarde contenant les fichiers modifiés ou effacés de chaque jour (attention, il est préférable de ne pas mettre les répertoires de backup dans le même répertoire que le miroir, car rsync penserait que ces répertoires sont des copies des réprtoires présents sur le serveur et les effacerait/copierait à chaque fois !) Si nous lançons par exemple la commande suivante dans un script lancé quotidiennement: rsync --force --ignore-errors --delete --backup --backup-dir=/copie/increment/$JOUR -av serveur::original/ /copie/main La variable jour contenant la date du jour. Nous obtenons le résultat suivant après une douzaine de jours: root@client # ls -la /copie/increment total 76k drwxr-xr-x 19 root root 4.0k Dec 12 22:01 ./ drwxr-xr-x 6 root root 4.0k Nov 30 11:54 ../ drwxr-xr-x 2 root root 4.0k Nov 30 09:22 2004-11-26/ drwxr-xr-x 2 root root 4.0k Nov 27 15:15 2004-11-27/ drwxr-xr-x 2 root root 4.0k Nov 28 15:15 2004-11-28/ drwxr-xr-x 2 root root 4.0k Nov 29 09:41 2004-11-29/ drwxr-xr-x 6 root root 4.0k Nov 30 12:25 2004-11-30/ drwxr-xr-x 6 root root 4.0k Dec 1 22:01 2004-12-01/ drwxr-xr-x 7 root root 4.0k Dec 2 22:01 2004-12-02/ drwxr-xr-x 5 root root 4.0k Dec 3 22:01 2004-12-03/ drwxr-xr-x 2 root root 4.0k Dec 4 22:01 2004-12-04/ drwxr-xr-x 2 root root 4.0k Dec 5 22:01 2004-12-05/ drwxr-xr-x 7 root root 4.0k Dec 6 22:02 2004-12-06/ drwxr-xr-x 5 root root 4.0k Dec 7 22:01 2004-12-07/ drwxr-xr-x 6 root root 4.0k Dec 8 17:39 2004-12-08/ drwxr-xr-x 5 root root 4.0k Dec 9 22:01 2004-12-09/ drwxr-xr-x 4 root root 4.0k Dec 10 22:01 2004-12-10/ drwxr-xr-x 3 root root 4.0k Dec 11 22:01 2004-12-11/ drwxr-xr-x 3 root root 4.0k Dec 12 22:01 2004-12-12/ Et hop, c'est bien le résultat escompté ! Il ne nous reste plus qu'à sécuriser notre solution en utilisant SSH pour encapsuler les échanges. 7- Sécurisation de la solutionNous arrivons à la partie intéressante de notre sujet, l'industrialisation de notre solution. Nous avons vu que pour des raisons d'accès aux répertoires copiés, il était parfois nécessaire de donner les droits root au processus rsync. Cela n'est clairement pas acceptable d'un point de vue sécurité. Une faille dans l'application aurait pour conséquence de donner un accès root distant aux vilains pirates. Nous allons voir comment l'utilisation de SSH permet de répondre à ce problème, et d'apporter encore plus de sécurité. Faire tourner rsync sur SSHL'utilisation de SSH avec rsync est tellement simple que cela en devient déroutant ! D'ailleurs, les documentations que j'ai pu trouver sur le net en parlent à peine, comme si tout coulait de source tellement la solution est simple. Tout d'abord, il faut que vous ayez un serveur SSH qui tourne sur votre serveur, voir le document sur la configuration d'un accès sécurisé à une machine par SSH. Et il faut aussi que SSH soit installé sur la machine cliente. L'utilisation de SSH par rsync se fait simplement en utilisant l'option "-e ssh", tout ce qui peut se passer ensuite est transparent pour l'utilisateur. Par exemple, si nous reprenons un des exemples précédents. root@client # rsync -rv -e ssh serveur::original /copie Nous donnera le même résultat que précédemment, sauf que nous aurons utilisé SSH. La différence résidera dans le fait que SSH vous demandera un mot de passe si vous avez configuré l'authentification par mots de passe. Cela n'a l'air de rien, mais SSH apporte: - Un chiffrement des échanges, ce qui fait que personne ne pourra voir ce qui transite sur le réseau, - Une authentification du serveur et du client, celle-ci pouvant se faire par mot de passe ou par clefs SSH, - Un sécurisation du processus en ne faisant plus écouter rsync sur le réseau, mais SSH. Pour vérifier la mise en oeuvre, commencez par tester SSH seul, puis si cela marche comme vous le voulez, utilisez l'option -e ssh de rsync. Configuration de SSH
La solution que nous avons mise en place n'est pas encore très satisfaisante d'un point de vue
sécurité. L'authentification se fait pour l'instant par mots de passe, le service rsync est
accessible depuis l'extérieur. Le fait de mettre SSH en oeuvre donne potentiellement un accès root
complet à la machine.
Nous allons maintenant voir comment configurer SSH pour pallier à ces problèmes.
Tout d'abord pour l'authentification, SSH nous permet d'utiliser une authentification forte par
clefs SSH, nous n'allons pas nous en priver car celle-ci permet notamment de prescrire l'utilisation
des mots de passe des comptes utilisateurs.
Il nous faut donc tout d'abord créer une paire de clefs SSH. Pour le lieu de sauvegarde de la clef,
nous entrerons autre chose que /root/.ssh/id_rsa pour ne pas écraser un éventuel fichier existant.
Nous entrerons simplement "Entrée" pour les mots de passe. Ainsi, nous ne protègerons pas la clef
privée par passphrase, ce que nous voulons. Et bien oui, si nous protégions la clef par un mot de
passe, l'accès à la clef lors d'un reboot ne serait plus possible et la fonction de sauvegarde
ne marcherait plus.
root@client # ssh-keygen -t rsa -b 1024
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/id_rsa2
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa2.
Your public key has been saved in root/.ssh/id_rsa2.pub.
The key fingerprint is:
61:90:16:97:ea:e2:59:10:94:f0:fd:a2:d4:53:9e:97 rootclient
Nous avons maintenant une clef privée pour l'utilisateur root, placée au bon endroit
(/root/.ssh/id_rsa2)
Nous en limitons l'accès.
root@client # chmod 400 /root/.ssh/id_rsa2
Il faut maintenant préciser dans quel cas utiliser cette clef. Pour cela, nous créons le fichier
"config" dans /root/ssh/.
Ce fichier doit contenir le texte suivant:
Host @IP_du_serveur
User root
Compression yes
Protocol 2
RSAAuthentication yes
StrictHostKeyChecking no
ForwardAgent yes
ForwardX11 yes
IdentityFile /root/.ssh/id_rsa2
Il nous faut maintenant copier la clef publique sur le serveur. Etant donné que SSH est censé
fonctionner actuellement, on ne s'en prive pas en faisant le transfert par scp.
root@client # scp /root/.ssh/id_rsa2.pub root@serveur:/root/.ssh/id_rsa2.pub
Il faut encore sur le serveur copier le contenu du fichier de la clef publique dans le
fichier authorized_keys2 qui contient l'ensemble des clefs publiques des utilisateurs autorisés
à se connecter.
root@serveur # cat /root/.ssh/id_rsa2.pub >> /root/.ssh/authorized_keys2
Vous devriez maintenant être en mesure de vous connecter en SSH sans donner de mot de passe grâce
aux clefs SSH présentes sur le client et le serveur. Mais si cela est bien pratique, ce n'est pas
le top pour la sécurité de laisser un accès root sans mot de passe. Il suffirait que la clef
privée SSH soit volée pour qu'une personne ait un accès distant root.
Nous allons donc voir comment augmenter le niveau de sécurité de cet accès.
Tout d'abord, nous allons limiter les commandes autorisées avec cette clef ainsi que la machine
à partir de laquelle l'accès est autorisé. Pour cela, nous allons spécifier ces contraintes dans
la clef publique sur le serveur. Il suffit d'ajouter avant "ssh-dss" les informations from et
command. Cela nous donne pour la clef publique sur le serveur.
from="@IP_du_client",command="/root/rsync_command" ssh-dss AAAAB3NzaC1kc3MAAAEBAOF43lOwq8A5v4hjoKU769fy3hYT8u+DuDMbvegQ4uJSkvMvpObFYhYZdkk0mTHDKM3nm2r1fpxpIqN
8qpUBCe96DtjzU49Qt+xdRp/IiUkBYfPaMAwQ93HgVCWXatYjZtcFfjovNaHLD2etG+WAKqRAjTbCsjtaJ0xV7+GQhqeGc816WFY5uKNDyEvdYRplM83LuTyfCwpo9hxprvlUD0F/uarSQBIGXstpDf7HrrcA
gq4Lba8Z93ccoJghmju6f+XToTlZLIWJtyul2UrEVLrO4ioMmTS0Nmf6phJRL5YDE7eNQ21BkOqwUfVUgZ7ysgWnYyuFL+O+nFZhc7WlpFEAAAAVAJQ7LvmmcBSxfDZ3Q0NkrowSgldRAAABAHqg3QPSU3HTB
mHsc7H9Ksgh+07+KYVKWNO/Y76T7EA94HFg35IgfW9ELqvmwjPlLyU3YzfNgz/QdD3ZmZyYfxq26FVkeGFhfAsbXwFN8qtojuPtmLXW9vbOHwRiW8zU9KcIcs7AdXnrp/AYpJHX9sPFNDHLiG7LXTn+0NtVIi
2R3/yBouWMbZqH+FNfgV6dpdquKwCD+T+ijtOKVvvEIUlaAyQbaAoDxx1pZgnlcqi4Y/VU4bseHY55EPFpyLO4S40yB5TvsYuZEYXHjuw+e1+vG26yriFCLlWBQhA6+3QacfttJxErGNeB0bl1XLQgrblJ3jc
nJBRyze9s8iRrzCgAAAEBANnApVKbjJ2GC95F9qoy1VHBHXl04bfvdHIDWBYeytPKzYipt8ux/+s5B076w1wufTMlcdnFtccB7ysfZZQWZz+FsHiYC4UKHAI06xH0SLtvd7OSLItj3Jad/XsmhMkLKZPR8fR4
qsZ6hC0QLyx57ZG5z0ugiJZBcwhPqFI8ouf0J4ZPvJdymZjmm76bjhC0WeKRZejIpMOx1b1B1dTjIYGAZGsZfZt18Gtc8UBkA4Iq9Ut0pi0iUWyE2gBpLowLkRB10HTpvmRP+tqgOHEB865aJvMcxm0IzWRDC
PZXDhO2PIY20hcWAO8cv5+1WDag2t0QyrYePmXkC/o9gsgharY= user@client
Si vous essayez de vous connecter, cela ne devrait plus marcher :-/
Nous voyons que les commandes autorisées seront celles spécifiées dans le fichier
/root/rsync_command. Notre but est que ce fichier ne nous autorise que les commandes nécessaires
au fonctionnement de rsync. Nous allons donc faire en sorte que seule la commande "rsync --server"
soit possible. Ainsi, toute personne essayant de se connecter à notre machine en SSH se verra
poliment rejetée. Voici le fichier.
root@serveur # cat /root/rsync_command
#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
rsync\ --server*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Rejected"
;;
esac
Et hop, maintenant les accès sont limités à une seule machine qui est le client, et à la seule
commande qui permet de faire fonctionner rsync.
Il n'y a plus qu'à tester.
root@client # rsync -rv -e ssh serveur::original /copie
S'il n'y a pas de message d'erreur, ça devrait être bon !
Mais vous pourriez me dire que le serveur rsync est toujours joignable directement, et vous auriez
raison. Toute la sécurité que nous avons mis en oeuvre ne servirait donc à rien...
La réponse à ce problème est relativement simple. Etant donné que notre serveur rsync n'est plus
accédé directement depuis le réseau, mais localement depuis le tunnel SSH, il n'y a plus de raison
de le faire écouter sur le réseau, mais seulement sur l'interface locale (l'interface de loopback)
Pour cela, il nous suffit de le spécifier quand on lance le démon.
root@serveur # rsync --daemon --address 127.0.0.1
root@serveur # netstat -anp | grep rsync
tcp 0 0 127.0.0.1:873 0.0.0.0:* LISTEN 16542/rsync
Et maintenant notre serveur est invisible depuis le réseau. Il est désormais obligatoire de passer
par SSH pour accéder au serveur rsync. Cette solution n'est pas non plus ce qui se fait de plus
sécurisé, et il serait notamment possible de chrooter l'application rsync, mais nous n'irons pas
jusqu'à ce niveau de complexité.
Il ne nous reste plus qu'à finaliser la solution en l'automatisant.
8- Industrialisation de la solution
A partir du moment où la solution SSH est en place et que le démon rsync tourne sur le serveur (sur
l'interface locale) toute la configuration qu'il reste à faire est sur le client.
Il faut créer un petit script qui fait la sauvegarde, et lancer ce script automatiquement par
cron. Je vous propose le petit script suivant qui permet de faire une sauvegarde incrémentale avec
création d'un fichier "timer" qui nous donne à chaque sauvegarde le temps de celle-ci.
#!/bin/sh
# Script de sauvegarde incrementale du repertoire /original sur la machine serveur
# Ce script utilise l'outil de synchronisation rsync pour faire une image
# globale du repertoire /original de la machine serveur dans le repertoire
# /copie/main/ de la machine client.
# Les sauvegardes incrementales journalieres sont dans chacun
# des repertoires identifies par la date dans le repertoire
# /copie/old_data. Par exemple, le repertoire
# 2004-11-25 contiendra les valeurs des fichiers a ce jour qui seront
# recuperables.
# Variable representant le jour de la sauvegarde
JOUR=`date +%Y-%m-%d`
# On cree le repertoire du jour et un fichier timer qui nous donnera
# les heures de debut et de fin du transfert
if [ -d "/copie/old_data/$JOUR" ]
then
echo "Le repertoire /copie/old_data/${JOUR} existe deja !";
else
mkdir /copie/old_data/$JOUR;
fi
touch /copie/old_data/$JOUR/timer
echo "---------------------------------" >> /copie/old_data/$JOUR/timer
echo "Heure de demarrage du transfert:" >> /copie/old_data/$JOUR/timer
date >> /copie/old_data/$JOUR/timer
echo "---------------------------------" >> /copie/old_data/$JOUR/timer
# On lance le script rsync de transfert des fichiers
/usr/local/bin/rsync -e ssh --force --ignore-errors
\ --delete --backup --backup-dir=/copie/old_data/$JOUR -av serveur::original/
\ /copie/main
# On ecrit l'heure de fin dans le timer
echo "Heure de fin du transfert:" >> /copie/old_data/$JOUR/timer
date >> /copie/old_data/$JOUR/timer
echo "---------------------------------" >> /copie/old_data/$JOUR/timer
# On detruit les fichiers vieux de plus de 30 jours
find /mnt/sauvegarde/old_data/ -atime +30 -exec rm -rf {} \;
Vous pouvez créer le fichier "sauvegarde" dans /etc/init.d et y copier le contenu du script.
Le rendre executable et le tester.
root@client # touch /etc/init.d/sauvegarde
root@client # chmod 755 /etc/init.d/sauvegarde
root@client # /etc/init.d/sauvegarde
Et hop, ça devrait marcher. Il ne vous reste plus qu'à modifier le fichier /etc/crontab pour lancer
automatiquement le script. Par exemple pour le lancer à 22h30 tous les jours, vous pouvez ajouter
la ligne suivante.
30 22 * * * root /etc/init.d/sauvegarde
Et voilà ! Vous pouvez maintenant sauvegarder tous vos disques ou répertoires de façon incrémentale
et automatisée.
Merci rsync !
|
Dernière mise à jour le 26/04/05.
Envoyez vos commentaires à eric@lalitte.com