rsync Ubuntu - Le guide complet pour une synchronisation parfaite

Synchroniser des fichiers avec rsync sur Ubuntu, c’est surtout choisir un outil qui copie vite, limite le trafic réseau et garde le contrôle sur ce qui change vraiment. Pour un poste de travail, un serveur applicatif ou une arborescence de déploiement, c’est souvent plus fiable qu’un simple cp et plus souple qu’un script maison. Dans cet article, je montre comment l’utiliser proprement, quelles options font la différence et où se cachent les pièges qui cassent une synchronisation.

Pourquoi rsync reste mon outil de base sous Ubuntu

Je l’utilise surtout quand je veux synchroniser un répertoire source vers une destination sans recopier inutilement tout ce qui n’a pas changé. Le cœur de l’outil repose sur un algorithme de transfert différentiel : rsync compare les fichiers, détecte ceux qui ont changé puis n’envoie que les différences utiles. C’est exactement ce qui le rend pertinent pour les sauvegardes, les miroirs et les déploiements continus.

Ce qui me plaît aussi, c’est sa souplesse. rsync peut copier en local, vers un autre hôte via ssh, ou dialoguer avec un daemon rsync quand ce mode est vraiment justifié. En revanche, il ne copie pas directement d’un hôte distant vers un autre hôte distant sans passer par la machine locale, donc je le réserve aux flux où j’ai un vrai point de contrôle clair.

• Pour un miroir, il maintient une destination alignée sur la source.
• Pour un déploiement, il met à jour seulement les artefacts modifiés.
• Pour une sauvegarde, il permet des copies incrémentales très efficaces.
• Pour un flux bidirectionnel, je ne le prends pas comme première option.

Autrement dit, rsync répond très bien à un besoin de synchronisation unidirectionnelle, mais il ne remplace pas un vrai outil de synchronisation bidirectionnelle quand les deux côtés peuvent évoluer en même temps. Une fois ce cadre posé, le vrai sujet devient la préparation de la machine et des accès.

Préparer la machine avant la première synchronisation

Sur Ubuntu, l’installation tient en une seule ligne, mais je ne m’arrête jamais là. Je vérifie la version, l’accès réseau et les droits d’écriture avant de lancer la moindre copie, parce qu’une commande correcte sur une machine mal préparée reste une mauvaise opération.

sudo apt update
sudo apt install rsync
rsync --version
ssh user@serveur

Si je synchronise vers un hôte distant, j’installe aussi une authentification SSH par clé. C’est plus propre qu’un mot de passe saisi à chaque exécution, et surtout plus compatible avec une tâche planifiée.

ssh-copy-id user@serveur

Je fais également attention au niveau de privilèges. Le mode archive -a essaie de préserver beaucoup de choses, mais certaines informations comme le propriétaire ou le groupe ne sont réellement conservées que si les droits le permettent. Quand je n’ai pas besoin de ces attributs, je les désactive explicitement avec --no-o et --no-g pour éviter de croire à une conservation qui ne se fera pas vraiment.

Une fois ce socle en place, les commandes deviennent beaucoup plus lisibles.

Les commandes qui couvrent la plupart des cas

Quand j’écris un déploiement ou une sauvegarde simple, je pars presque toujours d’une variante de rsync -avh. Le mode archive -a correspond à -rlptgoD : récursivité, liens symboliques, permissions, temps, groupe, propriétaire et périphériques spéciaux. En pratique, c’est un bon point de départ, mais il ne couvre pas les ACL, les attributs étendus, les temps d’accès, les dates de création ni les hard links.

• -n lance un test à blanc. Je l’active presque systématiquement avant un premier vrai transfert.
• -i affiche ce qui change réellement. C’est la meilleure façon de lire un delta sans deviner.
• -P équivaut à --partial --progress. C’est utile sur un transfert long ou interrompu.
• -z compresse les données pendant le transfert. Je l’emploie surtout quand le réseau est le goulot d’étranglement.
• --checksum compare un checksum au lieu de se fier uniquement à la taille et à l’heure. Je ne l’active que si les timestamps ne sont pas fiables, car il faut relire beaucoup plus de données.

rsync -avh -i -n --delete -e ssh ./build/ deploy@prod:/var/www/app/

La logique de cette commande est simple : je simule d’abord, je lis l’itemization, puis je retire -n seulement quand le résultat est cohérent. Les options sont courtes, mais elles deviennent dangereuses si je ne sais pas exactement ce qu’elles font ensemble.

La barre oblique finale et les exclusions qui changent tout

Le détail qui piège le plus souvent les débutants, c’est la barre oblique finale. rsync -a src/ dest/ copie le contenu de src dans dest, alors que rsync -a src dest/ crée dest/src et y met le dossier entier. Pour une synchronisation, ce n’est pas un détail cosmétique : c’est la différence entre une arborescence propre et un sous-dossier de trop.

