Backuppc fails to transfer

bigsqueaks · 02-20-2008, 02:32 AM

I think backuppc is configured properly. I have a backuppc user on the server with his public key in authorized_keys2 of the root user on the client.

My server is squeaks-laptop, 192.168.0.104. The client is bart-laptop 192.168.0.101.

The backups fail with error "Got fatal error during xfer (Unable to read 4 bytes)". Here is the output of the debug command run on the server:

Code:

backuppc@squeaks-laptop:/usr/share/backuppc/bin$ ./BackupPC_dump -v -f 192.168.0.101
cmdSystemOrEval: about to system /bin/ping -c 1 192.168.0.101
cmdSystemOrEval: finished: got output PING 192.168.0.101 (192.168.0.101) 56(84) bytes of data.
64 bytes from 192.168.0.101: icmp_seq=1 ttl=64 time=2.53 ms

--- 192.168.0.101 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.539/2.539/2.539/0.000 ms

cmdSystemOrEval: about to system /bin/ping -c 1 192.168.0.101
cmdSystemOrEval: finished: got output PING 192.168.0.101 (192.168.0.101) 56(84) bytes of data.
64 bytes from 192.168.0.101: icmp_seq=1 ttl=64 time=2.63 ms

--- 192.168.0.101 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.635/2.635/2.635/0.000 ms

CheckHostAlive: returning 2.635
full backup started for directory /home/bart
started full dump, share=/home/bart
Running: /usr/bin/ssh -q -x -l root \$hostip /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --ignore-times . /home/bart/
Xfer PIDs are now 9010
xferPids 9010
Read EOF: Connection reset by peer
Tried again: got 0 bytes
Done: 0 files, 0 bytes
Got fatal error during xfer (Unable to read 4 bytes)
cmdSystemOrEval: about to system /bin/ping -c 1 192.168.0.101
cmdSystemOrEval: finished: got output PING 192.168.0.101 (192.168.0.101) 56(84) bytes of data.
64 bytes from 192.168.0.101: icmp_seq=1 ttl=64 time=2.08 ms

--- 192.168.0.101 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.084/2.084/2.084/0.000 ms

cmdSystemOrEval: about to system /bin/ping -c 1 192.168.0.101
cmdSystemOrEval: finished: got output PING 192.168.0.101 (192.168.0.101) 56(84) bytes of data.
64 bytes from 192.168.0.101: icmp_seq=1 ttl=64 time=2.57 ms

--- 192.168.0.101 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.570/2.570/2.570/0.000 ms

CheckHostAlive: returning 2.570
Backup aborted (Unable to read 4 bytes)
dump failed: Unable to read 4 bytes

Here is the XferLOG.bad

Code:

full backup started for directory /home/bart
Running: /usr/bin/ssh -q -x -l root \$hostip /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --ignore-times . /home/bart/
Xfer PIDs are now 9172
Read EOF: Connection reset by peer
Tried again: got 0 bytes
Done: 0 files, 0 bytes
Got fatal error during xfer (Unable to read 4 bytes)
Backup aborted (Unable to read 4 bytes)

Here is proof I got the rsa keys setup correctly. I log into the client from my backuppc user on the server.

Code:

backuppc@squeaks-laptop:/usr/share/backuppc/bin$ ssh root@bart-laptop whoami
root

I'm really at a loss for what I can try next. My unable to read bytes error is supposed to be caused by ssh problems.

Can anyone help?

-Nathan

bigrigdriver · 02-20-2008, 03:10 AM

I may be off base here, but I see:
a) successful ping of the client.
b) start the ssh process.
c) process PID is assigned.
d) process fails.

I don't see indication of successful connection. You indicate that the root user of the server is identified in a file on the client, but I don't see anything in the ssh command that tells either the server or the client to use that file. See -i identity_file in the man mages.

bigsqueaks · 02-20-2008, 03:30 AM

Quote:

You indicate that the root user of the server is identified in a file on the client, but I don't see anything in the ssh command that tells either the server or the client to use that file. See -i identity_file in the man mages.

On the client, in the root user's .ssh directory, authorized_keys2 file contains the public key of the server's user backuppc. The private key is on the server as .../backuppc/.ssh/id_rsa, which is the default if -i identity_file is not specifide. So the option to pick the identity file (a different private key) is not required. (I don't know if backuppc supports this option to ssh, it might).

You're right, I don't see evidence of a successful connection either. However, when testing an ssh from server to client root, I showed that it works with no password entry, therefore using the keys. I don't know why it should fail when backuppc runs a more complicated command.

Does anyone know a verbose option that I could use to debug this?

-Nathan

bigrigdriver · 02-20-2008, 04:28 AM

I see that you state that you put the server's public key on the client. Did you also put the client's public key on the server?

http://backuppc.sourceforge.net/faq/ssh.html, read the section labeled Key exchange.

Your verbose option: http://backuppc.wiki.sourceforge.net/Troubleshooting.

bigsqueaks · 02-20-2008, 12:50 PM

Yes, the client's key is on the server's .../backuppc/.ssh/known_hosts.

It was either pasted there by me, or when I ssh root@client from server, I accepted the host key. In any case, root/.ssh/id_rsa.pub is in the known_hosts.

Success with ssh using commandline from server to client indicates that all authentication is working doesn't it?

bunadm · 02-20-2008, 01:53 PM

http://www.pcc-services.com/sles/backuppc4.html <-- great howto

Can you connect from server to client using this command? (without being prompted for a password)

ssh -q -x -l root CLIENTHOSTNAME-OR-IP

Another post that might help:

http://www.linuxquestions.org/questi...light=backuppc

bunadm · 02-20-2008, 01:56 PM

After looking over the command being used above:

/usr/bin/ssh -q -x -l root \$hostip

I dont think $HOSTIP should have the slash in front of it. I am not at home to check mine, but I can POST mine later.

bigsqueaks · 02-20-2008, 05:48 PM

FIXED!

Turns out the advice at http://www.howtoforge.com/linux_backuppc_p3
had bad advice:

Quote:

rsync will be tunneled through SSH (port 22). SSH needs to know the hostname or IP address of the client. Unless you have a DNS server that resolves falko-desktop to its IP address, SSH will not be able to resolve the name falko-desktop. Therefore we replace $host with $hostIP in $Conf{RsyncClientCmd} and $Conf{RsyncClientRestoreCmd}.

I'm writing to the author.