Sauvegardes avec rsync

rsync est un outil puissant permettant de synchroniser des arborescences, pas

nécessairement sur la même machine. Il est généralement utilisé pour faire des
sauvegardes, mais on peut aussi par exemple s’en servir pour mettre un site en
ligne.

Il fait l’inventaire des fichiers dans les deux répertoires et ne recopie que les
fichiers soit qui n’existent pas dans le répertoire cible, soit qui ont été modifiés
depuis la dernière copie. Comme scp, rsync utilise un tunnel ssh lorsque l’un des
deux répertoires (ou les deux) à synchroniser est distant.

Nous allons voir les bases de rsync et la façon dont on peut s’en servir pour faire
des sauvegardes, nous allons voir ensuite comment il est possible d’automatiser
cette tâche et de régler le problème du mot de passe (documentation)

Commande et options

Lorsque l’on souhaite sauvegarder une arborescence sur un répertoire distant, on

procède de la sorte :

rsync --progress -avz repertoiresource/* login@hote:repertoirecible/

Détaillons les options et arguments de cette commande :

 repertoiresource est le répertoire de votre disque dur dans lequel se trouve

l’arborescence à sauvegarder

 login est votre login sur la machine distante

 hote est le nom d’hôte de la machine distante

 repertoirecible est sur la machine le chemin vers le répertoire dans lequel vous
souhaitez stocker les fichiers sauvegardés
 –progress sert à afficher une jauge à chaque fois qu’un fichier est transféré

 -avz : le v sert à activer la verbosité, le a précise que l’on utilise le mode

« archive » (préservation des liens symboliques, des droits, etc.), z compresse
les fichiers pendant le transfert.
Vous remarquerez que pour que tout cela fonctionne, vous devez saisir votre mot
de passe…

A chaque fois que cette commande sera invoquée, le répertoire distant sera
synchronisé avec le répertoire source. Comme seuls les fichiers nouveaux ou
modifiés sont transférés, la synchronisation est très rapide. Vous noterez que
contrairement à ce que le mot synchronisation laisse entendre, la sauvegarde ne se
fait que depuis la source vers la cible. Si vous modifiez des fichiers dans le
répertoire cible, ils ne seront jamais recopiés dans le répertoire source par rsync.

Le mot de passe

Le problème qui se pose lorsque vous lancez la sauvegarde est que

systématiquement un mot de passe vous est demandé. Le caractère fastidieux de
cette saisie peut, à la longue, s’avérer fort pénible. La solution qui a mes yeux
semble la plus élégante est d’utiliser la cryptographie asymétrique.

Avant de lire la suite, vous devez accepter l’idée qu’il est impossible de passer le
mot de passe en argument à rsync, il vous enverra promener systématiquement et je
vous avoue qu’au niveau sécurité ça laisserait franchement à désirer.

Pour commencer vous devez créer un couple de clés RSA, l’une des clés est la clé
publique et l’autre la clé privée. La clé privée va vous servir à signer
électroniquement un document, et la clé publique servira à vérifier que la signature
est correcte. Vous devez donc mettre sur le serveur distant votre clé publique et
conserver sur votre disque dur votre clé privée. A chaque tentative de connexion, le
serveur va vous envoyer une donnée qui sera automatiquement signée à l’aide de
votre clé privée, puis retournée au serveur. Le serveur va ensuite utiliser votre clé
publique pour s’assurer que la signature est correcte. Si c’est le cas, la demande de
connexion sera acceptée, sinon elle sera refusée.

Cela signifie que vous n’aurez plus jamais besoin de saisir de votre mot de passe
lorsque, depuis une machine disposant de votre clé publique, vous vous
connecterez en ssh (ou avec une commande utilisant ssh, par exemple scp et rsync).

Vous devrez donc :

 Générer un couple de clés RSA

 Recopier votre clé publique sur le serveur

Je me suis librement inspiré cette page.

Génération d’un couple de clés

On génère un couple de clés avec la commande ssh-keygen :

ssh-keygen -t rsa

Vous pouvez conserver toutes les options par défaut. Une fois l’exécution de cette
commande terminée, deux fichiers id_rsa et id_rsa.pub sont crées dans le repértoire
$HOME/.ssh/. id_rsa.pub est votre clé publique et id_rsa est votre clé privée.

Envoi de la clé publique sur le serveur

Il suffit d’utiliser la commande scp pour envoyer id_rsa.pub sur le serveur ssh. On
procède de la façon suivante :
scp $HOME/.ssh/id_rsa.pub login@hote:.ssh/authorized_keys

login est votre login sur la machine distante, et hote est le hostname de la machine
distante. Et pour la dernière fois, vous devrez saisir votre mot de passe !Il ne faudra
pas oublier de gérer les droits du fichier $HOME/.ssh/authorized_keys en le
mettant en 700 :

ssh login@hote "chmod 700 .ssh/authorized_keys"

Voici la syntaxe de la commande :

rsync –options source destination

Les commandes RSYNC utilisées dans notre cas sont les suivantes :

rsync -av --delete --log-file=/Backup/rsync_log.log /var/www /Backup/

rsync -av --delete --log-file=/Backup/rsync_log.log /opt/fog /Backup/
rsync -av --delete --log-file=/Backup/rsync_log.log /images /Backup/

Les options a et v signifient archive et verbose. L’option archive permet de conserver tous les
attributs du fichier lors de la copie (ses droits, son propriétaire, son groupe, si c’est un lien
symbolique, etc…). L’option verbose couplée à l’option –log-file permet à rsync de nous parler et
d’inscrire ce qu’il fait dans un fichier journal. Tout ce que fait rsync sera inscrit
dans /Backup/rsync_log.log dans notre cas.
 Introduction
rsync est un logiciel (libre) qui permet la synchronisation de fichiers (de
manière unidirectionnelle) ; il est très souvent utilisé pour la réalisation de
sauvegardes.

À cet effet, on va voir aujourd’hui comment faire des sauvegardes complètes

et incrémentielles avec cet outil sous Linux.

Dans les exemples qui suivent, je vais utiliser 2 serveurs (Debian) :

Nom IP
srv-1 192.168.0.10
srv-filer 192.168.0.20
Le but va être de sauvegardé les données de « srv-1 » vers « srv-filer » ; les
commandes rsync s’effectueront depuis le serveur srv-filer.
La syntaxe de rsync reste relativement simple, et se présente comme suit :

1 rsync options source destination

SSH
Par défaut, rsync utilise SSH. Ce qui veut dire que pour chaque commande
rsync, un mot de passe vous sera demandé. Puisque les sauvegardes sont
habituellement automatisées, ce n’est pas l’idéal.

Il faut donc en amont générer une paire de clés pour SSH puis faire la
propagation sur le serveur distant afin de pouvoir s’authentifier sans mot de
passe (authorized_keys).

On génère donc la paire de clés :

1 root@srv-filer:/# ssh-keygen
Puis on lance la copie sur le serveur distant (ici srv-1) :
1 root@srv-filer:/# ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.10
On peut désormais se connecter en SSH depuis srv-filer vers srv-1 sans mot
de passe.

Sauvegarde complète
Si on souhaite faire une sauvegarde complète de srv-1 vers le répertoire «
/backups/srv-1/ » sur srv-filer :

root@srv-filer:/# rsync -avHP --exclude={"/proc/*","/sys/*","/dev/*"} --numeric-ids root@192.168.0.10:/

1
/backups/srv-1/
Concernant les options utilisées :

 -a : mode archive, pour tout préserver au niveau des fichiers

(horodatages, permissions, etc…)
 -v : augmente la verbosité
 -H : conserve les liens
 -P (ou –progress) : affiche des informations concernant la progression
des transferts
 –exclude : exclue les répertoires mentionnés dans la sauvegarde
 –numeric-ids : ne remplace pas les uid/gid par des noms
d’utilisateur/groupe
N’oubliez pas l’option -a qui est la plus importante (identique à -rlptgoD).
Selon vos besoins néanmoins, je vous invite à consulter le man rsync
(disponible ici également).
Après cette commande, l’ensemble du serveur srv-1 a été sauvegardé :

1 root@srv-filer:/# ls /backups/srv-1/
2 bin boot datas dev etc home initrd.img lib lib64 lost+found media mnt opt proc root run sbin srv
3 sys tmp usr var vmlinuz
4 root@srv-filer:/#
5 root@srv-filer:/# du -hs /backups/srv-1
 4,9G /backups/srv-1

Sauvegarde incrémentielle
Dans cette partie, je vais entrer plus profondément dans les détails afin
d’avoir la meilleure compréhension possible. Je vais notamment minimiser
et cibler mes sauvegardes sur un répertoire de test qui sera « /datas »et
effectuer différentes manipulations.
Préparation
On commence sur srv-1 par créer 10 fichiers texte dans le
répertoire /datas pour nos tests :

1 root@srv-1:/# for i in {1..10}; do touch /datas/test$i.txt; done

2 root@srv-1:/#
3 root@srv-1:/# ls /datas/
4 test10.txt test1.txt test2.txt test3.txt test4.txt test5.txt test6.txt test7.txt test8.txt test9.txt
On peut ensuite procéder à la sauvegarde complète du répertoire. Repartant
de zéro, la commande est la suivante :

1 root@srv-filer:/# rsync -avHP --numeric-ids root@192.168.0.10:/datas/ /backups/srv-1/

Après cette opération, les 10 fichiers textes ont bien été sauvegardés dans
le répertoire /backups/srv-1/ sur srv-filer :

1 root@srv-filer:/# ls /backups/srv-1/
2 test10.txt test1.txt test2.txt test3.txt test4.txt test5.txt test6.txt test7.txt test8.txt test9.txt

Variable d’environnement date

Lorsqu’on va réaliser une sauvegarde incrémentielle, on souhaite que tous
les fichiers qui ont été modifiés ou supprimés aillent dans un autre répertoire.
Pour faire les choses proprement, et ainsi avoir une arborescence claire dans
les dossiers, le mieux est d’avoir des répertoires avec dates (pour s’y
retrouver). Pour permettre d’inclure la date dans une commande rsync, on
va ajouter une variable d’environnement date.
 On édite le fichier /etc/profile et on y ajoute la ligne ci-dessous :

1 root@srv-filer:/# vi /etc/profile :
2 ...
3 date=$(date +%d-%m-%Y)
Depuis le terminal, si on fait un echo de la variable, ce dernier nous renvoie
donc la date au format adapté :

1 root@srv-filer:/# echo $date

2 17-03-2018

Commande rsync
On va maintenant ajouter/modifier/supprimer certains fichiers dans le
répertoire /datas sur srv-1 :

1 root@srv-1:/datas# touch 0.txt 00.txt

2 root@srv-1:/datas# echo "test" | tee test5.txt test6.txt
3 root@srv-1:/datas# rm test10.txt
Puis on lance la sauvegarde incrémentielle grâce à la commande suivante :

root@srv-filer:/# rsync -auvHP --numeric-ids --delete --backup --backup-dir=/backups/old-srv-1/$date/

1
root@192.168.0.10:/datas/ /backups/srv-1/
Concernant les options ajoutées en comparaison de la sauvegarde
complète :

 -u : mettre à jour uniquement les fichiers modifiés

 –delete : efface les fichiers qui n’existent pas dans le répertoire source
 –backup : effectue une sauvegarde des fichiers modifiés/supprimés
 –backup-dir : précise l’emplacement de sauvegarde des fichiers
modifiés/supprimés
 – $date : la variable d’environnement qui nous permet de créer un dossier
à la date du jour
 On va maintenant vérifier ce qui s’est passé dans notre répertoire de
sauvegarde (même si la verbosité de rsync a dû déjà vous le dire).

Dans le répertoire contenant la sauvegarde complète (/backups/srv-1/) :

1 root@srv-filer:/# ls /backups/srv-1/
2 00.txt 0.txt test1.txt test2.txt test3.txt test4.txt test5.txt test6.txt test7.txt test8.txt test9.txt
On retrouve bien les 2 fichiers créés (0.txt et 00.txt), et le fichier supprimé
(test10.txt) n’est plus présent.
Si on regarde dans le répertoire /backups, un dossier old-srv1 a été créé :

1 root@srv-filer:/# ls /backups/
2 old-srv-1 srv-1
Dedans, un répertoire avec la date du jour a aussi été créé (grâce à notre
variable $date) :

1 root@srv-filer:/# ls /backups/old-srv-1/
2 17-03-2018
Pour ce qui est de son contenu :

1 root@srv-filer:/# ls /backups/old-srv-1/17-03-2018/
2 test10.txt test5.txt test6.txt
Comme attendu, les fichiers modifiés (test5.txt et test6.txt) et le fichier
supprimé (test10.txt) ont été sauvegardés dans ce répertoire.
Vérification du contenu des fichiers modifiés pour en être sur :

1 root@srv-filer:/# cat /backups/srv-1/test5.txt && cat /backups/srv-1/test6.txt

2 test
3 test
4 root@srv-filer:/#
5 root@srv-filer:/# cat /backups/old-srv-1/17-03-2018/test5.txt && cat /backups/old-srv-1/17-03-
6 2018/test6.txt
root@srv-filer:/#

On va refaire un test le lendemain. On modifie les

fichiers test1.txt, test2.txt et test3.txt :

1 root@srv-1:/datas# echo "test" | tee test1.txt test2.txt test3.txt

Puis on relance la commande rsync pour la sauvegarde incrémentielle :

root@srv-filer:/# rsync -auvHP --numeric-ids --delete --backup --backup-dir=/backups/old-srv-1/$date/

1
root@192.168.0.10:/datas/ /backups/srv-1/
Côté srv-filer, le dossier à la date du jour a bien été créé :

1 root@srv-filer:/# ls /backups/old-srv-1/
2 17-03-2018 18-03-2018
Et ce dernier comprend bien la sauvegarde des fichiers modifiés :

1 root@srv-filer:/# ls /backups/old-srv-1/18-03-2018/
2 test1.txt test2.txt test3.txt

Automatiser les sauvegardes

 Pour automatiser les sauvegardes, on passe simplement par le
fichier /etc/crontab.
Si vous avez des doutes quant à la syntaxe, prenez connaissance de
l’exemple suivant :

1 # Example of job definition:

2 # .---------------- minute (0 - 59)
3 # | .------------- hour (0 - 23)
4 # | | .---------- day of month (1 - 31)
5 # | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
6 # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
7#| | | | |
8 # * * * * * user command to be executed
Ainsi, pour une sauvegarde incrémentielle tous les dimanches à 05h00 du
matin, on procède comme suit :

root@srv-1:/# vi /etc/crontab
1
# m h dom mon dow command
2
00 5 * * 7 root rsync -auvHP --numeric-ids --delete --backup --backup-dir=/backups/old-srv-
3
1/$DATE/ root@192.168.0.10:/datas/ /backups/srv-1/

Archivage
Pour aller plus loin, si on veut gagner de la place, on peut procéder à un
archivage.

La compression des fichiers pourrait s’effectuer de la manière suivante :

1 root@srv-filer:/# tar -czvf /backups/srv-1.gz /backups/srv-1/

On peut par exemple inclure cette compression après la sauvegarde mise
dans la crontab (compression + suppression du répertoire) :
1 root@srv-filer:/# tar -czvf /backups/srv-1.gz /backups/srv-1/ && rm -R /backups/srv-1
Pour décompresser ensuite, on procède comme suit (-C définissant l’endroit
d’extraction) :

1 root@srv-filer:/# tar -xzvf /backups/srv-1.gz -C /backups/srv-1/

Étape 1 : créer un nouvel utilisateur Synology
Afin de bien séparer les processus et privilèges, il vaut mieux créer
un nouvel utilisateur Synology : cela permet de contrôler
exactement ce à quoi il a accès.
Dans ce tutoriel, notre utilisateur s'appellera saveme.
Étape 2 : activer l'accès SFTP
Activez l'accès SFTP dans Diskstation > Control Panel > FTP >
SFTP > Enable SFTP service. Vérifiez aussi que le port 22 (SSH)
est bien ouvert dans votre routeur et firewall; et bien redirigé vers
votre NAS.
Ensuite, ouvrez une session SSH sur votre NAS :

ssh admin@IP_NAS

Entrez votre mot de passe, vous devriez être loggué. Si ce n'est pas
le cas, vérifiez la configuration routeur/firewall du port 22.

Étape 3 : éditer le fichier passwd

Une fois que vous êtes identifié en SSH sur votre NAS, il vous faut
éditer le fichier passwd:
nano /etc/passwd

Allez à la dernière ligne, qui gère le nouvel utilisateur créé à l'étape

1. A la fin de cette ligne, remplacez :

/sbin/nologin

par

/bin/sh

Sauvegardez le fichier.

A lire : PHP : configurer un pool PHP pour chaque site

Maintenant, on assigne un dossier de travail avec tous les droits
nécessaires à notre utilisateur (qui s'appelle saveme). Au lieu de le
mettre dans /homes, on va plutôt le mettre à la racine, bien au
chaud, sous /volume1/backup.
On donne accès au dossier :

chown saveme:users /volume1/backup

Étape 4 : identification avec notre nouvel

utilisateur
On s'identifie avec notre utilisateur saveme :
su - saveme

Si vous obtenez des messages d'erreur comme :

su: can't chdir to home directory '/volume1/backup'

su: can't run /sbin/sh: No such file or directory

La première erreur est due à une erreur de permissions. Vérifiez

que vous avez bien chowné le bon dossier. La seconde montre que
vous avez oublié d'ajouter

/bin/sh

à votre utilisateur dans l'étape 3.

Étape 5 : ajouter la clé SSH du NAS sur le

serveur distant
On crée la clé en utilisant le chemin par défaut et on appuie juste
sur "entrée" lorsqu'on nous demande un mot de passe de clé :

ssh-keygen -t rsa

On copie la clé sur le serveur distant:

cat ~/.ssh/id_rsa.pub | ssh user@IP_SERVER "mkdir -p ~/.ssh && cat >>

~/.ssh/authorized_keys"
Essayez maintenant d'ouvrir une session SSH sur votre serveur
distant depuis la session SSH du NAS : la session devrait s'ouvrir
sans que vous n'ayez à entrer le mot de passe du compte.
Si vous obtenez une erreur de permission, voici les bonnes
permissions à appliquer :
 le répertoire .ssh doit avoir un chmod 700,

 la clé publique (fichier .pub) doit avoir un chmod 644,

 la clé privée (id_rsa) doit avoir un chmod 600.

A lire : Cron : résoudre l'erreur logrotate_script: 3: [: /var/run/mysqld/mysqld.pid:

unexpected operator

Voici donc les commandes à lancer pour attribuer les bonnes

permissions sur le NAS:

chmod /volume1/backup/.ssh 700

chmod /volume1/backup/.ssh/id_rsa.pub 644
chmod /volume1/backup/.ssh/id_rsa 600

Etape 6 : établir une structure et planifier les

sauvegardes
Commençons par créer des dossiers dans notre répertoire backup :
mkdir -p /volume1/backup/www
mkdir -p /volume1/backup/mysql
mkdir -p /volume1/backup/snapshots

Passons maintenant aux essais, avec une commande de test qui ne

copie rien (grâce à l'argument --dry-run) :
rsync --delete --stats -zav --dry-run user@example.com:/var/www/
/volume1/backup/www

Voilà ce que retourne la commande:

Number of files: 212521

Number of files transferred: 71
Total file size: 8981539430 bytes
Total transferred file size: 265780 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 5047457
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 171658
Total bytes received: 5300913

sent 171658 bytes received 5300913 bytes 142144.70 bytes/sec

total size is 8981539430 speedup is 1641.19 (DRY RUN)

Si vous obtenez une erreur de ce style:

rsync: failed to set times on "/volume1/backup/www/.": Operation not permitted (1)

alors, c'est un problème de permission : vérifiez que le dossier local

du NAS dans lequel vous voulez écrire est bien associé à
l'utilisateur qui lance la commande rsync (saveme dans notre
exemple pour le dossier backup).
Étape 7 : deux scripts BASH pour automatiser
les sauvegardes
Si tout va bien, nous allons créer deux scripts BASH à la racine de
notre dossier backup.
On commence par le fichier rsync.sh:
nano /volume1/backup/rsync.sh

et on y ajoute :

rsync --exclude /cache --delete --stats -zav root@example.com:/var/www/

/volume1/backup/www
rsync --delete --stats -zav root@example.com:/backups /volume1/backup/mysql

Cela nous permet de récupérer les fichiers du site et les bases de

données SQL.

A lire : Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les
plugins et les thèmes
Ensuite, on crée le fichier snapshot.sh:
nano /volume1/backup/snapshot.sh

et on y ajoute:

cd /volume1/backup/www; tar cvf /volume1/backup/snapshots/snapshot-$(date +%Y-%m-

%d).tgz *
find /volume1/backup/snapshots -mtime +120 -type f -exec rm -f '{}' \;

La première commande crée un fichier .tar du répertoire /www et le

place dans le dossier snapshots. La seconde trouve les archives
vieilles de plus de 120 jours et les supprime. Vous pouvez
également ajouter d'autres commandes snapshot pour les données
SQL.

Étape 8 : ajouter une tâche planifiée

Il ne vous reste plus qu'à ajouter les scripts dans un crontab pour
planifier les sauvegardes. Vous pouvez vous rendre
dans DiskStation > Panneau de configuration > Tâches
Planifiées et ajouter une nouvelle tâche exécutée par
l'utilisateur saveme et ajouter nos deux scripts:
/volume1/backup/rsync.sh
/volume1/backup/snapshot.sh