Backup Central

I am not sure whether to file this as a bug against debian or if I am
doing something wrong

using rdiff-backup 0.13.4
from debian/backports

server1 backing up to backups

backup works ok

backups$ rdiff-backup --list-changed-since 5D home/mjb
works fine

restore from backups on backups

backups$ rdiff-backup -r 1D rdiffdir/home/mjb/update-aide
rdiffdir/home/mjb/newaide

works fine and the file newaide is the version from one day ago
however
on server1

server1$ rdiff-backup -r 1D backups::/rdiffdir/home/mjb/update-aide
/home/mjb/newaide fails

rdiff-backup --test-server backups::/rdiffdir Testing
server started by: ssh -C backups rdiff-backup --server
Server OK

error from the restore

rdiff-backup -r 1D backups::/rdiffdir/home/mjb/update-aide /home/mjb/newaide
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File
"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/Main.py",
line 259, in Main
File
"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/Main.py",
line 239, in take_action
File
"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/Main.py",
line 451, in Restore
AssertionError
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File
"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/Main.py",
line 259, in Main
File
"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/Main.py",
line 227, in take_action
File
"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/connection.py",
line 352, in Server
File
"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/connection.py",
line 314, in get_response
File
"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/connection.py",
line 230, in _get
rdiff_backup.connection.ConnectionReadError: Truncated header string
(problem probably originated remotely)

I have checked server logs on backups and cant find anything that shows
any rdiff problems

can anyone point me in the right direction

begin quotation of Mal Beaton on 2004-10-11 13:53:36 +1000:

backup works ok

backups$ rdiff-backup --list-changed-since 5D home/mjb
works fine

restore from backups on backups

backups$ rdiff-backup -r 1D rdiffdir/home/mjb/update-aide
rdiffdir/home/mjb/newaide

works fine and the file newaide is the version from one day ago
however
on server1

server1$ rdiff-backup -r 1D backups::/rdiffdir/home/mjb/update-aide
/home/mjb/newaide fails

Do you usually do backups over ssh? Was the successful restore from a
local copy of the archive, an NFS mount, or something else?

rdiff-backup --test-server backups::/rdiffdir Testing
server started by: ssh -C backups rdiff-backup --server
Server OK

error from the restore

<snip>

"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/connection.py",
line 230, in _get
rdiff_backup.connection.ConnectionReadError: Truncated header string
(problem probably originated remotely)

Are you using the same version locally and remotely?

Alec Berryman wrote:

begin quotation of Mal Beaton on 2004-10-11 13:53:36 +1000:


backup works ok

backups$ rdiff-backup --list-changed-since 5D home/mjb
works fine

restore from backups on backups

backups$ rdiff-backup -r 1D rdiffdir/home/mjb/update-aide
rdiffdir/home/mjb/newaide

works fine and the file newaide is the version from one day ago
however
on server1

server1$ rdiff-backup -r 1D backups::/rdiffdir/home/mjb/update-aide
/home/mjb/newaide fails



Do you usually do backups over ssh? Was the successful restore from a
local copy of the archive, an NFS mount, or something else?


Yes to ssh. Local restor successful. the test to the backups server via
ssh is succesful as shown below. doing a local restore on the backups
server is successful



rdiff-backup --test-server backups::/rdiffdir
Testing server started by: ssh -C backups rdiff-backup --server
Server OK

error from the restore



<snip>


"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/connection.py",
line 230, in _get
rdiff_backup.connection.ConnectionReadError: Truncated header string
(problem probably originated remotely)



Are you using the same version locally and remotely?


yes both servers are using
rdiff-backup 0.13.4
from debian/backports




------------------------------------------------------------------------

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Mal Beaton <mal < at > mbeaton.id.au> writes:
"/home/tretkowski/rdiff-backup/rdiff-backup-0.13.4/debian/rdiff-backup/usr/lib/python2.2/site-packages/rdiff_backup/connection.py",
line 230, in _get
rdiff_backup.connection.ConnectionReadError: Truncated header
string (problem probably originated remotely)

this error in my experience usually means the network connection
has dropped unexpectedly, which isn't terribly useful since anything
causing the server process to suddenly die would close down the
network connection.

can the remote backup client successfully list increments on the server?
also, try a network restore over ssh from the backup server to itself.

could there be a permissions problem, such as the local user running the
restore not having permission to write to the restore destination?

are the remote backup and restore attempts both using the
same userid on the server? is this also the userid that can successfully
do a local restore on the server? do the permissions and ownerships
on the backups and restore target area look sane?

if you can, see how far the ssh connection gets;
does a login successfully happen on the server during the
restore attempt?

if none of this helps, try strace'ing the client restore to see what
is going on when things die, and if that still doesn't help, strace a
local restore on the backup server and see where the two differ.

there should be some way to strace the server process invoked by the
remote client while it runs; I've never had to do that, but if I
needed to, I'd try some kludge like attaching strace to the sshd and
having it follow process forks (-f and -ff options), or replacing the
rdiff-backup executable with a bash script that runs the program under
strace (while passing all the arguments).


--best of luck
--akb