Amanda-Users

Re: forcing a failed backup to disk to use the same slot

2007-03-26 09:58:19
Subject: Re: forcing a failed backup to disk to use the same slot
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Mon, 26 Mar 2007 09:47:35 -0400
On Monday 26 March 2007, Paul Bijnens wrote:
>On 2007-03-25 01:58, Gene Heskett wrote:
>> On Saturday 24 March 2007, Frank Smith wrote:
>>> René Kanters wrote:
>>>> Hi,
>>>>
>>>> I have had some problems that an overnight backup 'hung up', i.e., a
>>>> level 0 dump started but never properly finished so backups from
>>>> other machines did not work either. So far the problem has been with
>>>> the western digital disk on my Mac amanda server, where a restart of
>>>> the external disk solves the problem.
>>>>
>>>> I catch these problems the same day they happen, so  I am wondering
>>>> whether it is possible to run amdump with a configuration of dumping
>>>> to a disk (using tpchanger "chg-disk") and not have amanda use the
>>>> next slot, but the slot that the failed dump started on.
>>>>
>>>> I could not find any information on that in the man pages.
>>>>
>>>> Any ideas?
>>>
>>> If you're sure that nothing you need was written to the 'tape', you
>>> can use amrmtape and then relabel it with the same label.  That
>>> should make it the first tape to use on the next run.
>>>  I've often wondered why Amanda marks a tape as 'used' on a failed
>>> backup even when nothing was written to tape.
>>>
>>> Frank
>>
>> I think, and someone is welcome to correct me, that the re-write of
>> the label on the tape with the current date, and all the housekeeping
>> that gets done when that is done, really should be delayed until such
>> time as there really is something in the holding disk that's complete
>> and ready to move to tape.  As it is, I believe this bit of
>> housekeeping is done up front before the error is known.
>>
>> This would be one improvement that could be put into amanda, and would
>> be most welcome.  Hint hint...
>
>On the other hand, delaying the checks for the correct tape that is
>as well writable, misses the opportunity to fall back to plan B,
>the "degraded mode" dumps (incrementals to holdingdisk instead) is
>something is wrong with the tape.
>
>But we could get around it, by doing writing a dummy label, just like
>for a new tape during that "write" test (just like "amcheck -w" does).
>And when the first real data is to be written, rewrite that label again
>with the correct one for the date.
>This would keep the tape available for the next run if anything goes
>wrong with getting the dumps.

I think the how is less important to most tape users.  My only problem 
with that is the wear and tear on the tape and drive, not a consideration 
for vtapes.  But whats wrong with going to plan B when its found that the 
first file isn't writable?  Most holding disks should have enough area to 
do that I'd think. In the event of a failure, could it not be sufficient 
to just move that tape back to the top of the tapelist & mark it somehow 
as new?

-- 
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)
When the blind lead the blind they will both fall over the cliff.
                -- Chinese proverb