Transfert rapide de gros fichiers entre deux serveurs Linux grâce à rsync sur SSH

Le transfert de fichiers volumineux entre deux serveurs via SSH avec la commande rsync est l’une des méthodes les plus efficaces et robustes pour les administrateurs Linux. Que vous migriez des sites web de plusieurs centaines de giga-octets, des archives de sauvegarde, des dossiers médias ou des données applicatives, rsync se distingue par sa capacité à ne transférer que les blocs modifiés, ce qui accélère considérablement l’opération par rapport aux méthodes de copie traditionnelles. Le principe est simple : les fichiers de la source sont synchronisés vers la destination via un tunnel SSH chiffré ; si la connexion se coupe, la reprise est possible sans tout recommencer.

Dans les opérations de migration de serveur, d’upgrade d’hébergement, de changement de datacenter ou de sauvegarde, la rapidité mais aussi l’intégrité des données sont essentielles. Télécharger puis re-uploader un gros volume en une seule fois peut être chronophage et vous obliger à tout recommencer en cas de coupure. rsync intervient ici en conservant les horodatages, permissions, propriétaires et structure des dossiers. C’est pour cela qu’il est plébiscité au quotidien par les sysadmins Linux, équipes DevOps et experts en hébergement web.

Dans ce guide, nous détaillerons étape par étape comment transférer des fichiers volumineux entre deux serveurs Linux via rsync sur SSH, avec des exemples concrets de commandes. Nous aborderons aussi les paramètres pour optimiser la performance, les contrôles de sécurité, la gestion des erreurs, le transfert de test et les points à vérifier avant de passer en production. Si vous envisagez une migration vers un nouveau VPS ou un nouvel hébergement, assurez-vous d’avoir assez d’espace disque, un accès SSH et les droits d’utilisateur adéquats sur source et destination. Pour choisir l’infrastructure adaptée, consultez Solutions de serveur VPS Hostragons et Forfaits d'Hébergement Linux.

Pourquoi choisir rsync sur SSH pour transférer de gros fichiers ?

rsync est un outil en ligne de commande puissant pour synchroniser fichiers et dossiers en local ou entre serveurs distants. Son atout majeur : l’algorithme de transfert delta, qui n’envoie que les parties modifiées du fichier au lieu de tout recopier à chaque fois. Par exemple, sur une archive de sauvegarde de 80 Go dont seuls 2 Go ont changé, rsync peut ne transférer que ces blocs modifiés, ce qui optimise le temps et la bande passante.

SSH apporte le chiffrement. Ainsi, les fichiers transitent de façon sécurisée, et ne risquent pas d’être interceptés sous forme de texte brut. Cette sécurité est cruciale, notamment pour les données clients, commandes e-commerce, archives médias, backups de bases de données et fichiers applicatifs sensibles. La sécurité dans l’hébergement ne se limite pas au SSL pour le trafic web : le canal de transfert inter-serveurs doit aussi être sécurisé. Utilisez certificat SSL pour le site web, et SSH pour les transferts entre serveurs.

rsync offre une flexibilité supérieure à FTP ou aux téléchargements manuels : il conserve les permissions, transporte les liens symboliques, peut supprimer les fichiers obsolètes sur la destination, limiter la bande passante et tester l’opération avant de la lancer. Ce niveau de contrôle est précieux lors de transferts risqués de gros fichiers.

Quand utiliser rsync sur SSH ?

La commande rsync sur SSH est particulièrement adaptée au transfert de gros volumes, de nombreux fichiers ou de dossiers fréquemment modifiés. Pour un petit dossier d’images, un SFTP manuel suffit. Mais avec des milliers de fichiers, des droits personnalisés et des archives massives, rsync devient la solution la plus fiable.

• Migrer un site web d’un ancien serveur vers un nouveau VPS.
• Transférer un répertoire WordPress uploads contenant des milliers de fichiers médias.
• Sauvegarder quotidiennement, hebdomadairement ou mensuellement vers un autre serveur.
• Changer de datacenter ou de fournisseur d’hébergement.
• Synchroniser des fichiers applicatifs entre production et sauvegarde.
• Prévoir des transferts longs avec risque de coupure de connexion.

