| View previous topic :: View next topic |
| Author |
Message |
antoine_
Tux's lil' helper
Joined: 07 Apr 2006
Posts: 103
Location: Paris ou Bordeaux
|
 Posted: Sun Nov 19, 2006 10:58 pm Post subject: [Howto] Sauvegarde de fichiers personnels avec rsync et ssh |
 |
|
Bonjour,
Je viens de mettre en place un système me permettant d'effectuer des sauvegardes depuis mon portable vers un serveur distant (dans mon école). Je vous propose ici la démarche suivie.
Le système mis en place ici est finalement assez simple. Il utilise cron, rsync, et ssh. Il existe de nombreux moyens de faire des sauvegardes. Celui que je présente ici répond à mon besoin, et surtout aux moyens dont je dispose. De plus je ne suis pas un pro du script. Du coup si vous avez des améliorations à apporter, ou bien d'autres idées pour effectuer des sauvegardes, je vous invite à les poster.
Il n'y a rien que des fonctionnalités tout à fait banales des différents outils, mais je ne connaissais pas ça il y a peu de temps, du coup je me suis dit que je n'étais peut-être pas le seul dans ce cas là.
Pour le réaliser, je me suis inspiré d'un howto de Howto Forge : Create Incremental Snapshot-style Backups With rSync And SSH. Il propose notamment une sauvegarde des bases de données. N'étant pas concerné, je n'ai pas exploité cette partie.
1 - Principe
Sur un poste de travail, vous disposez de fichiers personnels que vous souhaitez sauvegarder. Vous disposez également d'un serveur distant (un autre poste de travail, un serveur à votre université/école/boulot, une machine sur votre réseau local). Dans mon cas il s'agit de mon portable et d'un serveur à mon école sur lequel j'ai compte personnel.
Le but est d'effectuer une copie de certaines données choisies, du poste de travail vers le serveur afin de se prémunier d'un crash de disque, d'un vol de portable, etc...
Pour cela, cron va lancer à intervalles réguliers un script (toutes les 30 minutes pour moi). Il s'agit d'une commande rsync qui va synchroniser les fichiers entre le poste de travail et le serveur. Seuls les fichiers ayant été modifiés vont être copiés sur le serveur, ce qui va donc réduire le volume à transférer. De plus, rsync va compresser les données pendant le transfert, et elles seront chiffrées grâce à ssh. En revanche les données ne sont pas compressées sur le serveur. Maintenant que j'y pense cela pourrait en fait se faire assez simplement, probablement que j'ajouterai cette fonctionnalité plus tard...
Avantages :
- Les sauvegardes ne nécessitent aucune intervention.
- Seuls les fichiers modifiés sont mis à jour, d'où un volume de données à transférer réduit.
- Les données à transférer sont chiffrées pendant le transfert.
Inconvénients
- Selon le réseau par lequel vont transiter les données, il n'est pas forcément souhaitable de sauvegarder des quantités importantes d'information. Ainsi, effectuer une sauvegarde complète de sa bibliothèqe de films en passant par Internet n'est pas forcément une bonne idée. Sur un réseau local cela est en revanche réalisable.
- Dans la version actuelle, les données ne sont pas compressées sur le serveur. Cela pourrait être amélioré.
2 - Prérequis
Pour cette manipulation il vous faut :
- Un poste de travail, ayant rsync et openSSH installé. Il me semble que rsync est installé par défaut sur Gentoo. Pour openSSH un emerge -av openssh réglera le problème.
- Un serveur ayant rsync, ssh et un serveur ssh (sshd) fonctionnel. Vous devez posséder un compte utilisateur sur ce serveur.
A noter que vous n'avez (presque) pas besoin de compte root sur aucune des deux machines pour mettre en place ce système.
3 - Test de rsync
Pour la suite, on nommera desktop le poste de travail, et localuser le compte utilisateur ; on nommera server le serveur et remoteuser le compte utilisateur sur le serveur.
On va commencer par tester rsync, pour voir si tout fonctionne bien.
Sur le poste de travail, effectuer les commandes suivantes :
| Code: | $ touch fichierTest
$ "rsync -avz ./fichierTest -e ssh remoteuser@server.domaine.com:~remoteuser |
Vous aurez à rentrer le mot de passe de votre compte remoteuser pour pouvoir effectuer le transfert.
Pour vérifier que cela a fonctionné, connectez-vous sur server via ssh et vérifiez l'existance d'un fichier vide baptisé "fichierTest". Vous pouvez vous amuser à ajouter un contenu à fichierTest, et relancer la commande. Le contenu aura changé sur server également.
Ca marche ? Alors c'est déjà presque fini :o)
L'option -z sert à compresser les données pendant le transfert. L'option -a active le mode archive, qui correspond à plusieurs options, comme par exemple la conservation des permissions, des répertoires, etc...
L'option -e permet de faire appel à ssh pour le transfert des fichiers
4 - Identification automatique
Lors de la précédente égape, vous avez eu à rentrer votre mot de passe. Pour un script qui a lieu régulièrement, on ne souhaite pas rentrer le mot de passe à chaque fois.
Pour cela, il va falloir faire appel au mécanisme de clé publique de ssh.
Sur desktop exécutez la commande suivante :
| Code: | | $ ssh-keygen -t dsa |
Ne rentrez pas de passphrase (tapez entrée directement). Laissez le chemin par défaut qui vous est proposé. ssh_keygen génère dans ~/.ssh une clé privé sous le nom id_dsa et une clé publique sous le nom id_dsa.pub.
Copiez la clé publique sur server en exécutant la commande suivante sur desktop :
| Code: | | $ scp ~/.ssh/id_dsa.pub remoteuser@server.domaine.com:~remoteuser |
Ensuite, connectez-vous à server. Si le répertoire .ssh n'existe pas, il faut le créer :
| Code: | $ mkdir .ssh
$ chmod 700 .ssh |
Une fois que le répertoire existe, toujours depuis server :
| Code: | $ cat id_dsa.pub >> .ssh/authorized_keys
$ rm id_dsa.pub |
On vient de rajouter la clé publique de desktop aux clés publiques acceptées par server.
Pour vérifier que cela fonctionne, loguez vous depuis desktop sur server via ssh. Il ne devrait vous demander aucun mot de passe.
5 - Mise en place de la tâche cron
Maintenant il ne reste plus qu'à dire à desktop de faire une mise à jour de certains répertoires à certains intervalles de temps.
Créons un répertoire .rsync et un fichier exécutable nommé backup grâce à :
| Code: | $ mkdir .rsync
$ cd .rsync
$ touch backup
$ chmod 700 backup |
Editez ensuite le fichier backup et copiez les lignes suivantes :
| Code: | #!/bin/bash
rsync -az --delete ~localuser/repertoire1 [...] ~localuser/repertoireN -e ssh remoteuser@server.domaine.com:~remoteuser/Sauvegardes |
Remplacez "~localuser/repertoire1 [...] ~localuser/repertoireN par une liste de répertoires ou de fichiers que vous souhaitez sauvegarder. Sur server ces fichiers seront contenus dans un répertoire Sauvegardes, afin de ne pas mettre le bazar dans vos affaires.
L'option --delete efface les fichiers sur server lorsqu'ils ont été effacés sur desktop.
Vous pouvez donc adapter la commande en fonction des répertoires que vous souhaitez sauvegarder.
Il est possible de créer un fichier de log, en redirigeant la sortie de rsync vers un fichier dans .rsync. Je n'ai pas choisi de le faire, mais cela peut être utile pour débuger. A vous de voir.
A présent il va falloir indiquer à cron d'exécuter cette tâche à intervalles réguliers.
Tout d'abord, vérifiez si localuser a accès à cron :
Si on vous dit que vous n'avez pas le droit d'utiliser cette commande, c'est que vous n'êtes pas dans le groupe cron sur desktop. En root depuis desktop, ajouez localuser au groupe cron :
| Code: | | $ usermod -a cron localuser |
Sur desktop, éditez un fichier cron.txt dans .rsync :
| Code: | # Sauvegardes sur serveur distant
0,30 * * * * /home/localuser/.rsync/backup |
Et il n'y a ensuite plus qu'à le rajouter à la liste des tâches :
Ici on dit que l'on veut lancer le script backup à la demi et à pile de chaque heure.
Il est possible de mettre plusieurs lignes dans le fichier cron.txt et de créer plusieurs scripts afin de lancer des sauvegardes avec différentes fréquences. Ainsi on peut sauvegarder des documents importants souvent, et d'autres moins importants de manière plus espacée.
En principe le système devrait dont faire des sauvegardes de manière automatique.
Il est à noter qu'en cas de perte du disque ou de la machine, on perd au maximum une demi-heure de données dans l'exemple qui est donné. La système ne fait pas de la copie en continu sur le serveur. Pour une utilisation en tant que station de travail, je trouve que ce serait un peu excessif.
J'attends donc tout commentaire, correction, complément à ce petit howto... |
|
| Back to top |
|
 |