Je préfère aussi écrire mes exclusions de manière explicite. Dans un projet web, j’exclus souvent node_modules/, dist/, .git/ et les journaux, parce que ce sont des répertoires lourds ou non pertinents pour la destination.

rsync -avh --exclude='node_modules/' --exclude='dist/' --exclude='.git/' ./app/ backup:/srv/app/

Le point critique, c’est l’interaction entre exclusions et suppression. Avec --delete, rsync supprime sur la destination ce qui n’existe plus à la source, mais il faut d’abord tester avec --dry-run. Si je veux comprendre ce qui va bouger avant d’écraser quoi que ce soit, j’ajoute -i et je lis la sortie ligne par ligne.

Quand l’horodatage n’est pas fiable, par exemple sur certains montages ou sur des systèmes de fichiers à résolution différente, je teste aussi --modify-window=1. C’est plus propre que de forcer des réexpéditions inutiles, mais je ne l’active que si j’ai identifié un vrai problème de comparaison de dates. Une fois ces règles maîtrisées, la synchronisation devient plus prévisible, ce qui est exactement ce qu’on veut avant d’automatiser.

Automatiser une synchronisation sans créer un incident

Quand la synchronisation devient récurrente, j’écris un script court plutôt qu’une ligne de commande opaque dans cron. L’idée n’est pas de faire joli, mais de garder un point d’entrée stable, des logs lisibles et un comportement que je peux rejouer à la main en cas de doute.

#!/usr/bin/env bash
set -euo pipefail

SRC="/srv/app/"
DEST="backup@nas:/backups/app/"
LOG="/var/log/rsync-app.log"

rsync -a -i --delete --partial --delay-updates -e ssh \
  "$SRC" "$DEST" | tee -a "$LOG"

Je garde trois habitudes dans ce genre de script. D’abord, je commence par un test à blanc avant le premier passage réel. Ensuite, j’évite de faire dépendre la commande d’arguments trop nombreux ou trop implicites. Enfin, je sépare le réglage de la synchronisation de sa planification, parce qu’un bon systemd timer ou un cron lisible vaut mieux qu’une magie de shell impossible à relire deux mois plus tard.

• --delay-updates réduit le risque qu’une application voie des fichiers à moitié copiés.
• --partial conserve les transferts interrompus, ce qui évite de repartir de zéro.
• tee -a me donne un journal exploitable sans perdre la sortie console.
• Un compte de service dédié limite les dégâts si la tâche planifiée se trompe.

Si je dois livrer une arborescence de production, je préfère encore ce type de script simple à une chaîne de commandes dispersées. Le prochain niveau de prudence, c’est de verrouiller les droits et la surface d’attaque.

Sécuriser les transferts distants et les droits

Je réserve le mode daemon aux cas où il y a une vraie raison de l’utiliser. Dans la plupart des flux de déploiement et de sauvegarde, ssh suffit largement, protège le trafic et évite d’exposer un service de plus. Quand je dois écrire dans un répertoire appartenant à root à distance, j’utilise parfois --rsync-path='sudo rsync', mais seulement avec un compte limité et des règles sudoers très ciblées.

• Je préfère une clé SSH dédiée à un mot de passe interactif.
• Je limite le compte de service au répertoire cible et à rien d’autre.
• Je place --partial-dir dans un emplacement sûr, jamais dans un répertoire partagé en écriture comme /tmp.
• Je n’active --delete qu’après un test à blanc validé.
• Je garde le paquet rsync à jour, surtout sur les serveurs exposés.

Quand j’applique ces règles, je réduis fortement le risque d’écraser la mauvaise arborescence, de publier un transfert incomplet ou d’exposer un service inutile. Il reste alors une dernière question utile : rsync est-il vraiment le bon outil pour ce que je veux faire, ou seulement le plus familier ?

Le bon choix quand rsync n’est pas suffisant

Je garde rsync comme mon outil de base pour la synchronisation unidirectionnelle, les déploiements et les miroirs, mais je sais aussi quand je dois m’arrêter. Si le besoin devient bidirectionnel, je regarde plutôt un outil conçu pour cela, parce qu’un aller-retour de fichiers n’a pas les mêmes risques qu’une simple copie de source vers destination.

• Pour une synchronisation à sens unique, rsync reste très difficile à battre.
• Pour une copie bidirectionnelle, je m’oriente vers un outil comme Unison ou Syncthing.
• Pour une sauvegarde versionnée, je préfère une solution pensée pour les snapshots et la rétention.
• Pour un déploiement rapide, rsync est excellent si la cible est préparée et les exclusions sont propres.

Mon réflexe final est simple : je teste avec --dry-run, je valide les exclusions, puis je n’active la suppression qu’en dernière étape. Si la tâche doit vivre dans le temps, je la mets dans un script lisible, avec des droits limités et des logs clairs. C’est cette discipline, plus que l’outil lui-même, qui fait la différence entre une synchronisation fiable et un incident évitable.