On Fri, Oct 09, 2020 at 08:48:41 +0200, Bernhard Erdmann wrote:
> There is another logfile:
> /tmp/amanda/server/be-full/amfetchdump.20201009083605.debug
>
> $ cat /tmp/amanda/server/be-full/amfetchdump.20201009083605.debug
> Fr Okt 09 08:36:05.594766041 2020: pid 2215: thd-0x1bab4f0: amfetchdump:
> pid 2215 ruid 33 euid 33 version 3.5.1: start at Fri Oct 9 08:36:05 2020
Yeah, that's the one to look at.
Unfortunately, I don't see anything in there that tells us more than we
already knew (i.e. that the program wasn't choosing the correct storage
before searching for the requested dump).
However, in my quick tests on a somewhat-similar setup here, I found
that I could in fact get amfetchdump to request the correct volume by
doing a manual override of the storage on the command line....
So, does the following command work any better?:
$ amfetchdump -ostorage=vtape -d vtape be-full svr '^/$' 20000119
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - [email protected] - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
