I tried to recover 4 or 5 times. It failed each time.
I only ran one backup of that type, but amcheckdump said it was
a good dump. I could try again.
-Sandro
From: Jean-Louis Martineau [mailto:[email protected]]
Sent: Tuesday, November 01, 2016 9:50 AM
To: Ochressandro Rettinger <[email protected]>;
'[email protected]' <[email protected]>
Subject: Re: amrecover problems on compressed DLEs
client compressed dump are decompressed by amrecover
server compressed dump are decompressed by amidxtaped (on the server)
I tried many recovery with client compressed dump and it never hanged.
Do you tried it once or many times?
Knowing if it always fail or sometimes fail can help.
Jean-Louis
On 01/11/16 11:40 AM, Ochressandro Rettinger wrote:
Since you asked about server vs: client compression, I decided
to try server side compression instead. And, because my life just isn't weird
enough, it worked.
When I look at the amidxtaped.debug file for the process that
worked on recovery from server compressed tape, I see that it appears as
though amidxtaped itself is spawning a gzip process, and when I look at the
amidxtaped.debug file for the process that hung forever, I see no similar
message. Also, it appears that amidxtaped is simply aware of more needed
steps, for the server compressed backups.
Tue Nov 01 09:17:14.081375699 2016: pid 153615: thd-0x19b6400: amidxtaped:
Starting <Xfer@0x28f64e0 (<XferSourceRecovery@0x24fc000> ->
<XferFilterProcess@0x28fb010> -> <XferFilterCrc@0x293d030> ->
<XferDestFd@0x293d0e0>)>
Tue Nov 01 09:17:14.081424025 2016: pid 153615: thd-0x19b6400: amidxtaped:
Final linkage: <XferSourceRecovery@0x24fc000> -(PULL_BUFFER)->
<XferElementGlue@0x2976040> -(READFD)-> <XferFilterProcess@0x28fb010>
-(WRITEFD)-> <XferElementGlue@0x2976170> -(PUSH_BUFFER_STATIC)->
<XferFilterCrc@0x293d030> -(PUSH_BUFFER_STATIC)-> <XferElementGlue@0x29762a0>
-(WRITEFD)-> <XferDestFd@0x293d0e0>
Vs:
Sat Oct 29 14:18:46.905301215 2016: pid 98917: thd-0x2653600: amidxtaped:
Starting <Xfer@0x35a5e20 (<XferSourceRecovery@0x3199000> ->
<XferDestFd@0x3583820>)>
Sat Oct 29 14:18:46.905335006 2016: pid 98917: thd-0x2653600: amidxtaped: Final
linkage: <XferSourceRecovery@0x3199000> -(PULL_BUFFER)->
<XferElementGlue@0x3613030> -(WRITEFD)-> <XferDestFd@0x3583820>
-Sandro
From: Jean-Louis Martineau [mailto:[email protected]]
Sent: Monday, October 31, 2016 2:53 PM
To: Ochressandro Rettinger
<[email protected]><mailto:[email protected]>;
'[email protected]<mailto:[email protected]>'
<[email protected]><mailto:[email protected]>
Subject: Re: amrecover problems on compressed DLEs
You are doing client or server compression?
The backup was done with 3.4 or 3.3.?
Can you post the complete amrecover and amidxtaped debug files.
Jean-Louis
On 31/10/16 03:51 PM, Ochressandro Rettinger wrote:
I'm running Amanda 3.4 (3.4.1?) from the zmanda RPM, on an RHEL
7.2 machine. My client is an RHEL 6.8 machine, running the same generation of
client, also from the zmanda RPM.
My disklist file was as follows:
backuptest /slash / {
comp-gnutar-ssh
exclude append "./boot"
exclude append "./var"
}
backuptest /boot gnutar-ssh
backuptest /var comp-gnutar-ssh-full
with the thought that everything in /boot is compressed already
anyway, and wanting to test the idea of splitting DLEs up and use different
backup methods and the like.
Well, the backup went OK, and running amcheckdump on the backup
showed as OK, but when I went to recover, attempting to recover /slash for
example, it would start trying to extract the files, and then just hang
forever. (Forever in this case being defined as 24 hours.) However, when I
tried to recover the /boot DLE, that actually worked. So, I changed my DLEs to
all be just plain "gnutar-ssh" type, re-ran the backup, and then attempted to
recover again, and was successful recovering.
I ran "ps -ef" while the amrecover process was hung, and saw
that it had spawned a "gzip -dc" process. So, I presume it was trying to pipe
compressed data to that process, but somehow, either before or afterwards, it
was getting lost on its way to the tar process. Indeed, looking at the debug
file, I see "amrecover: Spawning "/usr/bin/gzip /usr/bin/gzip -dc" in pipeline".
The last thing in the debug file is "amrecover:
send_to_tape_server: DATA-READY" until I hit ctrl-C in the amrecover window, at
which point a "QUIT" was sent by amrecover, presumably to the amandad process
that it was connected to.
Any thoughts on why this wouldn't be working? Any thoughts on
other things I can look at?
-Sandro
