[EMAIL PROTECTED] wrote:
> Searching through the mail archives, I see lots of posts about getting
> aborts with signal=PIPE on backups. I've got this problem on restore.
>
> I have been backing up 5 machines (linux and windows) using rsyncd
> flawlessly for a few months now.
>
> Thought it was about time to check restoring (backups are useless unless
> they restore!). I had no luck.
>
> I had two types of errors.
>
> The first thing I tried was restoring from the backuppc server (running
> debian testing/lenny) to a ubuntu 7.10 box. There, I got a failure with
> the signal=PIPE error. Responses to questions people have about this
> error during backup say that some big files can cause it. So I retried
> restoring a single small file and got the same result.
>
> I figured I would try restoring a single small file to other hosts on
> the network. I tried another debian box and a winxp box (both of which
> have been happily backed up for months). Both of those fail with
> "unable to read 4 bytes". According to Les Mikesell in a response (to
> someone having this problem on a backup), it means:
>
>> Usually this means that ssh did not authenticate correctly to start the
>> connection. Be sure you have tested the passwordless access running as
>> the backuppc user on the server (the key setup is per-user).
That's if your xfer method is rsync. You can check this by issuing an
ssh command as the backuppc user on the server. I usually do something
like:
ssh -l root client id
to be sure that the command executes correctly on the client without a
password prompt.
> Not sure where to go with that. I have rsyncd daemons running on all
> the hosts being backed up. According to step 5 of the docs, the rsyncd
> approach doesn't use ssh. Do I need to set up a passwordless ssh setup?
> I thought I have read through the docs pretty thoroughly but I haven't
> seen how to do this. I'll check again, but if someone can point me in
> the right direction, that would be helpful.
>
> Is the lack of a passwordless ssh also the cause of the signal=PIPE I
> see going to the ubuntu machine?
If your xfer method is rsyncd, you authenticate with a username and
passsword that must match what is in the secrets file on the client. And
for a restore, this must give you write access to the target. You can
test this by running the command line rsync, using double :'s to
separate the host and path, like:
rsync [EMAIL PROTECTED]::share/path .
or reverse to write. If these succeed, you should have the same access
from backuppc.
--
Les Mikesell
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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/