Par exemple, télécharger 250 Go de médias sur votre PC puis les re-uploader vers un nouveau serveur double la durée et risque de saturer votre connexion domestique ou professionnelle. Avec rsync, vous faites le transfert direct entre serveurs, sans étape intermédiaire.

Pré-requis avant de commencer

La maîtrise de la commande rsync ne suffit pas : il faut vérifier les conditions sur les deux serveurs pour réduire les risques de perte de données ou d’échecs de transfert. Voici les contrôles à effectuer en production.

1. Vérifiez l’accès SSH

La source doit pouvoir se connecter à la destination en SSH. Testez : ssh utilisateur@ip-destination. Si SSH écoute sur un port personnalisé : ssh -p 2222 utilisateur@ip-destination. Si cette étape échoue, rsync échouera aussi. Vérifiez le firewall, Fail2ban, le port SSH, les droits utilisateur et l’authentification par mot de passe ou clé.

2. Vérifiez l’installation de rsync

La plupart des distributions Linux incluent rsync, mais vérifiez tout de même avec rsync --version (Debian/Ubuntu). Si besoin, installez avec apt install rsync. Sur AlmaLinux/Rocky/CentOS : dnf install rsync ou yum install rsync. Sur VPS Linux Hostragons, l’installation prend quelques secondes.

3. Vérifiez l’espace disque

Si le disque de destination manque d’espace, le transfert sera interrompu. Pour connaître la taille du dossier source : du -sh /source/dossier. Sur la destination : df -h. Prévoyez plus que la taille du fichier, pour les fichiers temporaires et logs. Pour 500 Go à transférer, comptez au moins 550–600 Go d’espace disponible.

4. Prévoyez les services critiques et les fichiers en mutation

Sur un site actif, les fichiers peuvent changer pendant le transfert : uploads utilisateurs, caches, logs… Pour un gros volume, transférez d’abord les données principales, puis mettez le site en maintenance et faites un second rsync. Ainsi, l’interruption est réduite au minimum. Pour WordPress, consultez Guide de migration d'hébergement WordPress pour affiner votre plan.

Commande rsync de base : transférer des dossiers entre deux serveurs

La syntaxe la plus courante : rsync -avz /source/dossier/ utilisateur@ip-destination:/destination/dossier/. Ici : -a pour mode archive (permissions, horodatages, liens symboliques), -v pour affichage détaillé, -z pour compression pendant le transfert. Attention à la barre oblique : /source/dossier/ copie le contenu, /source/dossier crée le dossier lui-même sur la destination.

Exemple : déplacer 180 Go de /var/www/site/public_html/ de l’ancien serveur vers /var/www/site/public_html/ sur le nouveau : rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. Le transfert s’effectue via SSH.

Pour éviter d’utiliser root, créez un utilisateur dédié avec droits d’écriture sur le dossier cible (ex : deploy). La sécurité recommande d’éviter root en production.

Paramètres recommandés pour un transfert rsync robuste

Pour un gros transfert, la commande de base peut ne pas suffire. En cas de coupure, fichiers partiels, suppression accidentelle ou réseau lent, ajoutez ces paramètres :

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /source/dossier/ utilisateur@ip-destination:/destination/dossier/

-a mode archive, -H liens durs, -A ACL, -X attributs étendus, --numeric-ids conserve les IDs (utile si les noms d’utilisateurs diffèrent), --partial garde les fichiers inachevés, --progress affiche la progression, --append-verify vérifie lors de la reprise d’un gros fichier.

Chaque paramètre n’est pas toujours nécessaire. Pour un site web simple, -aHAX suffit. Pour des applications avec des droits complexes, ACL et attributs étendus sont cruciaux. Testez toujours avant le transfert réel.

Utiliser un port SSH personnalisé avec rsync

