Older server always do the decompression.
In newer version (3.3.x), server compression is decompressed on the
server and client compression is decompressed on the client.
This bug is fixed in 3.3.6
Jean-Louis
On 01/21/2015 03:41 AM, Schoepflin, Markus wrote:
Hello,
I'm facing an odd problem when using custom compressed tar archives:
amrecover fails to extract them when using client version 3.3.1, but it
works without problems on another client which is using client version
2.6.1.
Configuration on server (Amanda 2.6.1 on Debian 6.0.10):
define dumptype gnutar-xz-remote {
auth "ssh"
ssh_keys "/etc/amanda/id_amanda-server"
compress client custom
client-custom-compress "/etc/amanda/xz-1"
index yes
program "GNUTAR"
tape_splitsize 1 gbyte
split_diskbuffer "/data/amanda/split_diskbuffer"
}
and for the disk list:
<host> /etc gnutar-xz-remote
Configuration on client (Amanda 3.3.1 on Debian 7.8):
conf "MyConfig"
index_server "<server>"
tape_server "<server>"
auth "ssh"
ssh_keys "/etc/amanda/id_amanda-client"
Contents of /etc/amanda/xz-1:
#!/bin/bash
exec /usr/bin/xz -1 "$@"
Now, when executing amrecover on the client:
amrecover> setdisk /etc
200 Disk set to /etc.
amrecover> add *
Added dir /xml/ at date 2015-01-20-00-45-01
[...]
Added file /adduser.conf
amrecover> extract
[...]
Restoring files into directory /tmp/tmp.JwS8LFGzAS
All existing files in /tmp/tmp.JwS8LFGzAS can be deleted
Continue [?/Y/n]? y
tar: This does not look like a tar archive
tar: ./adduser.conf: Not found in archive
[...]
tar: ./xml: Not found in archive
tar: Exiting with failure status due to previous errors
And amrecover hangs, but can be interrupted with CTRL-C.
Relevant contents of amrecover debug log file from the client:
Wed Jan 21 09:24:36 2015: thd-0x1978a00: amrecover: read header 32768
=> 32768
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: User prompt:
'Continue [?/Y/n]? '; response: 'y'
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: image is
compressed /etc/amanda/xz-1
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: Spawning
"/etc/amanda/xz-1 /etc/amanda/xz-1 -d" in pipeline
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: Exec'ing /bin/tar
with arguments:
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: tar
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: --ignore-zeros
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover:
--numeric-owner
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: -xpGvf
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: -
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: ./adduser.conf
[...]
Wed Jan 21 09:24:39 2015: thd-0x1978a00: amrecover: ./xml
/usr/bin/xz: (stdin): File format not recognized
Wed Jan 21 09:26:21 2015: thd-0x1978a00: amrecover: sending: QUIT
Note that xz complains that it cannot recognize the file format. An
indeed, when replacing /etc/amanda/xz-1 on the client with this:
#!/bin/bash
cat -
the extract command works and completes successfully.
It looks like the server is already uncompressing the tar archive and
the client is trying the same again.
Note there is also a Debian bug ticket about this problem from 2012:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687312. In the ticket
the server was running 2.5.2 and the client 3.3.1.
Is this a known problem when mixing newer clients with older servers?
Can this be worked around somehow?
Thanks for any help,
Markus
