subject:"Re\: problems with amrecover"

Re: Problems with amrecover in 2.4.5p1

2006-02-21 Thread Stephen Carville


Paul Bijnens wrote:

On 2006-02-21 09:25, Stephen Carville wrote:

My attempt to restore files with amrecover keep failing since I 
upgraded to 2.4.5.  The output in amidxtaped.debug looks like:


amidxtaped: debug 1 pid 14962 ruid 250 euid 250: start at Mon Feb 20 


[...]


amrestore: could not open /dev/ait2: Permission denied
amidxtaped: time 0.004: amrestore terminated normally with status: 2
amidxtaped: time 0.004: rewinding tape ...
amidxtaped: time 0.004: tape_rewind: tape open: /dev/ait2: Permission 
denied

amidxtaped: time 0.005: pid 14962 finish time Mon Feb 20 20:33:06 2006



My first question then is, what are the permissions of /dev/ait2,
and what are the user/group you are using for starting amidxtaped in
(x)inetd.


Sound of palm slapping forhead...That was it.

/dev/ait2 is a symlink to /dev/nst0.  I checked the old server and the 
permissions there were:


crw-rw-r--1 root disk   9, 128 Aug 30  2001 /dev/nst0

On the new server:

crw-rw  1 root disk 9, 128 Feb 19 11:53 /dev/nst0

Once I added the global read, amrecover worked again.  I don't know how 
many time I looked at those permissions wihtseeing the problem.


Thanks

--
Stephen Carville -- polluting the ranks of skeptics since 1995.
---
Government is actually the worst failure of civilized man. There has 
never been a really good one, and even those that are most tolerable are 
arbitrary, cruel, grasping and unintelligent.

 -- H. L. Mencken

Re: Problems with amrecover in 2.4.5p1

2006-02-21 Thread Paul Bijnens


On 2006-02-21 09:25, Stephen Carville wrote:
My attempt to restore files with amrecover keep failing since I upgraded 
to 2.4.5.  The output in amidxtaped.debug looks like:


amidxtaped: debug 1 pid 14962 ruid 250 euid 250: start at Mon Feb 20 

[...]

amrestore: could not open /dev/ait2: Permission denied
amidxtaped: time 0.004: amrestore terminated normally with status: 2
amidxtaped: time 0.004: rewinding tape ...
amidxtaped: time 0.004: tape_rewind: tape open: /dev/ait2: Permission 
denied

amidxtaped: time 0.005: pid 14962 finish time Mon Feb 20 20:33:06 2006


My first question then is, what are the permissions of /dev/ait2,
and what are the user/group you are using for starting amidxtaped in
(x)inetd.




This makes no sense to me since I was able to recover the files using 
amrestore on the server.


amrestore runs as root, but amidxtaped runs as amanda usually.
If the permissions of /dev/ait2 are group readable, maybe you need
to add "groups = yes" in xinetd.conf to enable the additional groups
that user amanda is in.


--
Paul Bijnens, xplanation Technology ServicesTel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +32 16 397.512
http://www.xplanation.com/  email:  [EMAIL PROTECTED]
***
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out  *
***

Re: Problems with amrecover, no error messages

2004-11-22 Thread Sylvia Gelman

Hi Jon,
first of all, many thanks for your answer. I was so confused that I even didn´t try a
stupid find over the maschine. Ok, ... I found the file. My error in reasoning was that I
thought I can change in the directory where to recover to after running amrecover with lcd.

Thank you very much for your help!
Sylvia
Sorry for not chopping things down.
It looks to me like things worked as they should
but that your expectations were not accurate.
Suppose I have a disk-list entry (DLE) of "/foo/bar",
the "bar" directory is the "root" of my DLE
(amrestore calls it a filesystem).
Suppose I want to recover a file /foo/bar/proj/abc/target,
that file gets backed up as "./proj/abc/target" relative
to the "root" of my DLE.
However, it comes back from the recovery relative to
WHATEVER directory you run amrecover from. I typically
run amrecover from a newly created directory, such as
/tmp/recover. In that case, the file will recover to
/tmp/recover/proj/abc/target, not under /foo/bar. If
I really wanted it back in the original place I would
have to run amrecover from /foo/bar. I don't like to
do that because a human error might trash other things.
I like to recover first, then copy to real destination.
I looks like you ran amrecover from the mysql directory:

client2:/var/lib/mysql # /usr/sbin/amrecover bac -s srv -t srv -d

But your DLE was /var:

Trying disk /var ...
$CWD '/var/lib/mysql' is on disk '/var' mounted at '/var'.
200 Disk set to /var.
/var/lib/mysql
WARNING: not on root of selected filesystem, check man-page!

Thus, you were not at the "root of the selected DLE":
Then you asked to recover /var/lib/mysql/fulldump.sql.040930

amrecover> add fulldump.sql.040930

And it seems to have been recovered:

Continue [?/Y/n/s/t]? Y
./lib/mysql/fulldump.sql.040930

But, because you were not in /var, but in /var/lib/mysql,
it probably came back as /var/lib/mysql/lib/mysql/fulldump.sql.040930.
^^^
--
Sylvia Gelman Telefon: 06151-16-5261
TU-DarmstadtTelefax: 06151-16-2507
Institut fuer Automatisierungstechnik - IAT
FG Regelungstheorie und Robotik
Raum S3|10 529 Email:[EMAIL PROTECTED]
Landgraf-Georg-Str. 4 Systemadministratorin
64283 Darmstadt

Re: Problems with amrecover, no error messages

2004-11-22 Thread Jon LaBadie

