Wow, a supporter, and I thought I was all alone

;-)

-- 
AlanP

On Thu, July 27, 2006 10:14 pm, Matthias Andree wrote:
> Jon LaBadie <jon AT jgcomp DOT com> writes:
>
>> On Thu, Jul 27, 2006 at 04:07:40PM +0100, Alan Pearson wrote:
>>> NOTES:
>>>   planner: Last full dump of qtvpdc:/ on tape DailySet1-3 overwritten
>>> on this run.
>>>   planner: Incremental of qtvpdc:/ bumped to level 2.
>>>   planner: qtvpdc / 20060727 0 [dump larger than available tape space,
>>> 35448530 KB, full dump delayed]
>
>>> In the NOTES section it says that a full dump of the machine qtvpdc
>>> was delayed because it was larger than available tape space.
>>> Yet it says it is going to overwrite the last full dump of this
>>> machine 2 lines previous.
>>>
>>> Yes I realise it wouldn't fit on the tape, but Amanda should at least
>>> have put it in the holding disk area or NOT overwritten the only full
>>> backup at all.
>
>> That would seem to be a hard call.
>
> The planner runs BEFORE anything happens to the tape, right?
> (After all it needs to plan the dump levels.)
>
> I've also been in the situation where amanda would happily kill the last
> full dump. So why in hell are *again* excuses made for for a *FATAL*
> mistake of Amanda's planner? The minimum fix would be pretending the
> slot were empty and going to degraded mode. Oh, and add to that: tar
> (GNU tar) 1.15.1 will happily overestimate sparse files and think it has
> 4 GB to stuff when it has in fact only 2.8 GB...
>
> In my case, the configuration was f*cked up (check the archives),
> without amanda sanity checking them and printing a gentle warning.
>
>> For just one example, I've got a DLE that I only do weekly full dumps,
>> no incrementals.  It contains nothing but *.iso files, dvd or cd
>> images, that I can easily recreate from the original optical media.
>
> Excuse me, who cares for *your* backing up garbage?
>
>> And some of my DLEs go directly to tape, bypassing the holding disk.
>> Should the backup of those direct to tape DLEs be skipped to preserve
>> my relatively unimportant last full dump of the *.iso DLE?
>
> There are priorities in the dump definitions that can aid in making this
> decision - if the priority of the level 0 dump to be killed is higher
> than the data you're dumping directly to disk, lock the tape out.
>
>> Just for info, how did you get to the situation of only having one
>> full dump in the tapecycle?  If that tape failed you would have
>> been in a similar situation.
>
> Yes, but that's not a deliberate loss of data, unlike Amanda overwriting
> things (even though overwriting the last level 0 is a bad idea anyways).
>
>> Failed tapes were pretty common for me when I was using DDS tapes.
>
> It's known that DDS tapes like all helical scan media are consumables
> and stand only a few dozen cycles.
>
>> Typically I have 3-5 full dumps within a tapecycle.  (Not counting
>> those in the archive config)
>
> So, is that permission to deliberately destroy the *LAST* one?
> I think not.
>
> --
> Matthias Andree
>