Hi,

Matt Chandler wrote on 2008-08-21 13:30:39 -0500 [Re: [BackupPC-users] 
fileListReceive failed on centos 4.4]:
> Matt Chandler wrote:
> > [...]
> > full backup started for directory /
> > Running: /usr/bin/ssh -q -x -l backuppc sinope /usr/bin/sudo /usr/bin/rsync 
> > --server --sender --numeric-ids --perms --owner --group -D --links 
> > --hard-links --times --block-size=2048 --recursive --one-file-system 
> > --ignore-times . /
> > Xfer PIDs are now 26423
> > Got remote protocol 30
> > Negotiated protocol version 28
> > Sent exclude: /media
> > Sent exclude: /mnt
> > Sent exclude: /proc
> > Sent exclude: /sys

this much tells you
- ssh authentication is working (without prompt or extraneous output)
- sudo invocation is working (without prompt or welcome message)
- sudo isn't complaining about requiretty being set ;-).

That's good.

> > Here is the config for that machine:

Thank you for including it. Looks good to me (except that your excludes are
not specific to a share, so you're excluding '/u01/media', '/u01/mnt',
'/u01/proc' and '/u01/sys', but that probably does no harm - it's not the
problem in any case).

> > Both machines have the same version of rsync(rsync-3.0.3-1.el4.rf) and 

Note that BackupPC uses File::RsyncP, so the BackupPC server machine is, in
fact, *not* using 3.0.3. We see a negotiated protocol version 28 above, and
File::RsyncP reportedly works with rsync version 3, so that is *probably* not
the issue, though I wouldn't rule it out completely.

Les Mikesell wrote on 2008-08-21 15:11:25 -0500 [Re: [BackupPC-users] 
fileListReceive failed on centos 4.4]:
> [...]
> Try running the closest 'rsync -essh ...' command you can use 
> from the backuppc server command line as the backuppc user.

Which would be

        rsync -e ssh --numeric-ids --perms --owner --group -D --links \
        --hard-links --times --block-size=2048 --recursive --one-file-system \
        --ignore-times --exclude=/media --exclude=/mnt --exclude=/proc \
        --exclude=/sys root@sinope:/ /tmp/foo

Please note:
We are not testing 'ssh' or 'sudo' - they work (see above). I would actually
run that as root (locally and remote), because you want a full file list to be
generated on the remote side (which probably won't work for user backuppc),
and local warning messages about skipped devices (you aren't excluding /dev -
you might want to ;-) would only be confusing.

You might even want to choose a copy destination below TopDir instead of
/tmp/foo, just to have tested writing to the file system in question, though
BackupPC is quite clearly not getting that far before the error occurs - and
you are going to interrupt the process once it starts anyway (though / is
not the bulk of your 100GB, I suppose). The command does not seem to give any
output, so you'll have to check the copy destination to find out if anything
is happening. Alternatively, you could add '-P' or '-v' switches, but you'd be
changing the command, and that could have an influence on whether it works or
not (probably not, but who knows?).

Regards,
Holger

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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/