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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
