On Tuesday 01 November 2016 22:03:21 Ochressandro Rettinger wrote:
> I ran another backup with client compression, and tried
> recovering from it. It hung in the same fashion as the previous time I
> tried it. I then tried running amrecover on the actual client system
> itself (th
So, I understand the subject of software vs: hardware
compression now (thanks for that very enlightening description of why it's good
to let Amanda handle the compression, Chris) but now I'm wondering about the
question of server vs: client compression. I would tend to think th
I ran another backup with client compression, and tried
recovering from it. It hung in the same fashion as the previous time I tried
it. I then tried running amrecover on the actual client system itself (the
cleverly named "backuptest"), in the hopes that it would work better f
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
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:jmartin...@carbonite.com]
Sent: Tuesday, November 01, 2016 9:50 AM
T
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 compresse
I tried both "localhost backup" and "localhost root" in the amandahosts
file. No difference. It is odd -- everything seems to work. I can
connect to the localhost, issue sethost and setdisk commands. In fact,
if I give an invalid host or disk name, I get an error message. But the
ls command jus
