A couple comments to add to this thread:

Ebon: "NetBackup is not smart enough to use a different disk storage 
unit when a DSU fills up"
Rumor has it, the next version (6.0?) of NBU will properly handle this 
situation.

====

Paul: "It is a good idea to have fulls and incrementals go to different 
DSU's"
Your example below (with the DSSU filling up on a 50GB backup, then 
only cleaning up two incremental backups...) implies that the DSSU 
cleanup behavior can only happen ONCE during a backup job.  This is not 
the case.  If a backup to a DSSU encounters a diskfull error, the 
following results:
    (1) pause the backup
    (2) expire up to two [this number was recently upped to ten] of the 
oldest images that have been duped to tape
    (2a) if there are no images to expire in (2), fail the backup with 
an 84
    (3) resume the backup;  if another diskfull condition occurs, see 
step (1)

That said, I still agree that a separate DSSU for incrementals vs fulls 
is a good idea - if a big full backup has to keep pausing while NBU 
expires the much smaller incremental images, performance might take a 
noticeable hit.

But please keep in mind that those separate DSSU's should be on 
separate filesystems/partitions!

HTH
rob



On Jan 25, 2005, at 9:58 AM, Paul Keating wrote:

> 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.
>
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>