0

I have to live with a rather complicated setup, which I can't change. It's like so:

Objective: rsync files from a USB drive on network1 to a linux server on network2 where the only connection between the two networks goes through a Windows terminal server (ts) located on network2, but which allows remote desktop (rdp) connections from network1.

Originally, I could connect to network2 from network1 via VPN, attach the USB drive to my computer (Windows), and execute rsync to the linux server on network2. This worked fairly fast and only took a few minutes. Now it has been decided that VPN is not allowed, and we have to go via a terminal server. So, I rdp to the ts and share my USB drive as a local device, and I execute rsync on the ts. It reads the files on my USB and syncs them to the linux server, but now the whole process takes 10-12 hours. Just copying all files (drag'n'drop) takes a couple of hours less. I suspect the reason for the slowness is when the ts determines which files to sync, i.e. stepping through the dirs and files.

My rsync arguments are: -avz --size-only

I hope someone has an idea I could try out. Many thanks!

user168022
  • 3
  • 1
  • 1
    Explain the responsible persons your problem and let them create a solution (like reallow the VPN connection). Other than that, this is off-topic here as you are not a sysadmin managing this setup but an end-user (see the [FAQ]). – Sven Apr 05 '13 at 10:04
  • Okay. I manage the linux server and the software solution (which deep down uses rsync) to synchronize the data, so my question aimed at giving me the ammo for pointing the fingers at the network admins (who otherwise say it's not their fault). – user168022 Apr 05 '13 at 14:05

1 Answers1

0

You can verify if the slowness is working out what needs to be changed by running rsync with --dry-run which will show you what would be transferred without actually doing any copying.

Depending on how much data there is an how fast the connection is I would probably disable the -z compression function or at least experiment whether it makes any difference or not.

You might be able to speed things up by playing with the cipher used for encrypting the session too by specifying --rsh="ssh -c arcfour" which will use the cheaper than default arcfour cipher.

It's also worth noting that if you're just looking to copy the data (and not identify/copy just the difference) scp should be far faster than rsync. rsync does rolling checksumming and if you're transferring large files that you know will have widespread changes this can save on CPU usage.

James C
  • 804
  • 1
  • 7
  • 8
  • Thanks. It was good to use the `--dry-run`. I suspect now, that the cause lies in some internal routing in the network and I'll grab one of the network guys. – user168022 Apr 05 '13 at 14:02