The problem here is the answer you entered to "set owner/mode for '.'?"
is never sent to the dump process, and dump is just waiting for the answer.
The problem is not related to compression.
Some older amrecover version had problem restoring client compressed
backup, but it is fixed in newer release.
Jean-Louis
On 03/30/2015 01:25 PM, Debra S Baddorf wrote:
On Mar 30, 2015, at 11:33 AM, Jean-Louis Martineau <[email protected]> wrote:
On 03/30/2015 04:05 AM, Michael Schmitz wrote:
Hi all,
I've been using Amanda v2.5 for years an switched to v3.3.6 on freshly
installed FC21 server and all clients (SLES11) a few days ago. My configuration
contains the definition
define dumptype my-dump {
global
auth "ssh"
ssh_keys "/var/lib/amanda/.ssh/id_rsa"
program "DUMP"
index
priority high
compress client fast
}
and disklist entry like
foo.bar.com /home1 my-dump
Backing up works like a charm, but now I tried to restore a directory from
foo.bar.com:/home1 locally on my server:
# amrecover -C daily
AMRECOVER Version 3.3.6. Contacting server on 10.2.19.3 ...
220 amanda AMANDA index server (3.3.6) ready.
...
amrecover> sethost foo.bar.com
amrecover> setdate 2015-03-20
amrecover> setdisk /home1
amrecover> add ako
amrecover> lcd /tmp/amanda
amrecover> extract
Extracting files using tape drive changer on host 10.2.19.3.
The following tapes are needed: daily-23
daily-2
Extracting files using tape drive changer on host 10.2.19.3.
Load tape daily-23 now
Continue [?/Y/n/s/d]? y
Restoring files into directory /tmp/amanda
All existing files in /tmp/amanda can be deleted
Continue [?/Y/n]? y
set owner/mode for '.'? [yn] y
And this is where my trouble begins! Some files have been successfully restored, but my response
"y" is not processed. I see some zombie processes in the process table. Pressing Ctrl-C
terminates the entire restore. I don't really care too much about the permissions, but
"amrecover" didn't pick the second tape!
Redo the restore with amrecover, but skip (s) the level 0 backup and extract
only the level 1 backup.
Kill the dump process instead of amrecover when it ask to set owner/mode.
Jean-Louis
i.e. This is how to proceed from NOW, in order to get that second tape.
(As I understand it?)
It isn’t how to fix the original problem, or how not to have a problem for the
NEXT recover that you do.
And actually — if the original backup was on two tapes, the above still
doesn’t fix it, Jean-Louis.
I’ve seen that problem too. I think it is related to whether the host or
the client had done
the original compression. I have all my compression done on the server
just because of this issue.
I haven’t check lately as to WHETHER the problem has gone away; I just
always compress on the
server, because the problem cropped up when I first went to which ever version
caused it. Per your
experiences, apparently the problem is still there …….
Deb Baddorf
Fermilab
First I tried with my password-less SSH setup, which worked fine in the past, later I
switched to "bsdtcp", but this doesn't make any difference.
What's the problem and - even more important - what can I do?
Best regards,
Michael.