Pour la sécurité, SSH peut écouter sur un port différent de 22. Indiquez-le dans rsync : rsync -avz -e ssh -p 2222 /source/dossier/ utilisateur@ip-destination:/destination/dossier/. Mais attention : la syntaxe correcte : rsync -avz -e 'ssh -p 2222' /source/dossier/ utilisateur@ip-destination:/destination/dossier/.

Selon votre terminal ou panneau, vérifiez la syntaxe des guillemets. Si vous utilisez une clé SSH : rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /source/dossier/ utilisateur@ip-destination:/destination/dossier/. Cette méthode est courante en automatisation ou pour les backups via cron.

Test de transfert : utiliser --dry-run

Avant de lancer un gros transfert, faites un test avec --dry-run. Ce paramètre ne copie rien, mais liste les fichiers qui seraient transférés. Vous pouvez ainsi vérifier les chemins, éviter les erreurs de suppression ou de destination.

Exemple : rsync -avz --dry-run /var/www/site/ utilisateur@ip-destination:/var/www/site/. Vous verrez les fichiers concernés, les dossiers créés et le résumé. Si vous utilisez --delete, le test est encore plus crucial car ce paramètre supprime sur la destination ce qui n’existe plus sur la source : pratique pour une synchronisation miroir, risqué en cas de mauvaise cible.

La séquence professionnelle : test SSH, contrôle disque, rsync --dry-run, test sur un petit dossier, puis lancement du transfert principal. Cela prend quelques minutes mais évite des heures de correction après un échec.

Optimiser la performance : compression, bande passante, chiffrement

La performance de rsync dépend de la taille des fichiers, mais aussi du CPU, du disque, du ping réseau, de la bande passante et du nombre de fichiers. Beaucoup de petits fichiers peuvent ralentir le transfert plus qu’un seul fichier géant, à cause du traitement de métadonnées. Les VPS avec disques NVMe offrent un gain de performance évident pour le scan et l’écriture : pensez à serveur VPS NVMe si vous prévoyez de gros transferts.

La compression (-z) est utile sur des fichiers texte, logs ou certains backups, mais pas sur des fichiers déjà compressés (zip, tar.gz, jpg, mp4, gzip). Si vous transférez des médias volumineux entre deux serveurs puissants sur du 1 Gbps, la compression peut être contre-productive. Sur une bande passante limitée ou des fichiers texte, -z apporte un vrai gain.

Pour limiter la bande passante : --bwlimit. Exemple : --bwlimit=50000 limite à environ 50 Mo/s. Cela évite de saturer le trafic web du site pendant les heures de pointe. Privilégiez les transferts nocturnes, limitez la bande passante et surveillez la charge serveur (load average).

Comparatif : rsync, scp, SFTP, FTP

Il existe plusieurs méthodes de transfert de fichiers, chacune ayant ses avantages et limites. Le tableau suivant résume les usages recommandés en contexte de migration de gros volumes :

Comme le montre le tableau, rsync est le plus adapté aux synchronisations répétées et aux gros transferts. scp est simple mais détecte moins bien les changements. FTP sans chiffrement ne répond plus aux normes actuelles. Privilégiez les méthodes SSH pour tout transfert critique entre serveurs.

Workflow type : migration d’un site web avec gros fichiers

La migration d’un site implique plus que le transfert des fichiers : DNS, base de données, SSL, version PHP, droits et configuration mail sont aussi à vérifier. Voici un workflow pour minimiser la coupure sur un site volumineux :

• Préparez le serveur web, PHP, base de données et modules sur la nouvelle machine.
• Réduisez le TTL DNS à 300 secondes avant la migration (voir Vérification de domaine et gestion de domaine).
• Lancez le premier rsync alors que le site est actif : cela transfère la majorité des données.
• Exportez la base de données et transférez-la.
• Mettez le site en mode maintenance temporairement.
• Lancez un second rsync pour synchroniser les derniers changements.
• Répétez l’export de la base ou utilisez une stratégie incrémentale.
• Vérifiez droits, logs et fonctionnement sur le nouveau serveur.
• Installez ou renouvelez le certificat SSL (installation du certificat SSL).
• Modifiez les enregistrements DNS vers la nouvelle IP.

