rsync vs scp — quelle commande de copie Linux, et quand

■ space · voie prose

LA LIGNE UNIQUE, ANNOTÉE

La plupart des gens n'ont besoin que de ça — chaque drapeau étiquetté, dans l'ordre :

la barre oblique finale piège tout le monde une fois — rsync va même prévenir « no bytes transferred » quand vous pensiez à l'autre forme

CE QUE LA DIFFÉRENCE D'ÉTAT ACHÈTE

scp fait une chose : ouvrir un canal SSH, streamer les octets, fermer. Aucun état entre deux runs, donc un transfert mort à 90 % repart de zéro et renvoie tout. rsync est un outil de synchronisation qui utilise SSH comme transport : avant d'envoyer, il construit une liste de checksums de la destination (l'algorithme rolling-checksum

• Interruptions : rsync reprend ; scp redémarre le fichier.
• Secondes copies : rsync n'envoie que les changements ; scp renvoie tout.
• Suppressions : rsync peut refléter les suppressions avec --delete ; scp ne peut pas.
• Filtrage : rsync a des motifs --exclude ; scp copie tout ce que vous visez.
• Simulations : rsync montre ce qu'il ferait avec --dry-run ; scp ne propose rien.

RSYNC EST-IL PLUS RAPIDE ?

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

1. Petits fichiers en masse. rsync pipeline les parcours de répertoires et peut réutiliser une connexion ; les vieux scp lançaient un process par fichier. Des milliers de petits fichiers — un node_modules, une install WordPress — finissent nettement plus vite avec rsync.
2. Re-runs. Copiez un fichier de 4,0 Go où 50 Mo ont changé et rsync déplace environ 50 Mo ; scp renvoie 4 Go.
3. Compression. -z compresse en vol, ce qui aide sur les liens WAN lents.

Vous pouvez chronométrer vous-même — la commande est identique en forme, et c'est le re-run qui donne la réponse :

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

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

L'INCANTATION DE REPRISE

Non, scp ne peut pas reprendre un transfert interrompu — pas de drapeau, pas d'astuce. Tout le design de rsync suppose que le transfert sera parfois interrompu :

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 ajoutant à la suite, puis vérifie par checksum la zone ajoutée — sûr contre un fichier partiel corrompu, contrairement à l'ancien --append.
simple.
• --progress vous montre où il a repris.

Enveloppé dans une boucle de retry, c'est une sauvegarde set-and-forget même sur une connexion hostile :

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

vérifiez : relancez le même rsync → il vérifie et n'envoie ~rien

QUAND SCP GAGNE ENCORE

• Un petit fichier, une fois. Taper scp app.conf user@host:/etc/myapp/ est plus court que toute invocation rsync, et il n'y a rien à reprendre.
• rsync est absent à l'autre bout. rsync exige son binaire des deux côtés. Beaucoup de conteneurs minimaux et d'appareils embarquent le serveur SFTP de scp mais pas rsync.
• Vous ne voulez pas d'un démon rsync exposé. Rare, mais certains environnements verrouillent spécifiquement le démon rsync.

Une subtilité à connaître : le projet OpenSSH a déprécié le protocole original de scp il y a des années, et le scp moderne parle en réalité SFTP dessous. Ça a corrigé une bizarrerie d'échappement de chemin, mais ça n'a rien changé aux deux limites qui comptent — pas de reprise, pas de transfert delta. Le changement de protocole ne fait pas de scp un rsync. Et si votre vraie question est « rsync vs cp » : cp est l'équivalent local-only de scp — pas de reprise, pas de delta, pas d'attributs sans drapeaux — et pour des one-shots locaux ça convient.

LE DANGEREUX

--delete reflète aussi les suppressions — il retire à la destination les fichiers partis de la source. Puissant pour des miroirs, dangereux ailleurs. Simulation d'abord :

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # relecture
rsync -avh --delete src/ user@server:/srv/dest/             # puis commit

vérifiez : la passe --dry-run imprime la liste des suppressions et ne change rien

Pour une synchro quotidienne ou hebdo, glissez rsync dans un timer systemd et laissez-le ne copier que les deltas — le journal est là où les runs laissent leur histoire.

LA TABLE DU VERDICT

Par défaut, rsync pour les sauvegardes, les gros arbres, tout ce qui passe par un lien qui peut couper, et tout ce que vous lancerez plus d'une fois. Utilisez scp quand la commande est un one-shot et que rien ne peut être interrompu — et ajoutez toujours --partial — ça transforme chaque future connexion coupée de redémarrage en pause.

fin de la page copie · rien de récupéré · tout est local