truc
Advocate
Joined: 25 Jul 2005
Posts: 3199
|
| Posted: Tue Nov 21, 2006 5:16 pm Post subject: |
|
|
Ca semble sympa, j'fais des choses similaires, mais sans cron, just un chti clic dans rox, ce qui peut me permettre de rentrer la passphrase, car: | Quote: | | Ne rentrez pas de passphrase (tapez entrée directement) |
Je trouve ça un peu étrange non? On perd tout le bénéfice de l'authentification, non?
M'enfin en tout cas, c'est pas mal de combiner ssh et rsync je trouve:)
_________________
The End of the Internet! |
|
| Back to top |
|
|
antoine_
Tux's lil' helper
Joined: 07 Apr 2006
Posts: 103
Location: Paris ou Bordeaux
|
| Posted: Tue Nov 21, 2006 9:41 pm Post subject: |
|
|
En fait l'authentification se fait grâce à la clé publique et à la clé privée générées au début du howto.
Le principe est que la clé publique est communiquée aux machines auxquelles on veut se connecter, comme on le fait ici grâce à scp. La clé privée ne doit surtout pas être communiquée.
La passphrase sert à chiffrer la clé privée.
Effectivement, il y a un risque au niveau de la sécurité si on n'utilise pas de passphrase : si quelqu'un arrive à s'introduire sur la machine, il peut prendre la clé privée. Comme elle n'est pas chiffrée, il pourrait donc arriver à se connecter au compte utilisateur sur le serveur en se faisant passer pour la machine corrompue.
Deux choses par rapport à ce risque :
- Tout d'abord utiliser ce dispositif sans passphrase sur un compte root semble être une grosse bêtise.
- J'ai fait quelques recherches, et il semble qu'il existe un moyen de contourner ce problème : l'utilisation de ssh-agent. On créé une clé avec passphrase. Au lancement de la session utilisate
ur, on lance ssh-agent (de manière automatique). Il va demander de rentrer la passphrase. Il garde alors la clé privée en mémoire. Toutes les identifications suivantes se font alors de manière automatique. Par contre ça oblige à rentrer deux mots de passe au lancement de la session...
Pour mon utilisation qui reste simple, je ne pense pas utiliser ssh-agent. Cependant je vais creuser un peu le sujet, c'est intéressant. Je le mettrais en place une fois, pour voir ce que ça donne. Ca me fait ça à creuser, en plus du problème de la compression des données côté serveur :o) |
|
| Back to top |
|
|
yet_another_olivier
n00b
Joined: 31 Oct 2005
Posts: 4
|
| Posted: Wed Nov 22, 2006 11:42 am Post subject: |
|
|
| antoine_ wrote: |
[*]J'ai fait quelques recherches, et il semble qu'il existe un moyen de contourner ce problème : l'utilisation de ssh-agent. On créé une clé avec passphrase. Au lancement de la session utilisate[/list]ur, on lance ssh-agent (de manière automatique). Il va demander de rentrer la passphrase. Il garde alors la clé privée en mémoire. Toutes les identifications suivantes se font alors de manière automatique. Par contre ça oblige à rentrer deux mots de passe au lancement de la session...
|
Ils est aussi possible d'utilisé keychain qui permet de conserver la clé en mémoire même si on sort de la session qui utilise ssh-agent. Ce qui fait qu'en pratique, on ne rentre la passphrase qu'au boot de la machine, a l'ouverture de la premiére session. Trés pratique si on a des ssh en crontab, par exemple. Mais un peu moins sûr, car si quelqu'un arrive a avoir un accés root sur la machine, il pourra aller facilement sur toute celles ou la clé publique est déployée, enfin, d'aprés ce que j'ai compris.
il y a un Howto dans la doc officielle :
http://www.gentoo.org/doc/fr/keychain-guide.xml
_________________
--
Olivier |
|
| Back to top |
|
|
SnowBear
l33t
Joined: 03 Sep 2005
Posts: 773
Location: France - Bordeaux
|
| Posted: Sun Dec 24, 2006 6:21 pm Post subject: |
|
|
Salut,
merci pour cet excellent tutoriel 
Je cherchais depuis quelques temps la meilleure façon de sauvegarder mes données et je crois que la tienne est pas mal ^^. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
