Matthew,

> Is there a way to do one of the following?
>
>   (a) Tell Networker to surrender a drive at the next available
>   opportunity?  By surrender, I mean something like ``do not use the
>   drive for any operation except one that I start by hand''.
>
>   (b) Tell Networker not to use a drive at all, except for certain
>   purposes -- mainly inventories and restores.
>
> The problem I'm trying to solve is that all N drives in our jukebox
> are busy constantly.  We could still get all our backups done with N-1
> drives, though: the server is network-bandwidth constrained, rather
> than tape-bandwidth constrained.  So we'd like to have a drive sitting
> idle for the occasional restore and for jukebox inventories (which
> require a free drive, even if that drive is never needed to read a
> label).
>
> We're using Networker 5.5.1 on Solaris 7, and a Sun L1000 four-drive,
> 30-slot DLT jukebox.

The quick answer is "no".

OTOH my impression is that the server gives restores some sort of
priority over saves so it might do what you are after anyway for this
case.  Inventories are another matter; even under NetWorker 6 they must
have a drive free even if it ends up not needing to load any tapes to
check them.

Your "surrender" option is supposed to be partially introduced in
NetWorker 7.  (It will not start any new operations on a flagged drive;
when it is finally idle it is disabled.)  It is probably worth pointing
out here that, at the level you are talking about, NetWorker makes no
distinction between "automatic" and "manual" operations; they are all
just "operations".

Others have mentioned that you can set a read-only flag on one of the
drives.  This works well from the drives POV.  However older versions
of NetWorker (memory is not good enough to remember if that includes
5.5.1) had a bug in the jukebox tack-on where such attributes were not
taken into account when selecting a drive.  This meant that when a
writable tape was called for it would sometimes load the tape into your
read-only drive and then refuse to write to it.  From memory it then
ejected the tape and started again, trying the same tape in the same
drive, until something happened to break the cycle (like the drive
breaking).

I would favour the "increase target sessions" option.  This would tend
to leave some of your drives free.  You could then leave one drive
disabled (to ensure that it was free for when you needed it) and enable
it when required.  The downsides are that the enable/disable steps are
manual, and that something else can jump in and steal your drive if you
are not quick enough.

You should probably consider increasing your target sessions anyway
given that your server is network-bandwidth constrained.  Your drives
are probably sitting there shoeshining themselves (and your tapes) into
an early grave.

The other side of this coin is disaster restore performance.  If this
is important to you then your target sessions (and server and client
parallelisms) should be designed to optimise this, with backup
performance a secondary consideration.

George.
--
George Scott           George.Scott AT its.monash DOT edu
Systems Programmer, IT Services, Monash University

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=