On Mon, Nov 22, 2004 at 11:17:27AM +0100, Sylvia Gelman wrote:
> Hi,
> 
> I had similar Problems to Toralf Lund (13.10.2004), after setting chunksize 
> to 1GB it seems ok and I didn´t get anymore the following error messages:
> 
> invalid sparse archive member
> tar: Skipping to next header
> 
> But unfortunatly I can´t recover any file and I don´t get any error 
> messages. Really strange ...
> Hope someone can help. Please ask if you need more details.
> 
> Thanks for any help
> 
> Sylvia
> 
> P.S. By the way what means the WARNING: not on root of selected filesystem, 
> check man-page! ?
> 
> client2:/var/lib/mysql # /usr/sbin/amrecover bac -s srv -t srv -d 
> /dev/rmt/0n
> AMRECOVER Version 2.4.4p1. Contacting server on srv ...
> 220 srv AMANDA index server (2.4.4p3) ready.
> 200 Access OK
> Setting restore date to today (2004-11-22)
> 200 Working date set to 2004-11-22.
> Scanning /export/opt/hold...
> Scanning /hold...
> 200 Config set to bac.
> 200 Dump host set to client2.
> Trying disk /var ...
> $CWD '/var/lib/mysql' is on disk '/var' mounted at '/var'.
> 200 Disk set to /var.
> /var/lib/mysql
> WARNING: not on root of selected filesystem, check man-page!
> amrecover> setdate 2004-11-21
> 200 Working date set to 2004-11-21.
> amrecover> sethost client2
> 200 Dump host set to client2.
> amrecover> setdisk /var
> 200 Disk set to /var.
> amrecover> cd lib/mysql
> /var/lib/mysql
> amrecover> add fulldump.sql.040930
> Added /lib/mysql/fulldump.sql.040930
> amrecover> lpwd
> /var/lib/mysql
> amrecover> extract
> 
> Extracting files using tape drive /dev/rmt/0n on host srv.
> The following tapes are needed: bac-012
> 
> Restoring files into directory /var/lib/mysql
> Continue [?/Y/n]? Y
> 
> Extracting files using tape drive /dev/rmt/0n on host srv.
> Load tape bac-012 now
> Continue [?/Y/n/s/t]? Y
> ./lib/mysql/fulldump.sql.040930
> amrecover> quit
> 200 Good bye.
> 
> client2: more /tmp/amanda/amrecover.20041122104426.debug
> -snip-
> cd_glob (lib/mysql) -> ^lib/mysql$
> add_dir_list_item: Adding "2004-11-21" "0" "bac-012" "5" "/lib/mysql/."
> add_dir_list_item: Adding "2004-11-21" "0" "bac-012" "5" "/lib/mysql/demo/"
> add_dir_list_item: Adding "2004-11-21" "0" "bac-012" "5" 
> "/lib/mysql/fulldump.sql"
> add_dir_list_item: Adding "2004-11-21" "0" "bac-012" "5" 
> "/lib/mysql/fulldump.sql.040930"
> -snip-
> add_glob (fulldump.sql.040930) -> ^fulldump\.sql\.040930$
> add_file: Looking for "fulldump\.sql\.040930[/]*$"
> add_file: Converted path="fulldump\.sql\.040930[/]*$" to 
> path_on_disk="\/lib\/mysql/fulldump\.sql\.040930[/]*$"
> add_file: Pondering ditem->path="/lib/mysql/."
> add_file: Pondering ditem->path="/lib/mysql/demo/"
> add_file: Pondering ditem->path="/lib/mysql/fulldump.sql"
> add_file: Pondering ditem->path="/lib/mysql/fulldump.sql.040930"
> add_file: (Successful) Added /lib/mysql/fulldump.sql.040930
> -snip-
> amrecover: stream_client_privileged: connected to 130.83.28.5.10083
> amrecover: stream_client_privileged: our side is 0.0.0.0.563
> amrecover: try_socksize: receive buffer size is 65536
> Exec'ing /bin/tar with arguments:
> tar
> -xpGvf
> -
> ./lib/mysql/fulldump.sql.040930
> amrecover: pid 15478 finish time Mon Nov 22 10:54:13 2004
> 

Sorry for not chopping things down.
It looks to me like things worked as they should
but that your expectations were not accurate.

Suppose I have a disk-list entry (DLE) of "/foo/bar",
the "bar" directory is the "root" of my DLE
(amrestore calls it a filesystem).

Suppose I want to recover a file /foo/bar/proj/abc/target,
that file gets backed up as "./proj/abc/target" relative
to the "root" of my DLE.

However, it comes back from the recovery relative to
WHATEVER directory you run amrecover from.  I typically
run amrecover from a newly created directory, such as
/tmp/recover.  In that case, the file will recover to
/tmp/recover/proj/abc/target, not under /foo/bar.  If
I really wanted it back in the original place I would
have to run amrecover from /foo/bar.  I don't like to
do that because a human error might trash other things.
I like to recover first, then copy to real destination.

I looks like you ran amrecover from the mysql directory:

> client2:/var/lib/mysql # /usr/sbin/amrecover bac -s srv -t srv -d 

But your DLE was /var:

> Trying disk /var ...
> $CWD '/var/lib/mysql' is on disk '/var' mounted at '/var'.
> 200 Disk set to /var.
> /var/lib/mysql
> WARNING: not on root of selected filesystem, check man-page!

Thus, you were not at the "root of the selected DLE":

Then you asked to recover /var/lib/mysql/fulldump.sql.040930

> amrecover> add fulldump.sql.040930

And it seems to have been recovered:

> Continue [?/Y/n/s/t]? Y
> ./lib/mysql/fulldump.sql.040930

But, because you were not in /var, but in /var/lib/mysql,
it probably came back as /var/lib/mysql/lib/mysql/fulldump.sql.040930.
  ^^^

-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computin

48 matches

Mail list logo