diff

Le
zardoz
Bonjour,

Je voudrais savoir quel est l'outil le plus rapide, entre rsync et ftp,
pour transférer des données entre un serveur distant et un local

Merci
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Dominique ROUSSEAU
Le #24824252
Le sam., 29 sept. 2012 at 15:32 GMT, zardoz
Bonjour,

Je voudrais savoir quel est l'outil le plus rapide, entre rsync et ftp,
pour transférer des données entre un serveur distant et un local



En partant de "zero" (ie pas de transfert incrémentiel), ça dépendra bien plus
du réqeau entre les 2 que de l'outil utilisé. rsync permettra juste reprendre
simplement, si c'est interrompu en cours.
Le Forgeron
Le #24824552
Le 29/09/2012 18:12, Dominique ROUSSEAU nous fit lire :
Le sam., 29 sept. 2012 at 15:32 GMT, zardoz
Bonjour,

Je voudrais savoir quel est l'outil le plus rapide, entre rsync et ftp,
pour transférer des données entre un serveur distant et un local



En partant de "zero" (ie pas de transfert incrémentiel), ça dépendra bien plus
du réqeau entre les 2 que de l'outil utilisé. rsync permettra juste reprendre
simplement, si c'est interrompu en cours.



C'est pas faux... mais rsync permet de faire également de la compression
au vol, ce qui nécessiterait une phase préparatoire et postèrieure avec
ftp. ça n'a pas d'intérêt dans le cadre de transfert d'images (enfin
jpeg et png), mais on transfere parfois d'autres choses.

Ne pas perdre de vue non plus que le goulet peut ne pas être le réseau
(mais l'un des disques par exemple), enfin, dans le cas soit d'un
transfert sur LAN ou si on a le bonheur d'être en fibre des deux cotés.

A noter que si le transfert concerne une multitude de fichiers:
* FTP va probablement ouvrir une connexion data par fichier (c'est pas
obligatoire dans la RFC, mais les implémentations font rarement
autrement), donc chaque transfert encours un délai de latence
supplémentaire, le temps de mettre en place cette connexion (dont
l'algorithme gérant la fenêtre d'acquittement repart à zéro à chaque fois)
* rsync va effectuer un checksum post-transfert de chaque fichier, ça
peut également ralentir les performances globales (bien qu'ayant été
récemment en mémoire, il y aura une difference avec un flux ininterrompu.)
zardoz
Le #24836672
Bonjour,

Merci pour vos réponses.

Il s'agit effectivement de transfèrer des fichiers de gros volume (disons
40 à 60 Go découpés en tranches de 20 Go environ dans plusieurs .tgz),
voire en une seule archive, sur un lien fibre à 100Mb ;
L'idée étant de scipter ça en Perl, car il me semble qu'en bash ou sh
un ftp va demander un mot de passe à la connection au serveur distant,
donc pas automatisable avec un cron par exemple.

Me corriger si je me trompe :-)

Merci

Le Sat, 29 Sep 2012 20:27:25 +0200, Le Forgeron a écrit :

Le 29/09/2012 18:12, Dominique ROUSSEAU nous fit lire :
Le sam., 29 sept. 2012 at 15:32 GMT, zardoz
Bonjour,

Je voudrais savoir quel est l'outil le plus rapide, entre rsync et
ftp,
pour transférer des données entre un serveur distant et un local



En partant de "zero" (ie pas de transfert incrémentiel), ça dépendra
bien plus du réqeau entre les 2 que de l'outil utilisé. rsync permettra
juste reprendre simplement, si c'est interrompu en cours.



C'est pas faux... mais rsync permet de faire également de la compression
au vol, ce qui nécessiterait une phase préparatoire et postèrieure avec
ftp. ça n'a pas d'intérêt dans le cadre de transfert d'images (enfin
jpeg et png), mais on transfere parfois d'autres choses.

Ne pas perdre de vue non plus que le goulet peut ne pas être le réseau
(mais l'un des disques par exemple), enfin, dans le cas soit d'un
transfert sur LAN ou si on a le bonheur d'être en fibre des deux cotés.

A noter que si le transfert concerne une multitude de fichiers:
* FTP va probablement ouvrir une connexion data par fichier (c'est pas
obligatoire dans la RFC, mais les implémentations font rarement
autrement), donc chaque transfert encours un délai de latence
supplémentaire, le temps de mettre en place cette connexion (dont
l'algorithme gérant la fenêtre d'acquittement repart à zéro à chaque
fois)
* rsync va effectuer un checksum post-transfert de chaque fichier, ça
peut également ralentir les performances globales (bien qu'ayant été
récemment en mémoire, il y aura une difference avec un flux
ininterrompu.)
zardoz
Le #24836692
Le Thu, 04 Oct 2012 01:15:13 +0000, zardoz a écrit :

Bonjour,

Merci pour vos réponses.

Il s'agit effectivement de transfèrer des fichiers de gros volume
(disons 40 à 60 Go découpés en tranches de 20 Go environ dans plusieurs
.tgz), voire en une seule archive, sur un lien fibre à 100Mb ;
L'idée étant de scipter ça en Perl, car il me semble qu'en bash ou sh un
ftp va demander un mot de passe à la connection au serveur distant, donc
pas automatisable avec un cron par exemple.

Me corriger si je me trompe :-)

Merci

Le Sat, 29 Sep 2012 20:27:25 +0200, Le Forgeron a écrit :




Re-bonjour,

ça serait du FTPS évidemment, + crypy openssl des fichiers tranférés.

Merci
Le Forgeron
Le #24838482
Le 04/10/2012 03:24, zardoz nous fit lire :
Le Thu, 04 Oct 2012 01:15:13 +0000, zardoz a écrit :

Bonjour,

Merci pour vos réponses.

Il s'agit effectivement de transfèrer des fichiers de gros volume
(disons 40 à 60 Go découpés en tranches de 20 Go environ dans plusieurs
.tgz), voire en une seule archive, sur un lien fibre à 100Mb ;
L'idée étant de scipter ça en Perl, car il me semble qu'en bash ou sh un
ftp va demander un mot de passe à la connection au serveur distant, donc
pas automatisable avec un cron par exemple.

Me corriger si je me trompe :-)

Merci

Le Sat, 29 Sep 2012 20:27:25 +0200, Le Forgeron a écrit :




Re-bonjour,

ça serait du FTPS évidemment, + crypy openssl des fichiers tranférés.

Merci




Si l'objectif des tranches est uniquement la reprise sur interruption,
voir l'option --partial de rsync. Avec une paire RSA (ou DSA), ça
sécurise l'accès au serveur (mais faut laisser la phrase de passe vide
pour un cron... de toute manière, si on scripte pour cron, le mot/la
phrase de passe se retrouve stocké... plouf pour la sécurité sur le
client, reste le MIM et la protection d'accés au serveur)

Sinon, sans perl à écrire et à polir, le client lftp est très bien: un
peu dur à maitriser, mais permet de faire des reprises sans trop de
difficultés.

Par exemple: en mode aspiration (pour du miroir, ici on detruit
également les fichiers qui ont disparu de la source et était encore sur
la destination :"-e")

lftp ftp://user: -e "mirror -e /
/local/disk/to/fill ; quit"

(le mode "push" s'obtient en ajoutant -R après "mirror -e" et en
inversant les deux répertoire (distant/local))

Il supporte ftps, donc pas la peine de se prendre la tête non plus.
mirror a plein d'options, voir le man de lftp.
(y compris "-c")
Publicité
Poster une réponse
Anonyme