A few versions ago, I had this issue too. The newer clients were expecting to do their own decompression, since the client had compressed the dump to start with. But the older server had already DONE a decompress before sending the data. Thus, any backups done with CLIENT compression failed to restore, because the server sent data which was already uncompressed.** When I switched to always doing SERVER compression, those newer clients were happy, because then they didn’t try to do their own decompression.
I had heard that newer versions fixed this, but I still always have the server do the compression (& thus the uncompression ). ** We had a temporary fix, so we could actually restore from dumps previously done with client side compression. Here it is: $ more gzip.null.kludge #!/bin/bash # # null gzip command to fake out amanda when restoring an old dump # from an old amanda server where the server gunzips before sending # and then the client also tries to gunzip the data... which fails # # to use: # cp this-file /usr/bin/gzip.null (if not already in place) # mv /usr/bin/gzip /usr/bin/gzip.real # mv /usr/bin/gzip.null /usr/bin/gzip # amrecover ... # mv /usr/bin/gzip /usr/bin/gzip.null # mv /usr/bin/gzip.real /usr/bin/gzip # /bin/cat > On Nov 1, 2016, at 11:03 AM, Ochressandro Rettinger > <[email protected]> wrote: > > 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]>; > '[email protected]' <[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 > > > >
