Re: Problems with amrecover, no error messages
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
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
Problems with amrecover, no error messages
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
