Hi,
On Fri, Jul 11, 2008 at 02:52:31PM +0530, Ishan Patel wrote:
> [...]
> BUT I AM NOTABLE TO RESTORE MY DATA THROUGH WEB INTERFACE
first of all, thank you for providing detailed information on your setup.
Unfortunately, the problem seems to be somewhat obscure, so I agree with
Craig that we need some more information from your log files. I don't agree
with Dan, backuppc-users' most notorious top-poster, that he didn't manage
to set up restores, so you shouldn't bother either ...
We can try to clear up some misconceptions though.
> ---->>>this is my /etc/sudoers file's entry
>
> # User privilege specification
> root ALL=(ALL) ALL
> backuppc ALL=NOPASSWD: /bin/tar
That would allow backups and restores through sudo/tar, if BackupPC was
configured to do so (which it is not).
> ---->>> i have done ssh without root passwd configuration by generation
> public/private key for my localhost
>
> i.e i am able to ssh to my own pc with root passwd
>
> proof...
>
> backuppc@ishan:/root$ ssh -l root 192.168.0.96 whoami
> root
> backuppc@ishan:/root$
That is mostly fine - except that for 'localhost' the command would be
ssh -l root localhost
which may ask you to accept the public key of 'localhost' even if the key
has already been accepted for 192.168.0.96. Presuming that also works without
prompt, it would allow backups and restores via ssh, if BackupPC was
configured to do so (which it is also not).
Additionally, I would like to point out that using both 'sudo' and
'ssh -l root' for the same backup is pointless. One or the other will do,
combining both makes no sense. It makes sense however to ssh to a *remote*
host (which you want to backup) as a *non privileged user* and then
use 'sudo' to gain root privileges for a 'tar' or 'rsync' command, because
in this way, you can limit root privileges to the command invocations needed
(you can even allow backups ('tar -c') but disallow restores ('tar -x')). For
a local backup, 'sudo' is preferable over 'ssh', because it saves you the
unnecessary overhead of encryption and the TCP/IP stack (well, and because
you can limit it to 'tar'/'rsync').
> ---->>> my localhost.pl file
>
> backuppc@ishan:/etc/backuppc$ cat localhost.pl
> #
> # Local server backup of /etc as user backuppc
> #
> $Conf{XferMethod} = 'tar';
>
> $Conf{TarShareName} = [
> '/backbpo'
> ];
>
> $Conf{TarClientCmd} = '/usr/bin/env LC_ALL=C $tarPath -c -v -f - -C
> $shareName --totals';
This means you are using *neither sudo nor ssh* for backups. You're simply
running 'tar' locally. This will limit your backups to files readable by
the 'backuppc' user. That's ok for a test scenario, but it won't get you
far later on. Since you've setup 'sudo', you could change that to
$Conf{TarClientCmd} = '/usr/bin/env LC_ALL=C sudo $tarPath -c -v -f -'
. ' -C $shareName --totals';
> # remove extra shell escapes ($fileList+ etc.) that are
> # needed for remote backups but may break local ones
> $Conf{TarFullArgs} = '$fileList';
> $Conf{TarIncrArgs} = '--newer=$incrDate $fileList';
The default value of TarClientRestoreCmd (which you don't seem to be
overriding) seems to be
$Conf{TarClientRestoreCmd} = '$sshPath -q -x -l root $host env LC_ALL=C'
. ' $tarPath ...'; # and so on
i.e. tar over ssh. You'd probably want to change that to
$Conf{TarClientRestoreCmd} = /usr/bin/env LC_ALL=C sudo $tarPath -x -p'
. ' --numeric-owner --same-owner -v -f -'
. ' -C $shareName';
(Disclaimer: I'm not sure if LC_ALL=C will survive 'sudo' or be filtered out
of the environment; take it as a gesture of good will.)
> $Conf{RsyncShareName} = [
> '/backbpo'
> ];
You don't need that one for XferMethod = tar.
> ---->>>
> this is my directory whose backup i m taking
>
> its /backbpo
>
> #ls -l /backbpo
>
> drwxrwxrwx 3 backuppc backuppc 4096 2008-07-11 12:44 backbpo
>
> #cd /backbpo
>
> ls -l
>
> -rwxrwxrwx 1 backuppc backuppc 0 2008-07-10 15:24 3
> -rwxrwxrwx 1 backuppc backuppc 0 2008-07-10 15:24 4
> -rwxrwxrwx 1 backuppc backuppc 0 2008-07-10 15:24 5
> -rwxrwxrwx 1 backuppc backuppc 0 2008-07-10 15:24 6
> drwxrwxrwx 2 backuppc backuppc 4096 2008-07-10 18:27 test
There's not much in those files ... note that there seems to be no file named
'2'.
> AND this is what my backup is
>
> root@ishan:/var/lib/backuppc/pc/localhost/3# ls -l
> total 12
> -rw-r----- 2 backuppc backuppc 24 2008-07-11 13:31 attrib
> -rw-r----- 1 backuppc backuppc 516 2008-07-11 13:31 backupInfo
> drwxr-x--- 3 backuppc backuppc 4096 2008-07-11 13:31 f%2fbackbpo
There's probably also a backup number 2 ...
> i have also tried to give 777 permissions to f%2fbackbpo firectory .. then
> also no help..
You shouldn't do that, and it's definitely not necessary for the backuppc user
to access the files. When you're doing real backups, you definitely don't want
everyone to have full read - let alone write - access on all files in the
backup.
As a side note, if you *only* change the f%2fbackbpo directory and not the
parent directories, your change will have no effect in any case, because
access to a file requires access to the path elements above it.
/var/lib/backuppc and all directories below it should not have any access
for 'others' (i.e. 0xx0 permissions, aka. 'o=').
> ------------->>>
>
> last i have also tried to do something nesty with command line but i m
> getting this error in that also ..
>
> root@ishan:/var/lib/backuppc/pc/localhost/3#
> /usr/share/backuppc/bin/BackupPC_zcat
> /var/lib/backuppc/pc/localhost/2/f%2fbackbpo/f2
> /usr/share/backuppc/bin/BackupPC_zcat: can't open
> /var/lib/backuppc/pc/localhost/2/f%2fbackbpo/f2
What if you change the 2s to 3s?
As far as I remember, zero length files are a special case. They should be
restored correctly, but I don't know if BackupPC_zcat handles them. Try
putting some content into your files, doing a backup and then retry
BackupPC_zcat.
> and do tell me if u want some other information...
On Fri, Jul 11, 2008 at 02:46:04PM -0700, Craig Barratt wrote:
> [...]
> Look in the RestoreLOG file to see exactly what command is being
> run and what the error is.
We need to know more about why BackupPC_tarCreate failed. I wouldn't
normally expect it to fail, even if the restore process lacks the privileges
to restore the files in question.
Regards,
Holger
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
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/
|
