FWIW, in case you haven't discovered this, it is a good idea to have
FULLs and INCREMEMENTALS go to different DSUs.

If NB thinks there is insufficient space on a DSU, it will delete the
two oldest images that have been purged to tape, in order to make room
for the next backup.

However, if the two oldest images on the DSU are 100 Meg incrementals,
and the backup that is queueing is a 50 gig FULL, you're gonna end up
with the full DSU, and a status 84.

What I've been doing lately, is letting the Friday night FULL run, then
Monday morning, I verify that it is flushed to tape....once on tape, I
promote the tape copy to Primary, and expire the DSU image......that
cleans up the DSU and leaves enough free space to run till the following
Monday.

Currently this is a work around untill our SAN infrastructure is in
place in Q3, as we don't want to buy additional disk arrays now, with
the SAN in the pipe.

Paul

> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu 
> [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of 
> Nash, Ebon
> Sent: January 19, 2005 11:07 AM
> To: 'Weber, Philip'; 'veritas-bu AT mailman.eng.auburn DOT edu'
> Subject: RE: [Veritas-bu] Disk Staging & Storage Unit Groups
> 
> 
> We have not found a way to get around the 84 errors caused by 
> a dsu filling
> up.  NB isn't smart enough to try a different dsu.  However, 
> we have been
> able to run parallel jobs to different dsu's.  We have 3 
> media servers, each
> with one dsu.  We set job limits per dsu of 6.  We then 
> created 3 storage
> unit groups.  Each storage unit group has all 3 dsu's, 
> however, each group
> has a different priority for each dsu.  Then each policy has 
> a specific
> storage unit group it uses.  The policy A will always try to 
> write to STU
> group 1 first.  Policy B will always try to write to STU 
> group 2 first ,
> etc.  If one of those dsu's has the maximum number of jobs 
> running, the job
> runs on the next available dsu in the STU group.  This 
> ensures that the
> maximum number of jobs run, but the load is spread out across 
> dsu's.  That
> is provided you have balanced the policies so that roughly 
> that each dest
> STU is used equally.