Avec cette méthode, le transfert principal se fait pendant la disponibilité du site, et la coupure n’existe que lors de la synchronisation finale et du switch DNS. Pour un WordPress avec beaucoup de médias, cela réduit une coupure de plusieurs heures à quelques minutes.

Vérification de l’intégrité des données

La fin du transfert ne garantit pas que tout est ok : comparez nombre de fichiers, tailles et les éléments critiques. Utilisez du -sh sur source et destination pour comparer les volumes (attention, les différences de système de fichiers peuvent fausser la comparaison). Pour une vérification approfondie, relancez rsync avec les mêmes paramètres : si rien n’est transféré, l’opération est complète.

Pour vérifier par checksum : rsync -avc --dry-run /source/dossier/ utilisateur@ip-destination:/destination/dossier/ (-c compare par checksum). À utiliser avec précaution sur de très gros volumes (charge CPU/disque). Pour les archives critiques, dumps de bases ou documents clients, cette vérification rassure.

Après transfert d’un site, testez aussi côté application : page d’accueil, panneau admin, upload médias, paiement, formulaire de contact et logs d’erreur. Sur un site e-commerce, testez aussi les intégrations paiements et les tâches cron sur le nouveau serveur.

Erreurs courantes et solutions

Erreur « Permission denied »

Souvent liée aux droits SSH, permissions sur le dossier cible ou à la clé d’authentification. Testez d’abord la connexion SSH avec le même utilisateur. Si ok, essayez de créer un fichier sur la destination. Si besoin, modifiez la propriété du dossier (chown) ou définissez une stratégie sudo.

Erreur « No space left on device »

Arrive quand le disque de destination est plein. Vérifiez df -h sur toutes les partitions. Parfois le disque principal est ok, mais /tmp ou le point de montage cible saturé. Nettoyez logs, backups anciens, caches. Si besoin, upgradez votre VPS pour plus d’espace.

Erreur « Connection reset » ou « Broken pipe »

Typique lors de longs transferts. Avec --partial et --append-verify, relancez la commande pour reprendre là où elle s’est arrêtée. Les réglages SSH keepalive (ServerAliveInterval 60) peuvent aider à éviter les coupures.

Transfert très lent

Souvent lié au nombre de fichiers, aux limites disque, à la compression ou à la bande passante. Si vous avez beaucoup de petits fichiers, créez d’abord une archive tar (mais rsync ne détectera plus les changements fichiers). Pour des fichiers déjà compressés, retirez -z. Utilisez iotop, htop, iftop pour identifier le goulot d’étranglement.

Bonnes pratiques sécurité

La sécurité ne doit jamais être négligée lors d’un transfert entre serveurs. Évitez l’accès root direct, privilégiez les clés SSH à la place des mots de passe, sécurisez les droits de vos clés, ajoutez une passphrase si possible.

Créez un utilisateur temporaire avec accès limité au dossier concerné, puis désactivez-le après le transfert. Limitez l’accès SSH à des IP spécifiques pour réduire la surface d’attaque. Vérifiez les règles de firewall, Fail2ban et la version d’OpenSSH.

Pour les dumps de base, documents client ou données personnelles, nettoyez les fichiers temporaires une fois le transfert terminé. Ne laissez jamais des backups (.sql, .zip, .tar) accessibles depuis le dossier public web : stockez-les ailleurs ou supprimez-les.

Utiliser rsync pour les sauvegardes automatiques

rsync ne sert pas seulement à la migration : il permet aussi des backups réguliers. Par exemple, chaque nuit, un dossier peut être synchronisé vers un serveur de sauvegarde via cron, en SSH et sans mot de passe grâce à une clé. rsync ne transfère que les fichiers modifiés et peut limiter la bande passante.

