Transférer des fichiers entre deux serveurs avec SCP ou Rsync

Le transfert fichiers SCP Rsync répond à deux besoins distincts : SCP convient à une copie ponctuelle via SSH, tandis que Rsync sert à synchroniser des dossiers de façon incrémentale, avec reprise partielle et filtres. Pour envoyer un fichier unique, SCP est direct ; pour mettre à jour régulièrement un répertoire, Rsync évite de retransférer les fichiers inchangés.

SCP et Rsync s’appuient généralement sur SSH pour chiffrer le transport et authentifier la connexion. Ce guide montre comment préparer les deux serveurs, lancer des commandes adaptables, conserver les attributs utiles, limiter les erreurs de chemin ou de droits, puis vérifier le résultat sans confondre synchronisation et sauvegarde.

Comprendre le transfert de fichiers entre serveurs

Un transfert de fichiers entre serveurs consiste à envoyer ou récupérer des données entre deux machines accessibles sur un réseau. SCP est une commande de copie sécurisée qui utilise SSH, alors que Rsync est un outil de synchronisation qui compare une source et une destination. Les deux outils se pilotent depuis un terminal Linux ou Unix, avec un compte autorisé sur la machine distante.

La différence entre SCP et Rsync se voit surtout au deuxième transfert. SCP recopie les fichiers explicitement demandés, même lorsqu’ils existent déjà à destination. Rsync examine les deux arborescences et limite normalement les échanges aux fichiers nouveaux ou modifiés. Ce mécanisme est particulièrement utile pour des déploiements, des sauvegardes de travail ou des migrations par étapes.

Le bon choix ne dépend pas seulement du volume : une copie unique et une synchronisation récurrente ne posent pas le même problème technique.

Préparer les serveurs avant le transfert

Avant de copier un fichier entre deux serveurs, vérifiez quatre points : le nom d’hôte ou l’adresse du serveur cible, le compte distant, le chemin de destination et le port SSH. Une commande correcte ne peut pas compenser un accès SSH absent, un répertoire inexistant ou des droits insuffisants.

Les exemples suivants emploient des noms fictifs, comme [email protected], afin de ne pas exposer d’identifiants réels. Remplacez-les par le compte et le nom d’hôte autorisés dans votre infrastructure. Évitez le compte administrateur lorsque le transfert peut être réalisé avec un compte dédié disposant des droits minimaux nécessaires.

Étape 1 : vérifier les outils disponibles

Contrôlez la présence des commandes sur le serveur depuis lequel vous lancez l’opération. Sur de nombreuses distributions Linux, scp est fourni par le paquet client OpenSSH ; Rsync doit être installé sur les deux machines pour une synchronisation distante.

scp -V
rsync --version

Le résultat attendu est l’affichage d’une version ou d’une aide. Si le terminal répond que la commande est introuvable, installez le paquet correspondant via le gestionnaire de paquets de votre distribution, puis consultez la documentation officielle de votre environnement.

Étape 2 : tester la connexion SSH

Testez d’abord la connexion sans lancer de copie. La commande suivante ouvre une session SSH sur le second serveur avec le compte indiqué.

ssh [email protected]

Le résultat attendu est une invite de commande distante ou une demande d’authentification. Une empreinte de clé d’hôte inconnue doit être vérifiée par un canal fiable avant validation : elle identifie le serveur SSH auquel vous vous connectez.

Étape 3 : créer ou identifier le répertoire cible

Préparez le dossier de destination avant le transfert. Un chemin absolu, qui commence par /, réduit les ambiguïtés liées au répertoire courant du compte distant.

ssh [email protected] "mkdir -p /home/admin/reception"

Le résultat attendu est la création du dossier /home/admin/reception si le compte distant possède les droits nécessaires. La commande mkdir -p ne supprime ni ne remplace les fichiers déjà présents.

