On Monday 14 November 2005 15:33, Jon LaBadie wrote:
>On Mon, Nov 14, 2005 at 07:22:23PM +0100, Stefan G. Weichinger wrote:
>> Jon LaBadie wrote:
>> >Might not be the last file on the tape. Suppose you collected
>> > things on the holding disk, possibly several days of dumps, before
>> > taping.
>> >
>> >If the metadata were to hold the DLE -> tape mappings, the dump of
>> >the metadata couldn't begin until after all other DLEs were taped.
>> >Does that raise any issues?
>>
>> The size of the metadata-DLE should be relatively predictable so this
>> amount of space could be put into calculation from start (also the
>> history should show what size to expect). The metadata-DLE could only
>> be dumped AFTER the regular DLEs are dumped completely and the
>> related indexes are written, so I assume the metadata-DLE simply gets
>> into line as soon as its ready.
>
>What I was thinking was that many sites complete their dumping to
>holding disk well before taping is complete. For the metadata-DLE
>(MD-DLE?) to be complete it needs to know what tape(s) hold what DLE's.
>Thus dumping the MD-DLE would not only have to be last, but would have
>to be put on hold until all other taping was complete.
>
>It is the delay that I was concerned about. However I guess there
>is already precedence for such behavior by amdump. The starttime
>option, depending on the time argument, puts dumping on hold for
>a period. It resumes when triggered by the clock. Perhaps the
>MD-DLE could employ similar or the same code, but triggered by
>completion of all other activities.
Which on some systems, still cannot work because those files that are
open, will not be backed up at all, and on others will be only partially
valid. Amigados is one case where that no backup of open files is true,
and its burnt me badly several times. That of course wasn't amanda
before anyone asks, it was with Diavolo Pro. If that stuff had beennin
the backups, then I wouldn't have had to either re-invent a very complex
wheel when the hd died, or put it on the shelf. I put it on the shelf
(in the basement) rather than spend weeks fine tuning a difficult boot
process to working state again.
My method simply waits till amdump is done and has returned to the
script that launched it, at which point the script then launches a
second script that tars up all this stuff and appends it to the tape. It
could be all in one script I guess, but I tend to scratch individual
itches with seperate scripts. :) To me, this is the best option. And
anyone who wants to weed the trash stuff out of my scripts is welcome to
do so as eventually I'd like to see this added to the amanda
distribution, a super-wrapper for amdump if you will.
Whats missing in the overall function is a method of communicating back
to amdump, how much of a space cushion is needed in order to have room on
an otherwise full tape for these tarballs.
What they do now is autoconfigure how it runs according to what it was
called at invocation time, all the names are links to one (or more)
scripts depending on what it needs to do, dump or flush. Beyond that,
everything else is hard coded, but could be put into cli arguments or a
.config file to make it a bit more universal. But once I had it
working, I have this tendency to let something thats working alone so I
don't break it again. :)
I also have some scripts that make the automatic generation of a vtape
setup quite easily done if anyone is interested in those. They aren't
"pretty" either, but they worked for me. :)
--
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.36% 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.
|
