On Wednesday 22 January 2003 08:31, Simon Young wrote:
>On Thu, Jan 16, 2003 at 01:13:14AM -0500, Jon LaBadie wrote:
>> On Fri, Jan 10, 2003 at 11:14:55AM +0000, Pavel Rabel wrote:
>> > > > >Can amanda send a signal to my DLT IV to unload the tape
>> > > > > after backups are finished, so whoever goes back to swap
>> > > > > tapes can just do it without waiting to manually unload?
>> > >
>> > > For amdump this is easy.
>
>Is it really easy when using a tape changer?
Once configured, yes.
>If you follow amdump with an amtape eject command, will you not be
>ejecting the tape in the 'current' slot?
Thats how it would work here at any rate. Amanda does not change her
notion of "slot" until the next invocation of amdump or amcheck,
both of which apparently start out by searching for the next
reusable tape.
Here, as a side comment, in order to have available on the days
tape, a copy of todays indices and configuration, I have reduced
the tapetype size by 100 megs, and after amdump is done and all its
locks on those files removed, I am tarring up those two dirs and
appending them to the tape immediately after amdump. This I'm
doing because when amdump is running with indexing on, there are
locks on those files and they will not be included in the regular
file for that disklist entry. These indice and config backups are
being kept in a seperate directory off of '/' which I have added to
the disklist, and a script takes care of removing the oldest,
incrementing the rest to make room for a new un-numbered one for
every run. As that directory only compresses to about 70% of
original size, there will be about 1.1 gigs to save every nite.
Thinking out loud, if I was to just march thru that dir using the
tapes number, that would reduce the size of that 'incremental' to
just the 3 new files from the last run. I'll do that when I get to
the loopback point in my cassette storage rack. My script gets
ever more complex it seems.
>Once amdump has finished, isn't the current slot incremented?
Not here. This is all done at the start of the next run, which is
why you run amcheck sometime earlier and have it email you if the
right tape is not in the magazine. Once amdump can't find the
right tape, the whole run goes into the holding disk, and it does
that run no good to reload the magazine once amdump has looked at,
and not found the tape it needs.
> Implying that you'll be ejecting the tape in the next slot, which
> is most likely the one amanda will be wanting to use next.
I'd assume in those robots where it has an internal storage of 12 or
more tapes, that an eject would mean it will bring that tape to the
door for you to remove, in which case you would need to tell it
which tape slot to give you the contents of. This would not be the
same as ejecting a tape from a drive, which in larger libraries,
there may be 2 or more of. I keep refering to 'magazine' because
thats the 'style' mine is built as, which of course will not apply
to all cases.
>I'm not quite clear about this yet, so please correct me if I'm
> wrong.
>
>And what if amanda uses more than one tape in a single run? Is
> there a nice way to have it eject only the tapes it used?
That would only be effective in the event you had a library robot
capable of laying the tape(s) on an output "used" shelf or some
such. There may be one or more that can do that, but normally the
eject (rewoffl to mt) with either put that tape back into its slot
in the magazine, or will (dip switches may control this behaviour,
and they do on my mechanism so I shut that switch off) actually
cause the robot to eject and store this tape back in its magazine
slot, and load the next one if it is not at the end of the
magazine.
Not trying to confuse, my apologies if it does.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.22% setiathome rank, not too shabby for a WV hillbilly
|