• Utilisez des chemins absolus pour les dossiers de production ou d’archivage.
• Vérifiez l’espace disque disponible sur le serveur de destination avant un gros transfert.
• Confirmez que le compte distant peut écrire dans le dossier choisi.
• Conservez une copie indépendante lorsque les données ont une valeur de sauvegarde.

Comment copier un fichier entre deux serveurs avec SCP ?

SCP copie un fichier entre deux emplacements en utilisant la syntaxe utilisateur@hôte:chemin pour la partie distante. Lancez SCP depuis le serveur qui possède la source, ou depuis votre poste d’administration si les accès SSH sont disponibles. Pour un dossier complet, ajoutez -r.

La syntaxe générale de la commande SCP Linux est scp [options] source destination. Le caractère : après le nom d’hôte est essentiel : sans lui, le terminal interprète souvent la destination comme un chemin local. La page de manuel scp d’OpenSSH détaille les options disponibles selon l’implémentation installée.

Étape 4 : envoyer un fichier vers le second serveur

Depuis le serveur A, envoyez le fichier local rapport.csv vers le dossier préparé sur le serveur B.

scp /srv/export/rapport.csv [email protected]:/home/admin/reception/

Le résultat attendu est la présence de rapport.csv dans /home/admin/reception/ sur le serveur B. SCP écrase un fichier de même nom à destination sans demander de confirmation : contrôlez donc le nom cible avant l’exécution.

Étape 5 : récupérer un fichier depuis un serveur distant

Pour rapatrier un fichier, inversez simplement la source et la destination. La partie distante reste écrite sous la forme utilisateur@hôte:chemin.

scp [email protected]:/home/admin/reception/rapport.csv /srv/archives/

Le résultat attendu est la copie de rapport.csv dans le dossier local /srv/archives/. Vérifiez que le répertoire local existe avant la commande, sinon SCP renverra une erreur de chemin ou placera le fichier ailleurs que prévu selon la syntaxe utilisée.

Étape 6 : transférer un dossier avec SCP

Pour transférer un dossier avec SCP, l’option récursive -r est obligatoire. La commande suivante copie l’arborescence locale /srv/site vers le serveur distant.

scp -r /srv/site [email protected]:/home/admin/reception/

Le résultat attendu est un dossier site sous /home/admin/reception/. Pour conserver les dates et modes de fichiers lorsque cela est nécessaire, l’option -p de SCP demande la préservation des dates de modification et des permissions ; ne la confondez pas avec -P, en majuscule, qui désigne le port SSH.

Étape 7 : utiliser un port SSH personnalisé

Quand le serveur SSH écoute sur un port différent du port configuré par défaut, indiquez-le avec -P en majuscule. Le port ci-dessous est un exemple fictif : adaptez la valeur à votre configuration réelle.

scp -P 2222 /srv/export/rapport.csv [email protected]:/home/admin/reception/

Le résultat attendu est le même transfert via le port sélectionné. L’option -p minuscule a un autre rôle : elle préserve des attributs de fichiers. Cette différence de casse est une erreur fréquente dans les commandes SCP.

Comment synchroniser deux serveurs avec Rsync ?

Rsync synchronise un dossier source et un dossier cible en comparant leurs contenus. La commande Rsync Linux est adaptée aux transferts répétés, car elle évite normalement de recopier les fichiers inchangés. Avec SSH comme transport, elle conserve le chiffrement et l’authentification déjà configurés entre les serveurs.

Le mode archive -a réalise une copie récursive et préserve la plupart des attributs courants, notamment les permissions, dates et liens symboliques. La documentation du projet Rsync précise les comportements de chaque option, qui peuvent varier selon la version installée.

Étape 8 : synchroniser le contenu d’un dossier vers un serveur distant

Ajoutez une barre oblique finale à la source lorsque vous souhaitez copier le contenu du dossier, et non créer un dossier parent supplémentaire dans la destination.

rsync -av /srv/site/ [email protected]:/var/www/site/

