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_NASCode language: CSS (css)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/passwdAllez à la dernière ligne, qui gère le nouvel utilisateur créé à l’étape 1. A la fin de cette ligne, remplacez :
/sbin/nologinpar
/bin/shSauvegardez 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 - savemeSi 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 directoryCode language: PHP (php)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 rsaOn copie la clé sur le serveur distant:
cat ~/.ssh/id_rsa.pub | ssh user@IP_SERVER "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"Code language: JavaScript (javascript)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
.sshdoit 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 600Etape 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/snapshotsPassons 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/wwwCode language: JavaScript (javascript)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)Code language: PHP (php)Si vous obtenez une erreur de ce style:
rsync: failed to set times on "/volume1/backup/www/.": Operation not permitted (1)Code language: JavaScript (javascript)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.shet 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/mysqlCode language: JavaScript (javascript)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.shet 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 '{}' \;Code language: JavaScript (javascript)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.shVoilà, bonnes sauvegardes !
Rencontrez-vous des défis avec votre site WordPress ou WooCommerce? Laissez-moi les résoudre pour vous.
Salut,
pourquoi ne pas utiliser le service rsync présent sur le syno ?
Cdl.
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.