On 2017-11-10 08:45, Austin S. Hemmelgarn wrote:
On 2017-11-10 08:27, Jean-Louis Martineau wrote:
On 10/11/17 07:57 AM, Austin S. Hemmelgarn wrote:
On 2017-11-08 08:03, Jean-Louis Martineau wrote:
On 07/11/17 02:58 PM, Austin S. Hemmelgarn wrote:
> On 2017-11-07 10:22, Jean-Louis Martineau wrote:
>> Austin,
>>
>> It's hard to say something with only the error message.
>>
>> Can you post the amdump.<datestamp> and log.<datestamp>.0 for the 2
>> backup set that fail.
>>
> I've attached the files (I would put them inline, but one of the
sets
> has over 100 DLE's, so the amdump file is huge, and the others are
> still over 100k each, and I figured nobody want's to try and wad
> through those in-line).
>
> The set1 and set2 files are for the two backup sets that show the
> header mismatch error, and the set3 files are for the one that
claims
> failures in the dump summary.
I looked at set3, the error in the 'DUMP SUMMARY' are related to the
error in the 'FAILURE DUMP SUMMARY'
client2 /boot lev 0 FLUSH [File 0 not found]
client3 /boot lev 0 FLUSH [File 0 not found]
client7 /boot lev 0 FLUSH [File 0 not found]
client8 /boot lev 0 FLUSH [File 0 not found]
client0 /boot lev 0 FLUSH [File 0 not found]
client9 /boot lev 0 FLUSH [File 0 not found]
client9 /srv lev 0 FLUSH [File 0 not found]
client9 /var lev 0 FLUSH [File 0 not found]
server0 /boot lev 0 FLUSH [File 0 not found]
client10 /boot lev 0 FLUSH [File 0 not found]
client11 /boot lev 0 FLUSH [File 0 not found]
client12 /boot lev 0 FLUSH [File 0 not found]
They are VAULT attemp, not FLUSH, looking only at the first entry, it
try to vault 'client2 /boot 0 20171024084159' which it expect to
find on
tape Server-01. It is an older dump.
Do Server-01 is still there? Did it still contains the dump?
OK, I've done some further investigation by tweaking the labeling a
bit (which actually fixed a purely cosmetic issue we were having),
but I'm still seeing the same problem that prompted this thread, and
I can confirm that the dumps are where Amanda is trying to look for
them, it's just not seeing them for some reason. I hadn't thought of
this before, but could it have something to do with the virtual tape
library being auto-mounted over NFS on the backup server?
Austin,
Can you try to see if amfetchdump can restore it?
* amfetchdump CONFIG client2 /boot 20171024084159
At the moment, I'm re-testing things after tweaking some NFS parameters
for the virtual tape library (apparently the FreeNAS server that's
actually storing the data didn't have NFSv4 turned on, so it was mounted
with NFSv3, which we've had issues with before on our network), so I
can't exactly check immediately, but assuming the problem repeats, I'll
do that first thing once the test dump is done.
It looks like the combination of fixing the incorrect labeling in the
config and switching to NFSv4 fixed this particular case.