Le résultat attendu est la synchronisation du contenu de /srv/site/ dans /var/www/site/. Sans la barre oblique finale après /srv/site, Rsync copie généralement le répertoire site lui-même dans la destination ; ce détail change la structure finale.

Étape 9 : afficher la progression et limiter la bande passante

Ajoutez --info=progress2 pour suivre la progression globale d’un transfert. L’option --bwlimit limite le débit utilisé par Rsync afin de ne pas saturer une liaison partagée.

rsync -av --info=progress2 --bwlimit=5000 /srv/site/ [email protected]:/var/www/site/

Le résultat attendu est l’affichage d’une progression globale, avec une consommation réseau plafonnée selon la valeur choisie. Définissez une limite cohérente avec votre réseau et vos services en production ; une valeur trop basse allonge le transfert, tandis qu’une absence de limite peut gêner d’autres usages.

Étape 10 : exclure des fichiers et reprendre après une interruption

Les exclusions empêchent l’envoi de dossiers non nécessaires, comme des caches ou des fichiers temporaires. L’option --partial-dir conserve les données partielles dans un répertoire dédié afin qu’une relance puisse reprendre le travail, là où SCP ne propose pas de reprise automatique équivalente.

rsync -av --info=progress2 --partial-dir=.rsync-partial --exclude='cache/' --exclude='*.tmp' /srv/site/ [email protected]:/var/www/site/

Le résultat attendu est le transfert des fichiers utiles, sans le dossier cache/ ni les fichiers terminant par .tmp. Relancez exactement la même commande après une coupure : Rsync réévalue la destination et réutilise les données partielles lorsque les conditions le permettent.

Avant une synchronisation importante, une simulation Rsync révèle les fichiers concernés sans écrire sur la destination.

Étape 11 : simuler avant de synchroniser

Ajoutez --dry-run pour examiner les opérations prévues. Cette étape est particulièrement utile avant d’ajouter une exclusion, de modifier un chemin ou d’utiliser une option de suppression.

rsync -av --dry-run /srv/site/ [email protected]:/var/www/site/

Le résultat attendu est une liste d’actions sans transfert réel. Retirez --dry-run seulement après avoir vérifié les chemins affichés et la direction de la synchronisation.

• -a : copie récursive en mode archive, avec préservation d’attributs courants.
• -v : affiche les fichiers traités.
• -z : compresse les données pendant le transfert.
• --exclude : retire un motif ou un dossier de la synchronisation.
• --partial-dir : conserve les transferts incomplets dans un dossier séparé.

SCP ou Rsync : quelle méthode choisir ?

SCP est à privilégier pour une copie ponctuelle simple, notamment lorsqu’un fichier ou un dossier doit être envoyé une seule fois. Rsync est préférable pour synchroniser deux serveurs, déployer un arbre de fichiers ou reprendre un transfert interrompu. Les deux outils utilisent SSH, mais Rsync demande sa présence sur les deux machines.

Les performances ne se résument pas à une règle absolue. Une destination vide et un transfert initial complet peuvent rendre SCP parfaitement adapté. Rsync apporte surtout un avantage lors des transferts répétés, car la comparaison source-destination réduit les données envoyées lorsque seule une partie du contenu a changé.

Critère	SCP	Rsync	Choix pratique
Usage principal	Copie directe	Synchronisation de répertoires	SCP pour un envoi unique
Fichiers inchangés	Recopiés s’ils sont demandés	Évités lors des synchronisations suivantes	Rsync pour mises à jour répétées
Reprise après interruption	Pas de reprise automatique	Possible avec --partial-dir	Rsync pour transfert long
Répertoire complet	-r	-a	Rsync si les attributs comptent
Prérequis distant	Serveur SSH	SSH et Rsync installé	SCP si Rsync est indisponible

