We put together a system whereas all Incremental would write to a
storage unit group of purely DSU's, obviously we calculated the amount
of data(with retention in mind) in order for the DSU's to never fill up.
Then with the FULL's we had a separate DSSU , that would chug away of to
tape during the day.

The whole high level watermark thing I found to be pants, as when we
first embarked on the staging setup we stupidly believed that a high
waterlevel mark of say 90% would in fact keep the DSSU at a constant
90%. The problem we had was that only once the 90% threshold was
exceeded did duplication kick in to bring the DSSU back down to 90 % .
So you can imagine during  daylight duplication bringing the DSSU back
down to 90% and then in the evening the DSSU would fill up.

This was all fine as we didn't fully understand the high water level
mark. In my opinion the high level watermark should be at 0% as
everything going though the DSSU is destined for another destination
anyway, and with the ability to set windows for the staging schedule ,
why not get everything off to tape asap. Unless of course you want to
use a DSSU as a DSU and whether you are off siteing tapes or not .

Hope it helps.

Dave

-----Original Message-----
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Peter
DrakeUnderkoffler
Sent: 18 August 2006 12:29
To: Martin, Jonathan (Contractor)
Cc: veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] DSSU Storage?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have a couple of customers using DSSU's in NBU6.  First of all, I do
use storage unit groups with multiple DSSUs as part of them.  Almost all
have "re-used" existing storage as a general trend, so the back end
storage has been RAID 1 or RAID 5 more times than not.  The size of each
DSSU depends on what the client profiles, back end storage density and
policy/schedule quantities and frequencies.  Kind of need to put all
that in your brain and make a best guess.  I have found that setting the
mfs on the DSSU hasn't aided any of the situations I've set up and in
fact when using multiple DSSUs in a storage unit group, the smaller
(512mb) mfs has better distribution on smaller sides DSSUs.  Flushing is
done only after phase 2 is complete and successful.  So if your schedule
is not frequent enough, it will not prune out images as there would
still be only
1 copy of that backup image.  Looking forward to next updates when the
volume pool can be specified at a more granule level instead of all disk
staging for that DSSU goes to one pool.  I've taken the approach for
some customers to have cumulative or incrementals go to DSSUs and fulls
and archives go strait to tape.  Also, setting the storage unit group
usage profile is something to consider if you go that route
(prioritized, least used and failover).  As far as HWM and LWM, I've
generally left the HWM default (98%) and set the LWM to sometimes 60%,
but that depends on the available resources for phase 2 and the
frequency as well.  If you want to have the most possible images on disk
for faster restores, then taking your LWM down to 40% will make that
difficult.

Thanks
Peter

Peter DrakeUnderkoffler
Xinupro, LLC
617-834-2352



Martin, Jonathan (Contractor) wrote:
> I'm working on architecting a new backup solution here, which will
undoubtedly require Disk Staging to accommodate faster drives (LTO3 or
DLT-S4.)  I'm sure this is a common way to get around the limited
bandwidth associated with copper network connections.  Anyhow, how big
is everyone's DSSUs?  2x Media?  More?  How about your High Water Marks?
I'm thinking something along the lines of 50% high water mark with
DSSU's 2x Media (compressed.)  Also, lets say your DSSU gets up to 40%
when the backup window finishes, is there a setting to flush this after
a certain amount of time?  I'm installing 6.0 for the first time here
shortly, so all the new features are presently a mystery to me.
> 
> TIA,
> 
> -Jonathan
> 
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu 
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)

iD8DBQFE5aSUl+lekZRM55oRAnyDAKDc+1EkPCsbcDip//kG94/X3QSOZQCfVnGf
SmguJAyWXfl0dym2t0NMOkc=
=oRKG
-----END PGP SIGNATURE-----
_______________________________________________
Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu



Notice to recipient:
The information in this internet e-mail and any attachments is confidential and 
may be privileged. It is intended solely for the addressee. If you are not the 
intended addressee please notify the sender immediately by telephone. If you 
are not the intended recipient, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it, is prohibited and may be 
unlawful.

When addressed to external clients any opinions or advice contained in this 
internet e-mail are subject to the terms and conditions expressed in any 
applicable governing terms of business or client engagement letter issued by 
the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America, N.A., 
London Branch and Banc of America Securities Limited are authorised and 
regulated by the Financial Services Authority.