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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter DrakeUnderkoffler Sent: 18 August 2006 12:29 To: Martin, Jonathan (Contractor) Cc: [email protected] 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 - [email protected] > 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 - [email protected] 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. _______________________________________________ Veritas-bu maillist - [email protected] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
