--On Friday, July 08, 2005 10:58:25 -0400 Gene Heskett <gene.heskett AT verizon
DOT net> wrote:
> On Friday 08 July 2005 09:44, Jon LaBadie wrote:
>> On Fri, Jul 08, 2005 at 10:18:53AM +0200, MATILDA MATILDA wrote:
>>> Hi all,
>>>
>>> After backup I run amverifyrun to check the backup. Now I have the
>>> following situation and I don't know if this behaviour is intended
>>> or I'm doing something wrong.
>>
>> brief synopsis:
>> on a multi-tape run
>> amverify notes an incomplete dump file at the end of a tape
>> marks that as an error
>> finds the complete dump file on the next tape
>> does not remove the earlier error
>> thus generates a report showing errors
>>
>>> My question: Is there a way to check that backup so that I get an
>>> error when there is really an error in the backup set? In this
>>> context error means to me that I probably can't restore alle
>>> tar-files I backed up before.
>>
>> Seems to me that your desired behavior would be reasonable.
>>
>> It could be a real bear to test, having to read through entire tapes
>> before getting to the test point.
>>
>> I hope someone with a vtape test setup can duplicate the problem and
>> use that as a testbed instead.
>
> I'm running vtapes here. This was indeed true the last time I tried
> runtapes=2, Jon. There were also some other amverifyish housekeeping
> problems whose details I don't recall now as that was several (6+)
> months back up the log and none of the examples now exist.
>
> To me, the obvious cure would be to remove the partial file, a piece
> of cake in a vtape setup, but in a tape environment, that would
> require keeping track of the fm's so that a backspace could be done
> and the partial files header overwritten with an EOT marker & 32k
> of /dev/zero before going on to the next tape in the magazine &
> restarting the failed file. Thats a lot of wear and tear on both the
> tape and the drive IMO, so the real cure should be done in amverify
> itself.
This seems dangerous to me. Besides the fact that some drives don't
backspace well (speed-wise), even on a vtape an error in your
positioning would cause loss of data.
It seems easier and safer to to just have amverify buffer the
error and if it is successful in reading the DLE from the next
tape don't output the error.
Frank
>
> The question then is: can amrecover/amrestore cope properly with this
> scenario? I do not know, having never tested that exact scenario.
>
> --
> Cheers, Gene
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> 99.35% setiathome rank, not too shabby for a WV hillbilly
> Yahoo.com and AOL/TW attorneys please note, additions to the above
> message by Gene Heskett are:
> Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
--
Frank Smith fsmith AT hoovers DOT com
Sr. Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
|
