Amanda-Users

Re: Problems with amrecover, no error messages

2004-11-22 11:18:29
Subject: Re: Problems with amrecover, no error messages
From: Jon LaBadie <jon AT jgcomp DOT com>
To: amanda-users AT amanda DOT org
Date: Mon, 22 Nov 2004 11:08:30 -0500
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                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)

<Prev in Thread] Current Thread [Next in Thread>