Ok, I can of course do what you suggested to do a complete restore. That's fine for now, but will there be a real fix for this problem?
Our old backup server is still somewhere waiting for a new "job", and I will re-check whether the problem is really "new". -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jean-Louis Martineau Sent: Montag, 30. März 2015 19:38 To: Debra S Baddorf; Michael Schmitz Cc: AMANDA users Subject: Re: problem with restoring dump gzipped on client-side 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 isnt 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 doesnt fix it, Jean-Louis. > > > Ive 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 havent 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. >>> >
