Jesse,

One way to do this is to set your drive allocation lower than the total
number of available drives. This way you have one drive sitting idle. This
is
somewhat expensive when you get into this situation though. You can
also overide this if you submir enough jobs via different classes.

IE You have 4 drives and your class1 job allocates 2 drives, and class 2
job allocates 3 drives then you would have the class 2 job waiting for
one drive and you would not be able to get the restore to run until one
of them completed or you did as before and issued a kill job (150) to
get the drives released.

Another idea might be to put this drive
in a different pool so that it can only be allocated if all the other
drives in the first pool are in use or unavailable.


> Message: 3
> From: "Gardner, Jesse" <Jesse.Gardner AT storaenso DOT com>
>
> Last night we had a crucial server needing a restore, at the
> same time when
> all of our backups run.  When the restore was initiated, it sat in the
> queue.  Finally, we just killed the backup jobs and forced
> the restore.  It
> would be nice if, when one backup job ended, the restore had
> a high enough
> priority that it would kick off.  I searched this mailing
> list and found the
> exact same scenario:
> http://mailman.eng.auburn.edu/pipermail/veritas-bu/2001-Octobe
> r/006009.html
> However, no answer was found in the thread.
> Does anyone know of a way to assign a default priority to
> restores, or some
> other way of forcing restores to run in the midst of a queue
> of backups?