In case you weren't aware there have been a lot of
problems with dssu's and dsu's properly expiring old
and failed backup images. This led to a lot of status
84 issues with dsu's and dssu's. NetBackup would not
remove expired images of jobs that had failed or even
successful jobs in some circumstances. This has been
resolved in the latest maintenance pack. This was a
known issue and I believe there are several technotes
documenting the problems.
--- veritas-bu-request AT mailman.eng.auburn DOT edu wrote:
> Send Veritas-bu mailing list submissions to
> veritas-bu AT mailman.eng.auburn DOT edu
>
> To subscribe or unsubscribe via the World Wide Web,
> visit
>
>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> or, via email, send a message with subject or body
> 'help' to
> veritas-bu-request AT mailman.eng.auburn DOT edu
>
> You can reach the person managing the list at
> veritas-bu-admin AT mailman.eng.auburn DOT edu
>
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Veritas-bu digest..."
>
>
> Today's Topics:
>
> 1. Re: libacs.dll not found (J R)
> 2. Re: Disk Staging & Storage Unit Groups (Rob
> Worman (home))
> 3. Re: Convert "English Time" back to "seconds
> past the epoch" (slig
> htly simpler) (Mark Hickey)
> 4. RE: Disk Staging & Storage Unit Groups (Paul
> Keating)
> 5. slow restoration on clone volume (Song)
> 6. Re: Veritas Netback and DNS dependencies (Dave
> Markham)
> 7. Re: bpdbjobs -most_columns: field
> descriptions? (Dave Markham)
>
> --__--__--
>
> Message: 1
> Date: Wed, 2 Feb 2005 15:54:22 -0800 (PST)
> From: J R <tekkdude AT yahoo DOT com>
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] Re: libacs.dll not found
>
> You need to install STK's Libattach software to
> control ACS robots on Windows servers. The software
> is
> already included on Solaris but is a seperate
> install
> for Windows machines.
>
> Jeff Redington
>
>
> =====
> "A wise man once said 'Wherever you go, there you
> are'"
> -Mike Brady
>
> --__--__--
>
> Message: 2
> Cc: <veritas-bu AT mailman.eng.auburn DOT edu>
> From: Rob Worman (home) <rob AT worman DOT org>
> Subject: Re: [Veritas-bu] Disk Staging & Storage
> Unit Groups
> Date: Wed, 2 Feb 2005 21:14:06 -0600
> To: "Paul Keating" <pkeating AT bank-banque-canada DOT ca>
>
> 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
>
=== message truncated ===
=====
"A wise man once said 'Wherever you go, there you are'"
-Mike Brady
|
