Dans de nombreux projets IT (migration serveur, PRA, sauvegarde initiale, reprise après incident), une question revient souvent :
« Pourquoi ma copie réseau de 1 To met des heures, voire des jours, alors que le réseau est rapide ? »
La réponse tient rarement au débit brut, mais à la nature des fichiers transférés.
Chez DYB, nous rencontrons ce cas très régulièrement, notamment sur des environnements contenant des centaines de milliers de petits fichiers (PDF, documents comptables, images, exports applicatifs).
Le vrai problème : la copie “fichier par fichier”
Quand vous utilisez :
- un explorateur de fichiers
- SyncBack Pro
- Robocopy
- rsync
- ou une copie SMB/NFS classique
…chaque fichier est traité individuellement.
Pour chaque fichier, le système doit :
- Ouvrir le fichier source
- Lire les métadonnées (taille, dates, permissions)
- Établir un échange réseau
- Créer le fichier côté destination
- Écrire les données
- Fermer le fichier
👉 Sur un fichier de 10 Mo, c’est insignifiant.
👉 Sur 500 000 fichiers de 20 Ko, c’est catastrophique.
Résultat :
- le réseau n’est jamais saturé
- la latence devient le facteur limitant
- le débit réel chute parfois à quelques Mo/s, voire moins
Pourquoi une archive (ZIP / TAR) va beaucoup plus vite
Quand on procède ainsi :
- Création d’une archive sur le serveur source
- Transfert d’un seul fichier volumineux
- Décompression côté destination
On transforme :
- des centaines de milliers d’opérations réseau
- en un flux continu unique
Les gains sont immédiats :
- 🔹 Beaucoup moins d’allers-retours réseau
- 🔹 Débit proche du maximum du lien (1 Gb/s, 10 Gb/s, etc.)
- 🔹 I/O disque séquentielle (beaucoup plus efficace)
- 🔹 Moins d’impact antivirus / ACL / permissions
Même sans compression réelle (TAR simple), le gain est souvent x3 à x10.
Comparaison concrète des méthodes
| Méthode | Avantages | Inconvénients | Cas d’usage |
|---|---|---|---|
| Copie SMB / Explorateur | Simple | Très lent avec petits fichiers | Petits volumes |
| SyncBack Pro | Vérification, synchro | Lent pour un premier “seed” massif | Incrémental |
| Robocopy | Robuste, multi-thread | Toujours pénalisé par petits fichiers | Admin Windows |
| rsync | Très efficace en delta | Lent au premier transfert | Linux / Unix |
| ZIP | Portable | Compression CPU parfois lente | Usage ponctuel |
| TAR (sans compression) | Ultra rapide | Pas de gain de taille | Migration brute |
| TAR + zstd | Excellent compromis | CPU modéré | Backup / transfert |
Pourquoi Robocopy ou rsync ne règlent pas tout
Ces outils sont excellents, mais ils ne changent pas une réalité fondamentale :
Le réseau et les systèmes de fichiers n’aiment pas les millions de petites opérations.
Même avec :
- du multi-thread
- des options agressives
- un NAS performant
…le coût des métadonnées, des permissions et des ouvertures de fichiers reste dominant.
La bonne stratégie professionnelle
Chez DYB, nous appliquons systématiquement cette approche :
1️⃣ Transfert initial
- Création d’une archive (TAR ou ZIP)
- Transfert du fichier unique
- Décompression côté destination
2️⃣ Synchronisation continue
- SyncBack / Robocopy / rsync
- uniquement pour les changements incrémentaux
👉 Résultat :
- temps divisé par plusieurs facteurs
- réseau utilisé efficacement
- risques réduits pendant les migrations
Conclusion
Si votre copie réseau “rame” alors que votre lien est rapide, le problème n’est pas le débit.
C’est le nombre de fichiers.
👉 Quand les volumes sont importants et fragmentés, regrouper avant de transférer est souvent la solution la plus efficace.
Chez DYB, nous accompagnons nos clients sur :
- migrations serveurs
- plans de reprise d’activité
- sauvegardes massives
- optimisations réseau et stockage
📩 Besoin d’un diagnostic ou d’une migration propre ?
Nos équipes peuvent analyser votre volumétrie et choisir la méthode la plus rapide et la plus sûre.
