KillerPolicy is a single client running a max of 12 simultaneous
streams to backup approximately 2.5 TB across 7 mount points usually
at combined rate of approximately 20 - 30 MB/Sec peak and around 3.5
MB/Sec each for the final two especially large streams at the end.

On 6/7/06, bob944 <bob944 at attglobal.net> wrote:
> > I'm sure I have a setting wrong somewhere, but one of my huge backups
> > has decided that it wants to take over all 4 drives in our jukebox
> > when it does full backups.
> >
> > I use streams but would really like to set it so the policy can use a
> > maximum of 2 drives at any one time so other policies can run as well.
> > [...]
> > Thanks everyone.  I was worried that doing this would would be invalid
> > (due to the 4 drives using a single robot) but apparently not.  As of
> > this time, everything appears to be working just fine.
>
> You received, exclusively, suggestions to set up a special STU.  That is
> a hideous solution to my mind.
>
> You wanted KillerPolicy to use no more than two drives.  The number of
> drives used is #Streams * #Clients * #Copies (potentially reduced by
> multiplexing, drives in the STU and drive availability).  Configuring
> multiple streams and multiple copies is completely under your control.
> The throttle on how many jobs you want the class to run--how many drives
> to use--simultaneously is the "Limit jobs per policy" setting.  Set it
> to two and do whatever you like with the selection and client lists.
>
> > I have noticed that while I can limit a storage unit to only 2 drives,
> > I can't tell it which two.  Good in that if drives die it can still
> > go on.  Bad that if drives die, it may still go on (and block other
> > backups from occurring).
>
> You may be overthinking this (what if two drives are down?  Three?).  If
> it really is something you will care about, lower the class's Job
> priority relative to the ones you want to run.
>
>