Exemple : rsync -a --delete --bwlimit=30000 /var/www/site/ backup@ip-backup:/backup/site/. Cette commande synchronise le dossier source et destination. Attention avec --delete : tout fichier supprimé sur la source sera aussi supprimé sur la destination. Privilégiez des stratégies avec snapshots, dossiers par jour ou solutions avec versioning pour les backups critiques.

En hébergement, appliquez la règle du backup 3-2-1 : 3 copies, 2 supports différents, 1 hors site. rsync simplifie la copie inter-serveurs. Pour une infrastructure plus complète, consultez Solutions de sauvegarde et services d'hébergement professionnel.

Checklist finale avant transfert massif

Avant de lancer un transfert de gros fichiers, suivez cette liste pour limiter les erreurs. Elle devrait devenir un standard en production :

• rsync est-il installé sur les deux serveurs ?
• La connexion SSH fonctionne avec le bon utilisateur et port ?
• Le disque de destination a-t-il assez d’espace ?
• Un test --dry-run a-t-il été effectué ?
• Pour un site actif, le mode maintenance et la synchronisation finale sont-ils prévus ?
• Si --delete est utilisé, le chemin cible est-il validé ?
• Après transfert, les tailles, droits et tests applicatifs seront-ils vérifiés ?
• Les fichiers temporaires et dumps seront-ils nettoyés de façon sécurisée ?

Ces contrôles semblent simples, mais la plupart des erreurs viennent d’un mauvais dossier cible, de droits manquants, d’un espace disque insuffisant ou d’un changement DNS mal anticipé. Un processus rsync planifié réduit le temps de migration et sécurise la reprise.

Questions fréquentes

Que se passe-t-il si la connexion SSH se coupe lors d’un transfert rsync ?

Avec les bons paramètres (--partial, --append-verify), le transfert ne recommence pas à zéro. Les fichiers partiels sont conservés et la reprise se fait là où elle a stoppé. Vérifiez l’espace disque et les fichiers partiels avant de relancer.

Peut-on transférer une base de données directement avec rsync ?

Non, rsync transfère des fichiers. Il ne faut pas copier directement une base de données active (ex : MySQL, MariaDB). Utilisez mysqldump ou un outil de backup physique, puis transférez le fichier de dump avec rsync. En production, prévoyez maintenance ou réplication pour garantir l’intégrité.

Faut-il être root sur les deux serveurs pour utiliser rsync ?

Ce n’est pas obligatoire. Un utilisateur ayant droits d’écriture sur la cible suffit. Pour conserver la propriété, les ACL ou les droits complexes, il faudra parfois plus de privilèges. Mais en sécurité, privilégiez les utilisateurs avec droits limités.

La fonction --delete est-elle sûre ?

Elle est très utile pour synchroniser une cible en miroir, mais peut provoquer une perte de données si mal utilisée. Testez toujours avec --dry-run, vérifiez les chemins source et destination avant de lancer.

Pour les gros transferts, rsync ou scp ?

scp convient pour des copies rapides et ponctuelles, mais rsync est préférable pour les gros volumes, les nombreux fichiers ou les synchronisations répétées : il détecte les changements, reprend les transferts interrompus, limite la bande passante et permet des tests.

Résumé : les clés d’un transfert de fichiers efficace

Transférer de gros fichiers entre deux serveurs Linux via rsync sur SSH est une méthode rapide, sécurisée et fiable. Avec les bons paramètres, vous résistez aux coupures, n’envoyez que les fichiers modifiés et limitez la coupure lors d’une migration de site. Pour les meilleurs résultats : vérifiez SSH et l’espace disque, faites un test --dry-run, puis lancez le transfert principal de façon planifiée.

Si vous prévoyez une migration vers un nouveau serveur, une augmentation de stockage ou un hébergement plus performant, explorez les solutions Hostragons. Selon vos besoins, VPS, hébergement, domaine et SSL vous permettront un transfert en toute sécurité. Commencez par des tests, mesurez, puis réalisez la synchronisation finale de façon planifiée.