Une troisième alternative existe pour un besoin d’accès interactif aux fichiers : SFTP permet de parcourir et manipuler des fichiers via SSH, mais ne remplace pas la logique de synchronisation incrémentale de Rsync. Pour le besoin précis de copier des fichiers vers un serveur distant en ligne de commande, SCP et Rsync restent les outils les plus directs.

Sécuriser un transfert sécurisé par SSH

Un transfert sécurisé par SSH protège les données pendant leur transit, mais la sécurité dépend aussi du compte, des clés, des droits de fichiers et de la vérification de l’hôte distant. Le chiffrement du canal ne remplace ni une gestion rigoureuse des accès ni une sauvegarde indépendante des données transférées.

Préférez l’authentification par clé SSH à la saisie répétée d’un mot de passe, surtout pour une synchronisation récurrente. Une clé privée doit rester sur la machine de confiance, avec des permissions restrictives ; la clé publique est placée dans le fichier d’autorisation du compte distant. Activez une phrase de passe pour limiter les conséquences d’un vol de clé.

1. Créez ou utilisez un compte dédié au transfert, limité au répertoire nécessaire.
2. Vérifiez l’empreinte de clé du serveur SSH avant la première connexion.
3. Testez le transfert avec un fichier non sensible et un chemin de destination isolé.
4. Conservez les journaux de la tâche automatisée, sans y inscrire de secret.
5. Examinez les droits du dossier cible après chaque changement de configuration.

Un port SSH personnalisé peut réduire certains scans automatisés, mais il ne remplace pas les mises à jour, les clés SSH et des règles d’accès cohérentes. Pour automatiser, utilisez des clés dédiées et restreignez le compte plutôt que de placer un mot de passe dans un script.

Vérifier le résultat après le transfert

La vérification doit porter sur la présence des fichiers, leur taille, leurs droits et, lorsque l’intégrité est critique, leur somme de contrôle. Un transfert terminé sans message d’erreur ne prouve pas à lui seul que le bon dossier, la bonne version ou les bonnes permissions ont été utilisés.

Sur le serveur distant, listez les fichiers et leur taille avec une commande SSH. Pour un fichier important, calculez la même somme de contrôle sur la source et la destination avec l’outil de hachage disponible dans votre environnement.

ssh [email protected] "ls -lh /home/admin/reception/"
sha256sum /srv/export/rapport.csv
ssh [email protected] "sha256sum /home/admin/reception/rapport.csv"

Le résultat attendu est une taille cohérente et deux empreintes identiques pour le même fichier. Une somme différente signale un problème à investiguer avant d’utiliser les données ; ne remplacez pas une sauvegarde par cette seule vérification de transfert.

Erreurs fréquentes avec SCP et Rsync

Les erreurs de transfert viennent souvent d’un détail de syntaxe ou de droits plutôt que de l’outil lui-même. Une lecture attentive du chemin source, du chemin distant et du message SSH permet généralement de localiser la cause sans multiplier les essais au hasard.

Erreur de permission SCP ou Rsync

Le message Permission denied peut désigner un refus SSH ou une impossibilité d’écrire dans le dossier distant. Vérifiez d’abord que le compte utilisé est autorisé à se connecter, puis testez son accès au répertoire avec touch ou ls via SSH. Corrigez les droits du dossier cible par une procédure d’administration contrôlée, sans exécuter SCP ou Rsync en administrateur par défaut.

Connexion refusée ou serveur inaccessible

Un message Connection refused indique souvent qu’aucun service SSH n’écoute sur le port demandé, ou qu’un filtrage réseau bloque la connexion. Confirmez le bon hôte, le bon port et l’état du service SSH avec l’équipe ou la console d’administration du serveur. Utilisez -P avec SCP et -e "ssh -p PORT" avec Rsync si un port spécifique est réellement configuré.

Chemin introuvable ou fichiers copiés au mauvais endroit

