Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Dominique ROUSSEAU
Le sam., 29 sept. 2012 at 15:32 GMT, zardoz a écrit :
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 sam., 29 sept. 2012 at 15:32 GMT, zardoz <zardoz@home.net> a écrit :
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 sam., 29 sept. 2012 at 15:32 GMT, zardoz a écrit :
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 29/09/2012 18:12, Dominique ROUSSEAU nous fit lire :
Le sam., 29 sept. 2012 at 15:32 GMT, zardoz a écrit :
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.)
Le 29/09/2012 18:12, Dominique ROUSSEAU nous fit lire :
Le sam., 29 sept. 2012 at 15:32 GMT, zardoz <zardoz@home.net> a écrit :
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.)
Le 29/09/2012 18:12, Dominique ROUSSEAU nous fit lire :
Le sam., 29 sept. 2012 at 15:32 GMT, zardoz a écrit :
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
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 a écrit :
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.)
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 <zardoz@home.net> a écrit :
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.)
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 a écrit :
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 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 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.
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 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")
(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")
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")
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")
