Rsync vs scp : quelle commande de copie sous Linux ?

Prends rsync pour tout ce qui dépasse la copie rapide et ponctuelle, et scp quand tu veux juste un fichier sur une autre machine, maintenant. La différence de fond : scp renvoie le fichier entier à chaque fois et n'a aucune mémoire d'une connexion tombée, tandis que rsync compare la source et la destination, ne transfère que les blocs modifiés et reprend une copie interrompue là où elle s'était arrêtée. Sur une grosse sauvegarde via une liaison capricieuse, c'est l'écart entre deux minutes et tout recommencer. Les deux sont livrés avec OpenSSH sur quasiment toutes les distributions Linux : le choix est une question d'habitude, pas d'installation — et l'habitude devrait être rsync par défaut. Ci-dessous : un tableau comparatif sans détour, les écarts de vitesse réels, l'astuce de reprise que scp ne sait pas faire et les cas où scp reste la bonne réponse.

Quelle est la différence entre rsync et scp ?

scp fait une chose : ouvrir un canal SSH, streamer les octets, fermer. Il n'a aucun état entre deux exécutions, donc si le transfert meurt à 90 %, tu repars de zéro.

rsync est un outil de synchronisation qui utilise SSH comme simple transport. Avant d'envoyer, il construit une liste de sommes de contrôle du fichier côté destination (l'algorithme delta à checksum glissant) et ne transmet que les blocs qui diffèrent. Relance la même commande deux fois : le second passage ne déplace presque rien. C'est aussi ce qui fait de rsync l'outil naturel pour garder deux dossiers synchronisés — planifie-le et chaque exécution ne copie que les deltas.

Les conséquences pratiques :

Interruptions : rsync reprend ; scp redémarre le fichier.
Deuxièmes copies : rsync n'envoie que les changements ; scp renvoie tout.
Suppressions : rsync peut répliquer les suppressions avec --delete ; scp ne peut pas.
Filtrage : rsync a les motifs --exclude ; scp copie tout ce que tu lui donnes.
Simulation : rsync montre ce qu'il ferait avec --dry-run ; scp ne propose rien.

Rsync est-il plus rapide que scp ?

Pour une première copie d'un gros fichier sur un lien rapide, ils sont au coude à coude — les deux saturent SSH, et la passe de checksum n'ajoute qu'un faible surcoût. L'écart se creuse à trois endroits :

Petits fichiers en masse. rsync met en pipeline le parcours des dossiers et peut réutiliser une seule connexion ; les anciennes configurations de scp lançaient un travail par fichier. Des milliers de petits fichiers (un node_modules, une installation WordPress) terminent sensiblement plus vite avec rsync.
Ré-exécutions. Copie un fichier de 4 Go dont 50 Mo ont changé : rsync déplace environ 50 Mo ; scp renvoie 4 Go.
Compression. -z compresse en vol, ce qui aide sur les liens WAN lents.

Tu peux chronométrer les deux toi-même — la commande est identique dans sa forme :

# même fichier, même serveur, les deux en SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# relance les deux : scp recopie, rsync vérifie et n'envoie presque rien
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

Si tu passes tes journées sur des serveurs, la vitesse de transfert fait partie des choses à mesurer une fois — de la même façon que ss bat netstat sur les hôtes chargés (voir ss vs netstat : quelle commande de ports utiliser sous Linux).

scp peut-il reprendre un transfert interrompu ?

Non. scp n'a pas de reprise ; si la connexion tombe à 900 Mo sur 1 Go, tu recommences. C'est l'argument le plus cité de tous les débats rsync-vs-scp, et il est réel.

Tout le design de rsync suppose que le transfert sera interrompu de temps en temps. L'incantation canonique de reprise :

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

--partial garde le fichier à moitié écrit au lieu de le supprimer.
--append-verify reprend en annexant, puis vérifie par checksum la région annexée — protégé contre un fichier partiel corrompu, contrairement à l'ancien --append simple.
--progress te montre où il a repris.

