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.
^^^^^^^^^^^^^^^^^^^
