Hi,
Michael Aram wrote on 2009-07-29 15:57:31 +0200 [[BackupPC-users] Backup fails]:
> [...]
> Unfortunately, the backup seems to "hang".
> [...]
> By issuing on the command line (for testing):
> --------------------------------------------------------------------------------------------------
> /usr/bin/ssh -v -l backuppc servertobackup.example.com sudo /usr/bin/rsync
> --server --sender --numeric-ids --perms --owner --group -D --links
> --hard-links --times --block-size=2048 --recursive --ignore-times . /
> --------------------------------------------------------------------------------------------------
>
> the command is sent to the server and nothing happens. I guess this is
> normal because the command will need its time on the other side.....
no, it's normal, because you are starting an rsync server, which will wait for
you to be a client side rsync and talk rsync protocol with it. Chances are,
you won't. Let's ignore that for the moment, because it's not the problem.
> But unfortunately, when triggering the same command via the backuppc
> webinterface - after 2 hours - the backup fails with these logs:
> [...]
> ############# XFER LOG #####################################################
>
> Contents of file /var/lib/backuppc/pc/servertobackup.example.com
> /XferLOG.bad.z, modified 2009-07-29 11:54:21
>
> full backup started for directory /
> Running: /usr/bin/ssh -v -x -l backuppc servertobackup.example.com
'ssh -v' is one problem to begin with (possibly the only one, I don't know
what your RsyncClientCmd was to begin with - it should have been the default,
maybe with an added 'sudo').
> sudo /usr/bin/rsync --server --sender --numeric-ids --perms --owner
> --group -D --links --hard-links --times --block-size=2048 --recursive
> --ignore-times . /
> Xfer PIDs are now 2309
> Got remote protocol 1852141647
This is an indication of the problem. You should be seeing a number between
maybe 26 and 30 here. Try translating this long integer into a byte sequence.
You get 'Open' (perl -e 'print pack ("L", 1852141647), "\n";'), which is not
surprising, because that is what BackupPC gets to see where it should see an
rsync version number:
> Fatal error (bad version): OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL
> 0.9.8g 19 Oct 2007
Once again, there *must not* be *any* extraneous output generated by the login
process. 'ssh -v' is wrong. So are any .bashrc files (or whatever) that output
*anything* at all. Your command above ...
> /usr/bin/ssh -l backuppc servertobackup.example.com sudo ls -al
... is not a bad test, but it's hard to make absolutely clear what you should
see, because people tend to ignore what they think seems normal, and the exact
output of the command will vary. Try something like this instead:
% ssh -q -x -l backuppc servertobackup.example.com sudo echo hello
hello
%
You should - except for your shell prompt, which may look different, and the
indentation - see exactly what you see above. One more linefeed, any kind of
welcome message, any kind of prompt (for password or confirmation), and things
*will* go wrong.
> What can I do? How can I debug this?
Stop debugging it ;-). If anything goes wrong with the standard settings, let
us know what happens then. We can currently only see that ssh's '-v' switch is
getting in the way - of the backup, and, paradoxically, of debugging.
Regards,
Holger
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
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/
