Comment puis-je reprendre un gros transfert de fichier scp lors de l'utilisation de la redirection de port?


10

J'ai une machine à quelques sauts et je dois configurer la redirection de port afin de transférer des fichiers.

Edit: Pour être clair, plusieurs sauts sont nécessaires pour accéder à la machine distante. Depuis ma machine, j'ai configuré un VPN, où je peux accéder à 10.255.xx - c'est la seule machine à laquelle je peux me connecter via le VPN. Une fois connecté à .xx, je peux ensuite me connecter à d'autres machines - .yy étant l'une d'entre elles.

Depuis ma machine:

ssh -L 4567:localhost:4567 me@10.255.x.x

Puis à partir de cette machine:

ssh -L 4567:localhost:22 me@10.255.y.y

Je peux alors

scp -P 4567 me@localhost:/path/to/large/file.gz .

J'ai quitté cette nuit, pour constater que le transfert est mort à un moment donné.

J'ai vu quelques suggestions pour utiliser rsync sur ssh pour reprendre le transfert, mais je ne sais pas comment configurer cela. Est-ce possible?


À quoi servent tous ces sauts? N'atteindrait pas scp me@10.255.x.x:/path/to/large/file.gz .exactement la même chose? Quelle version de scp (ssh) est installée sur le client et le serveur?
Dennis

@Dennis: scp ne prend pas en charge la reprise d'un transfert - ce que vous proposez redémarrera le téléchargement.
chris

Certaines versions le font (le scp de mon ordinateur portable le fait, mon VPS ne le fait pas). La raison pour laquelle je demande, c'est parce que le houblon me semble inutile, et la synchronisation sans houblon sera beaucoup plus facile.
Dennis

Cette réponse pourrait également vous aider: unix.stackexchange.com/a/43097/14084
Bernhard

Réponses:


9

Avec certaines versions de scp (la version sur l'ordinateur source semble être la clé), il suffit de réexécuter la commande scp pour reprendre le transfert. Mais fais attention! Si votre version ne prend pas en charge les transferts partiels, le fichier partiel sera simplement écrasé.

Les commutateurs rsync suivants sont pratiques pour reprendre un transfert interrompu si scp ne le prend pas en charge:

     --append                append data onto shorter files
     --append-verify         like --append, but with old data in file checksum
 -e, --rsh=COMMAND           specify the remote shell to use
     --progress              show progress during transfer

La commande

rsync --append-verify --progress --rsh="ssh -p 4567" me@localhost:/path/to/large/file.gz .

devrait avoir l'effet souhaité. Notez que le -pcommutateur doit être en minuscules pour ssh.


Les sauts sont nécessaires en raison de la configuration du réseau sur le serveur de destination. Le problème avec l'utilisation de rsync sur ssh est que je dois utiliser le port local 4567, le fichier n'existe pas sur le serveur 10.255.xx.
chris

Mon erreur. Je supposais que 10.255.y.yc'était l'ordinateur client.
Dennis

J'ai mis à jour ma réponse.
Dennis

et que faire s'il n'y a aucun moyen d'utiliser rsync? Dans mon cas, je n'ai que ftp disponible sur l'hôte distant.
dr.dimitru

1
@Enzo La question concerne SCP, la réponse doit concerner scp. La question porte sur un transfert scp incomplet, pas sur l'outil scp. Il indique littéralement que j'ai vu quelques suggestions d'utiliser rsync sur ssh pour reprendre le transfert, mais je ne sais pas comment configurer cela. Est-ce possible? au fond.
Dennis

3

Utiliser sftp au lieu de scp

Dans ton cas:

sftp -a -P 4567 me@localhost:/path/to/large/file.gz .

Depuis la page de manuel sftp:

-a      Attempt to continue interrupted downloads rather than overwriting existing partial or complete copies of files.  If the remote file contents differ from the partial local copy then the resultant file is likely to be corrupt.

1

rsync utilise ssh par défaut, vous devrez peut-être spécifier la commande ssh exacte à l'aide du commutateur -e de rsync. Il a également un --partial qui devrait conserver le fichier incomplet afin qu'il puisse reprendre le transfert.


-1

Je ne vois pas vraiment à quoi servent vos tunnels, alors voici comment j'irais à résoudre votre problème:

ssh -R $tunnelPort:localhost:$localSSHPort $remoteUser@$remoteHost -p $remoteSSHPort

cela ouvre un tunnel inverse de la machine locale (localhost) à la machine distante (remotehost). $ tunnelPort est le port sur lequel se trouve le tunnel sur remotehost. $ localSSHPort est le port sur lequel s'exécute le sshd local et $ remoteSSHPort est l'endroit où sshd de remotehost écoute.

Maintenant que vous êtes à l'intérieur du tunnel (inversé!), Vous pouvez plus ou moins faire ce que Dennis a proposé:

rsync --apend-verify -az -e 'ssh -p $tunnelPort' /path/to/large/file $user@localhost:/destination

les drapeaux -a et -z sont expliqués dans la page de manuel de rsync, donc je ne les développerai pas. Ce qui se passe maintenant, c'est que lorsque vous exécutez rsync sur remotehost comme ci-dessus, il pousse toutes les données dans le port $ tunnelPort qui est ensuite transmis au sshd $ localSSHPort de votre hôte local.

J'espère que cela a aidé.


@ingenous: J'ai ajouté une explication pour les tunnels.
chris
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.