Enveloppé dans une boucle de retry, cela donne une sauvegarde qu'on oublie, même sur une liaison hostile :

until rsync -avh --partial --append-verify --progress \
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

Quand utiliser scp plutôt que rsync ?

scp reste le bon outil dans une poignée de cas :

Un petit fichier, une fois. Taper scp app.conf user@host:/etc/myapp/ est plus court que n'importe quelle invocation rsync, et il n'y a rien à reprendre.
rsync absent sur la machine distante. rsync a besoin de son binaire des deux côtés. Beaucoup de conteneurs minimaux et d'appliances embarquent le serveur SFTP de scp mais pas rsync.
Tu ne veux pas exposer un serveur rsync. Rare, mais certains environnements verrouillent spécifiquement le daemon rsync.

Une subtilité à connaître : le projet OpenSSH a déprécié le protocole d'origine de scp il y a des années, et le scp moderne parle en réalité SFTP sous le capot. Cela a corrigé une bizarrerie d'échappement de chemin, mais n'a rien changé aux deux limites qui comptent ici — pas de reprise, pas de transfert delta. Le changement de protocole ne transforme pas scp en rsync.

Dans la même veine : si ta vraie question est « rsync vs cp », la réponse suit la même logique — cp est l'équivalent local de scp (pas de reprise, pas de delta, pas d'attributs sans options), et rsync marche en local comme à distance. Pour un one-shot local, cp convient.

Quelles options rsync comptent vraiment ?

La plupart des gens n'ont besoin que d'une ligne :

rsync -avh --partial --progress src/ user@server:/srv/dest/

Option	À quoi elle sert
`-a` (archive)	Récursif + préserve permissions, dates, groupe, symlinks, devices
`-v` (verbose)	Liste ce qu'il transfère
`-h` (human)	Tailles lisibles
`--partial`	Garde les fichiers partiellement transférés, pour qu'une relance reprenne
`--progress`	Progression par fichier — ce que scp n'a jamais eu
`-z`	Compresse en vol (CPU lent sur LAN rapide : oublie)
`--delete`	Réplique aussi les suppressions — dangereux, toujours avec un dry run
`--dry-run` (-n)	Montre ce qui se passerait, ne change rien

Deux habitudes à prendre. D'abord, simuler tout ce qui contient --delete :

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # on vérifie
rsync -avh --delete src/ user@server:/srv/dest/             # puis on valide

Ensuite, attention au slash final — /srv/src copie le dossier lui-même dans la destination, tandis que /srv/src/ copie son contenu. Ça piège tout le monde une fois ; rsync va jusqu'à prévenir « no bytes transferred » quand tu pensais à l'autre forme.

Pour une synchro quotidienne ou hebdomadaire, mets rsync dans un timer systemd et laisse-le ne copier que les deltas — le côté journalctl de l'ordonnancement est couvert dans l'aide-mémoire journalctl.

Rsync vs scp : le verdict

	scp	rsync
Livré avec OpenSSH	Oui	Oui (les deux bouts requis)
Reprendre un transfert interrompu	Non	Oui (`--partial`)
Transfert delta à la relance	Non	Oui
Préserve permissions/symlinks	En partie	Complètement (`-a`)
Motifs d'exclusion	Non	`--exclude`
Dry run	Non	`--dry-run`
Répliquer les suppressions	Non	`--delete`
Idéal pour	Copies rapides ponctuelles	Sauvegardes, synchros, grosses arborescences

rsync par défaut pour les sauvegardes, les grosses arborescences, tout ce qui passe par un lien qui peut tomber et tout ce que tu lanceras plus d'une fois. scp quand la commande est plus courte que la pensée. Une seule option à retenir ? --partial : elle transforme chaque future connexion perdue, d'un redémarrage en simple pause.