On Friday 08 July 2005 15:37, Frank Smith wrote:
>--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.
Some tape drives may not be able to backspace, but truely those are
early dynosaurs. My experience is with DDS2's and QIC's up to 525
meg capacity. Each and every one has been able to bsb one or more
files. Worst come to worst, the tape can be rewound, & fsf'd to the
head of that file and wipe it from there. OTOH, that would be lots
of wear on the drive & tape if it occured very often, which it will
in a runtapes > 1 situation.
As far as a vtape loss of positioning is concerned, its A: bloody
unlikely, and B: insrantly recoverable by hand because here is a
common ls -l obtained directory listing of one of my vtapes:
-rw------- 1 amanda disk 10 Jul 8 01:42 00000-Dailys-2
-rw------- 1 amanda disk 32768 Jul 8 01:42 00000.Dailys-2
-rw------- 1 amanda disk 12 Jul 8 01:43
00001-gene._usr_src.1
-rw------- 1 amanda disk 9469952 Jul 8 01:43
00001.gene._usr_src.1
-rw------- 1 amanda disk 11 Jul 8 01:44 00002-gene._root.1
-rw------- 1 amanda disk 1048576 Jul 8 01:44 00002.gene._root.1
-rw------- 1 amanda disk 11 Jul 8 01:47
00003-gene._usr_local.1
-rw------- 1 amanda disk 491520 Jul 8 01:47
00003.gene._usr_local.1
[...]
-rw------- 1 amanda disk 10 Jul 8 03:07 00040-coyote._bin.1
-rw------- 1 amanda disk 65536 Jul 8 03:07 00040.coyote._bin.1
-rw------- 1 amanda disk 10 Jul 8 03:07
00041-coyote._usr_man.1
-rw------- 1 amanda disk 65536 Jul 8 03:07
00041.coyote._usr_man.1
-rw------- 1 amanda disk 10 Jul 8 03:08
00042-coyote._usr_movies.1
-rw------- 1 amanda disk 65536 Jul 8 03:08
00042.coyote._usr_movies.1
-rw------- 1 amanda disk 10 Jul 8 03:08 00043-coyote._dos.1
-rw------- 1 amanda disk 65536 Jul 8 03:08 00043.coyote._dos.1
-rw------- 1 amanda disk 10 Jul 8 03:08 00044-TAPEEND
-rw------- 1 amanda disk 32768 Jul 8 03:08 00044.TAPEEND
-rw-r--r-- 1 amanda disk 71680 Jul 8 03:09 configuration.tar
-rw-r--r-- 1 amanda disk 95344640 Jul 8 03:09 indices.tar
In the event of an error that isn't caused by the disk itself turning
tits up, tar & gzip can recover the contents of any of them. Amanda
in that case is a luxury. The last 2 files are my own bit of cma as
they represent the config dir that generated these vtapes, and the
complete, uptodate indices for the whole system as it exists for the
current tapelist. From those and the /home dir, which contains the
srcs for the last several versions of amanda-2.4.5, if I had to do a
bare metal, I'd get the /home/amanda tree, install the latest amanda,
then tar & gzip the last 2 files back to their original locations.
>From there I ought to be able to start an amrestore and goto bed.
> 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.
Which makes perfect sense to me. And, it shouldn't take more than say
10-15 lines of code to do it.
>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.
--
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.
|
