Quand on administre deux serveurs Linux, il y a vite un besoin très concret qui revient: copier des fichiers sans tout retransférer à chaque fois. C’est là que rsync devient vraiment utile. L’outil existe depuis longtemps, il n’a rien de spectaculaire dans sa forme, mais il rend des services énormes dès qu’on doit synchroniser un répertoire web, répliquer des sauvegardes ou envoyer des fichiers de logs vers une autre machine.
Son intérêt principal tient dans sa manière de travailler. Rsync compare la source et la destination, puis n’envoie que ce qui a changé. Sur un gros volume de données, la différence est immédiate. On gagne du temps, de la bande passante et, franchement, pas mal de tranquillité quand on doit automatiser ça la nuit avec cron ou systemd timers.
Si vous gérez aussi des accès distants et des transferts sécurisés, vous pouvez prolonger le sujet avec cet article sur la copie de fichiers entre machines Linux. Et pour rester dans les usages concrets côté administration, ce billet sur les commandes Linux utiles au quotidien complète bien la logique.
Contenu
À quoi sert rsync au quotidien
# synchroniser un dossier vers un autre serveur rsync -avz /var/www/ user@serveur2:/var/www/ # sauvegarde avec suppression des fichiers effacés côté source rsync -av --delete /data/ backup@serveur2:/backups/data/
Dans la vraie vie, rsync sert rarement pour faire joli. On l’utilise parce qu’on a un besoin simple: garder deux emplacements cohérents sans recopier bêtement l’ensemble. Typiquement, un serveur de production envoie chaque nuit une sauvegarde vers un second serveur. Autre cas classique, un développeur pousse un répertoire d’application vers une machine distante en excluant les fichiers temporaires. On le voit aussi dans les migrations, par exemple pour déplacer un site volumineux sans couper le service trop longtemps.
La commande de base ressemble à ceci:
rsync -avz /source/ user@serveur-distant:/destination/
Le -a conserve les permissions, dates et liens symboliques. Le -v affiche le détail des opérations. Le -z compresse les données pendant le transfert, ce qui peut être utile sur un lien lent. Dans la plupart des environnements, on l’associe à SSH pour éviter de transférer des données en clair.
Comment synchroniser des fichiers entre deux serveurs
Le plus simple consiste à lancer rsync depuis le serveur source vers le serveur cible. Par exemple, pour synchroniser un dossier de sauvegarde:
rsync -av /var/backups/ admin@192.0.2.10:/srv/backups/
Le slash final a son importance. /var/backups/ signifie qu’on copie le contenu du dossier. Sans ce slash, on copie le dossier lui-même dans la destination. C’est un détail qui semble mineur jusqu’au jour où l’arborescence d’arrivée n’est plus celle qu’on attendait.
Pour passer par SSH avec une clé précise ou un port non standard, on peut faire:
rsync -av -e "ssh -p 2222 -i /root/.ssh/id_rsa" /data/ backup@serveur2:/data/
Cette approche est propre pour les scripts automatisés. Elle évite les mots de passe interactifs et s’intègre bien dans une routine de sauvegarde. Si vous devez d’abord tester sans rien modifier, ajoutez --dry-run. C’est probablement l’option la plus rassurante de tout l’outil, parce qu’elle montre ce que rsync ferait sans toucher aux fichiers.
Les options qui font vraiment la différence
# simulation avant exécution réelle rsync -avzn --delete /data/ backup@serveur2:/backups/data/
Au-delà de la base, quelques options changent clairement la manière de travailler. --progress permet de suivre l’avancement, ce qui est appréciable sur un gros transfert. --exclude évite d’embarquer des caches, des dossiers Git ou des fichiers temporaires. --bwlimit limite la bande passante si vous ne voulez pas saturer un lien partagé avec d’autres services.
Pour une sauvegarde plus fidèle, beaucoup utilisent aussi --numeric-ids quand les UID et GID doivent rester strictement identiques entre les deux serveurs. Dans certains contextes, --delete entre également en jeu, mais c’est une option qui mérite un minimum de respect. J’y reviens juste après, parce qu’elle peut rendre service aussi vite qu’elle peut faire disparaître des fichiers.
Il y a aussi un duo très pratique pour les sauvegardes incrémentales artisanales: --link-dest et les liens matériels. Ce n’est pas toujours nécessaire, mais sur un serveur de backup, cela permet de conserver plusieurs états d’un répertoire sans dupliquer physiquement tous les fichiers inchangés.
Pourquoi il faut être prudent avec –delete
--delete indique à rsync de supprimer, côté destination, les fichiers qui n’existent plus côté source. Sur le papier, c’est logique: si l’on veut une vraie synchronisation, la destination doit refléter la source. En pratique, c’est aussi la meilleure façon d’effacer un contenu utile si l’on s’est trompé de répertoire ou si la source n’est pas dans l’état attendu.
Un exemple simple: vous pensez synchroniser /var/www/site/, mais vous pointez par erreur vers un dossier vide. Avec --delete, rsync peut très bien nettoyer la destination pour la rendre conforme à ce dossier vide. Ce n’est pas un bug, c’est exactement ce qu’on lui a demandé.
La bonne habitude consiste à tester d’abord avec --dry-run, à relire la source et la destination, puis à activer --delete seulement quand le scénario est clair. Beaucoup d’admins préfèrent aussi journaliser les exécutions pour garder une trace des suppressions et repérer immédiatement un comportement anormal.
Des usages réels en administration Linux
Rsync est très à l’aise dans plusieurs situations concrètes. Pour un serveur web, il peut envoyer chaque nuit une copie des fichiers statiques vers une machine de secours. Pour une base de fichiers utilisateurs, il permet de répliquer régulièrement les documents sur un stockage distant. Dans un contexte de supervision, il peut aussi centraliser des logs ou des exports générés par différents serveurs.
On le croise souvent dans des scripts simples mais robustes. Un cron lance une synchronisation à 2 h du matin, écrit le résultat dans un fichier log, puis envoie une alerte seulement en cas d’erreur. Ce n’est pas l’outil le plus moderne du monde, mais il reste très bon pour faire un travail précis sans complexité inutile.
Autre usage intéressant, la préparation d’une migration. On lance un premier rsync plusieurs jours avant le basculement, puis un second juste avant la coupure pour transférer uniquement les derniers changements. Cela réduit fortement la fenêtre d’interruption et évite de recopier plusieurs centaines de gigaoctets au dernier moment.
Quand un outil dure aussi longtemps dans les environnements Linux, ce n’est généralement pas un hasard. Rsync reste là parce qu’il répond à un besoin concret, avec une logique simple: transférer seulement ce qui doit l’être, garder la main sur les options, et pouvoir automatiser le tout sans transformer une tâche banale en usine à gaz.