Hi,

Boniforti Flavio wrote on 2009-04-09 14:15:18 +0200 [Re: [BackupPC-users] 
Sending csums, cnt = 0, phase = 1 - Backups stuck!]:
> Still doing trials, I checked both Linux and Windows boxes what version
> of rsync they run.
> 
> Both tell me:
> 
> rsync  version 3.0.5  protocol version 30
> 
> So why is the negotiated protocol "version 28" and not "30"?
> Could this be the actual problem? 

I'm no expert on Windoze backups, but from what I've read on this list the
problem is *not* the difference in rsync versions, but rather the protocol
version 28 being used. You currently can't get around that.

The rsync implementation on the BackupPC server is the Perl module
File::RsyncP, not native rsync. You can install whatever version of rsync you
like (on the BackupPC server - presuming you're not using it for local
backups of the server) or even leave it uninstalled. The only thing of
interest is the rsync(d) on the client to be backed up. Jeffrey's point is
that the problems we've all been reading about or experiencing for so long
with rsync over ssh backups of Windoze clients seem to disappear with protocol
version 30 (which you can only test with native rsync, not BackupPC). Aside
from that, they seem to be less frequent (obviously not non-existant, as your
case shows) with rsyncd on the Windoze side (and, still, File::RsyncP on the
BackupPC server side).

It would be interesting to find out the actual *cause* of the problems. I
wouldn't be surprised if it was not protocol version 28 - why should it, it
works between Unix hosts - or maybe even the Windows rsync implementation
(Cygwin) but rather a detail of option negotiation or option default values.
Maybe there is a workaround available (and maybe there isn't). Maybe
investigating this would be a waste of time. I don't know. Just sharing my
thoughts.


So, to summarize, running rsyncd (!) on the Windoze side seems to be the best
option, but you're already doing that. Remind me, please, which version of
BackupPC and File::RsyncP you are running and what your XferLogLevel is set
to. If possible, try a command line rsync with the '--protocol=28' switch to
see if native rsync has the same issue or not. Possibly add appropriate
switches to increase verbosity. Try to track down on which file it chokes -
if it's a file issue at all and not some general permissions issue or
something like that (which I feel it looks like, but then again, command line
rsync with protocol version 30 would have the same trouble).

I'm sorry that I can't be more helpful. I know how frustrating this kind of
problem is.

Regards,
Holger

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/