I'm putting into place a multi-server geographically separated backup system to protect my data (mainly my email, photos and mp3 files).

My choosen tool is rsync over ssh, I am backing up one Linux box and one Win2k box onto a remote server. At the moment the remote server is in fact just sitting by my desk, I'm still busy doing the initial sync of 30Gb of data before moving the server to the remote location.

I'm having problems with rsync on Win2k. I'm using the version that comes as part of the cygwin tools.

If I drive things from the Linux box the sync starts fine and runs for a couple of minutes. After a couple of minutes though the sync always stops, no error messages from rsync, it just freezes.

If I drive things from the Win2k box there are no freezes. However the transfer is many times slower that when driving it from the Linux box (or between two Linux boxes). It is so painfully slow that it makes it essentially unusable. I worked out I would still be doing my initial sync sometime next week !

I've found a work round for the moment. I am exporting the data on the Win2k box to the local Linux box via smbclient and then using rsync between the two Linux boxes. This doesn't freeze and runs nice and fast.

It will work for now, but it would be nice to do things "properly" :-(

It sounds bizarre, but lower the priority of the ssh process (using Windows Task Manager). It makes it go much quicker, and actually work.

Or it might be the rsync process that needs lowering. Try them. Alternatively, grab a copy of PuTTY and try using plink.exe from that instead of ssh. I've had good results with that, too.

It sounds bizarre, but lower the priority of the ssh process (using Windows Task Manager). It makes it go much quicker, and actually work

Interesting. Is there a way of lowering the priority of a process via the command line ?

Interesting. Is there a way of lowering the priority of a process via the command line ?

I don't know about changing the priority of an already-running process via the command line, but to start a command-line program at low priority, this works:

start /B /LOW program.exe

/LOW can be replaced with /BELOWNORMAL if /LOW is too.. low.

You can use 'nice' from Cygwin. That ought to do it. You'll need something like:

rsync -e 'nice ssh' the-rest-of-the-command

...probably.

The problem is that I want to drive the sync from the Linux box. Not sure how I can convince the Windows box that the ssh server should get run with low priority.

Ah, then your problem is the other way round from mine -- I use the Windows box as the client side, so this is fine.

How are you running sshd? As a daemon, or through inetd (I assume Cygwin's got one), or something else?

One thing you can try is (from the Linux box):

rsync -e ssh --rsync-path='nice rsync' the-rest-of-the-options

The '--rsync-path' switch tells it which application to run on the other end -- it's supposed to be used if your binary is not in $PATH.

How are you running sshd? As a daemon, or through inetd (I assume Cygwin's got one), or something else?

When you ask cygwin to make sshd listen it wraps sshd.exe up in something and installs it as an NT service. The end result being that sshd.exe effectively listens on port 22.

For the moment I am going to leave things as they are, rsyncing from a Samba share using the local Linux box. I'll come back and try and fix this "properly" some other time...

...the limiting speed is always going to be the ADSL line connecting the servers anyway.

I've found a work round for the moment. I am exporting the data on the Win2k box to the local Linux box via smbclient and then using rsync between the two Linux boxes. This doesn't freeze and runs nice and fast.

Instead of copying the data using smbclient, you could smbmount the win2k data and have the Linux box export it without copying. I have used this method to mirror gigabytes of data from an NT server to a Linux box over a 128k link without any problem.

Pim

That is in fact what I am doing, I had just missed the distinction between smbmount and smbclient...