Re: amrecover usage with chg-robot

Am 26.05.22 um 04:10 schrieb Exuvo:
>  From my notes when i was doing recovery testing:
>   For some reason if i use encryption i get a single spurious error at 
> the end of amcheckdump or amrecover if you recover the last file written:
>    application stderr: /usr/bin/tar: Skipping to next header
>    application stderr: /usr/bin/tar: Exiting with failure status due to 
> previous errors
>   It still recovers as it should so nothing to worry about and manual 
> recovery from the same tape does not produce this warning but i have not 
> yet figured out why it happens.
> 
> I did do a complete 8TB restore when i first set up my archive backups, 
> which takes 7 tapes for me, changer worked, and that did give the above 
> warning at the end but all files matched the source when i checked.
> 
> I think i had "/bin/gzip: gzip: stdin: decompression OK, trailing 
> garbage ignored" before i used -q to zstd which suppresses warnings and 
> interactivity.
> 
> You could try a manual restore:
> position at block 1 with mt fsb
> mbuffer -i $TAPE -s 1024k -b 2048 -L | /etc/amanda/encrypt -d | 
> /etc/amanda/zstd-compression -d | tar -xf -
> or mbuffer -i $TAPE -s 1024k -b 2048 -L | openssl enc -pbkdf2 -d 
> -aes-256-ctr -salt -pass fd:3 3< pwfile | zstd -dqcf | tar -xf -
> That never gave the warnings as i get with amrecover but only feasible 
> for full restores.
> You can try zstd -dfo /dev/null to see if zstd gives any warnings while 
> reading.

Thanks a lot for that detailed reply. Although in my case the 
compression is with gzip, not with zstd. So I am unsure if your 
suggestion applies.

A short search tells me that zstd is able to decompress gzip archives?

Nice, but the existing backups on tape tell amrecover to use "gzip -d" 
or so, right?

I see people setting up a symlink .. hmm, wondering.

> In my "define changer" section i have device-property "READ_BUFFER_SIZE" 
> "1024k", which i had to add to read older backups when i was testing 
> different block sizes.
> That settings means it supports up to that blocksize for restores.

I don't have that setting yet.

Set it to 2048k now to match

blocksize 2 mbytes

readblocksize 2 mbytes

in the used tapetype (maybe all 3 settings could go into either the 
tapetype OR the changer device-property lines).