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.
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.
Anton "exuvo" Olsson
ex...@exuvo.se
On 2022-05-25 17:09, Stefan G. Weichinger wrote:
Am 25.05.22 um 16:46 schrieb Stefan G. Weichinger:
The tested DLE is encrypted and compressed. Yes, redundant ... I can change
that in the future.
The first part gets read perfectly, but it seems that the end of the tarball
crashes things somehow.
I remember that error from mailing list threads .. I will research later when I
am back at my office.
Testing with a DLE that is/was not encrypted. Plain tar, no compression.
amrecover with device "/dev/sg21" works great. I have to confirm the tape
change after the first files have been extracted, then the changer loads the next tape
and the next restore step happens. Great.
-
So to me it looks that my dumptype with both compression and encryption is the
problem.
I use the script provided by Anton "exuvo" Olsson, he shared it in earlier
threads here.
The current iteration on this server:
https://dpaste.org/2YrkJ
Maybe it hasn't yet been tested with amrecover from multiple tapes?
Or the combination with gzip is a problem.
I'll be happy to share any more debug logs or so.
