On 2017-11-10 12:52, Jean-Louis Martineau wrote:
The previous patch broke something. Try this new set2-r2.diff patch
Unfortunately, that doesn't appear to have fixed it, though the errors look different now. I'll try and get the log scrubbed by the end of the day and post it here.
On 10/11/17 10:40 AM, 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 >> > amfetchdump doesn't see it, and neither does amrecover, but the files > for the given parts are definitely there (I know for a fact that the > dump in question has exactly one part, and the file for that does > exist on the virtual tape mentioned in the log file). > > I'm probably not going to be able to check more on this today, but > I'll likely be checking if amrestore and amadmin find can see them. >