Une omission de deux-points après utilisateur@hôte transforme une destination distante en chemin local. Avec Rsync, la barre oblique finale sur le dossier source détermine si le contenu ou le dossier parent est copié. Lancez une simulation --dry-run avant les synchronisations importantes afin d’observer exactement l’arborescence prévue.

Transfert interrompu

SCP ne reprend pas automatiquement un transfert interrompu : relancer la commande recommence la copie demandée. Pour des fichiers volumineux ou un réseau instable, utilisez Rsync avec --partial-dir, puis relancez la même commande après le retour de la connexion. Vérifiez toutefois l’espace disque disponible, car les données partielles occupent de la place.

Suppression involontaire avec Rsync

L’option --delete crée un miroir plus strict en supprimant sur la destination les fichiers absents de la source. Cette option peut être utile dans un déploiement maîtrisé, mais elle devient risquée si la source est incomplète ou si les chemins sont inversés. Testez toujours avec --dry-run et une destination non critique avant toute utilisation.

Automatiser une synchronisation récurrente sans fragiliser les données

Une tâche planifiée peut lancer Rsync à intervalles réguliers pour un répertoire dont la structure est stable. L’automatisation doit rester lisible : commande versionnée, clé SSH dédiée, journalisation et simulation après chaque changement de règle d’exclusion ou de chemin.

Une commande automatisée ne constitue pas une stratégie de sauvegarde complète. Une synchronisation peut propager une suppression, un chiffrement malveillant ou un fichier corrompu vers la destination. Conservez des versions, des copies isolées ou une politique de sauvegarde distincte lorsque le répertoire contient des données importantes.

La limitation de bande passante, les exclusions et la reprise partielle rendent Rsync plus confortable pour une tâche régulière. Le mécanisme de synchronisation n’empêche toutefois pas une erreur de configuration : contrôlez les journaux et vérifiez périodiquement le contenu réellement présent sur le serveur cible.

Sources utiles à consulter

La page de manuel SCP dans OpenSSH décrit la syntaxe, les options de port et les limites de la commande. Vérifiez la page correspondant à la version installée sur votre système avant d’utiliser une option moins courante.

La documentation officielle Rsync détaille le mode archive, les exclusions, la simulation et les options de synchronisation. Consultez-la avant de déployer --delete, des règles d’exclusion complexes ou une conservation avancée des attributs.

Questions fréquentes sur SCP et Rsync

SCP est-il suffisant pour un transfert ponctuel ?

Oui, SCP convient à l’envoi ou à la récupération d’un fichier, voire d’un dossier avec l’option -r. SCP est simple à utiliser lorsque SSH fonctionne déjà entre les deux serveurs. Pour une copie interrompue ou répétée, Rsync apporte davantage de contrôle.

Rsync transfère-t-il les fichiers de manière sécurisée ?

Rsync peut utiliser SSH pour le transport distant, ce qui chiffre les échanges et authentifie le serveur et le compte. La sécurité dépend aussi de la protection des clés SSH, des droits du compte distant et de la vérification de l’empreinte du serveur.

Comment éviter d’écraser un fichier existant avec SCP ?

SCP peut remplacer un fichier de même nom sur la destination sans confirmation. Utilisez un nom de fichier versionné, copiez d’abord vers un dossier de dépôt ou vérifiez l’existence du fichier distant avec SSH avant de lancer la copie.

Comment transférer de nombreux fichiers sans tout recopier ?

Utilisez Rsync avec le mode archive, par exemple rsync -av source/ utilisateur@hôte:destination/. Rsync compare les contenus avant les synchronisations suivantes et évite généralement de retransférer les fichiers inchangés.

Faut-il utiliser --delete avec Rsync ?

L’option --delete sert à obtenir un miroir de la source en supprimant les fichiers absents sur la destination. Utilisez-la seulement lorsque cette suppression est voulue et testée avec --dry-run. Elle ne convient pas à une destination qui doit conserver son propre historique.