Utiliser Rsync pour sauvegarder un serveur Linux vers un NAS Synology

Dans ce tutoriel, nous allons voir comment configurer rsync pour planifier des sauvegardes d’un serveur distant et permettre l’accès SSH vers votre NAS Synology en local.

Armez-vous de votre terminal préféré et lancez une session SSH, c’est parti !

É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.

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.

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.

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

Voilà, bonnes sauvegardes !

Envie d'ajouter des fonctionnalités exceptionnelles à votre site WordPress ou WooCommerce? Je suis là pour vous aider.

Explorons les possibilités ensemble »

Articles conseillés :

2 pensées sur “Utiliser Rsync pour sauvegarder un serveur Linux vers un NAS Synology”

    • Salut Mohamed,

      C’est vrai que l’on aurait pu le faire dans ce sens aussi.

      Je le fais du serveur vers le syno parce que le syno n’est pas allumé en permanence et je préfère avoir tous mes scripts et crontabs sur le serveur, c’est plus simple pour moi à maintenir.

      Reply

Opinions