-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I will absolutely agree that DSSUs are no where close from being fully
mature. About your failures, what is the SUG policy, failover, least used
or priority? As far as going over the HWM, what does 90% work out
to when taking into account the fragment size? I've run into a situation
where instead of queuing the job or failing with no available storage units,
I got 129's when the next unused DSSU in the SUG already had active jobs
and the additional pushed it passed it's allowed limit.
I've been wrestling with DSSU type functions in NBU since using
Vault as the phase 2 solution, so the process has made some good advancements,
but it still required a good level of over engineering when it comes
to available resources still as when it gets close to those limits, it
becomes unstable in my opinion.
Thanks
Peter
Peter DrakeUnderkoffler
Xinupro, LLC
617-834-2352
Aaron.J.Morrison at nab.com.au wrote:
>
> Hey Peter,
>
> We recently went Netbackup 6 and once we got the media servers to 6 as
> well, I set up a storage unit group consisting of two DSUs with manual
> duplication scripts.
>
> I have the HWM at 90%.
>
> Some of my backups are failing with 129 errors when directed to the Stroage
> Unit group even though one of the DSUs still had capacity.
> I thought that if a DSU went over the HWM it would continue existing
> backups but no new backups would be sent to it. The SUG should then remove
> it from the list while it's over the HWM.
>
> Maybe I am expecting too much from Netbackup but if it's going to fail
> backups with 129 errors then Storage Unit Groups are only half there in
> functionality....
>
>
> regards,
>
>
> Aaron
>
>
>
>
>
> (Embedded image moved to
> file: pic31998.jpg)
>
> Aaron Morrison
>
> Senior Technical Specalist
>
> Storage Management
>
>
>
> National Australia Bank
>
> 1/122 Lewis Rd Wantirna
> South 3152
>
> Tel: (+61 3) 9886 2359
> Mob: 0400104744
>
> Fax: (+61 3) 98862700
> email:
> aaron_morrison at nab.com.au
>
>
>
> Please contact Storage
> Management Australia for
> all requests.
>
>
>
>
>
>
>
> Peter
> DrakeUnderkoffler
> <pcd at xinupro.com> To
> Sent by: "Martin, Jonathan (Contractor)"
> veritas-bu-bounce <JMARTI05 at intersil.com>
> s at mailman.eng.aub cc
> urn.edu veritas-bu at mailman.eng.auburn.edu
> Subject
> Re: [Veritas-bu] DSSU Storage?
> 18/08/2006 09:29
> PM
>
>
>
>
>
>
>
>
> 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
>>>
>
_______________________________________________
Veritas-bu maillist - Veritas-bu at mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
National Australia Bank Ltd - ABN 12 004 044 937
This email may contain confidential information. If you are not the intended
recipient, please
immediately notify us at postmaster at nab.com.au or by replying to the sender,
and then destroy all copies
of this email. Except where this email indicates otherwise, views expressed in
this email are those of
the sender and not of National Australia Bank Ltd. Advice in this email does
not take account of your
objectives, financial situation, or needs. It is important for you to consider
these matters and, if the
e-mail refers to a product(s), you should read the relevant Product Disclosure
Statement(s)/other
disclosure document(s) before making any decisions. If you do not want email
marketing from us in
future, forward this email with "unsubscribe" in the subject line to
Unsubscriptions at nab.com.au in order
to stop marketing emails from this sender. National Australia Bank Ltd does not
represent that this
email is free of errors, viruses or interference.
- ------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)
iD8DBQFE6RITl+lekZRM55oRApcUAKDZnDW267qHXQVYw7pRpoxO1hOV/ACfWqWo
5aPpC9bQwcR9JurNFmY+sOc=
=Z6t2
-----END PGP SIGNATURE-----
|
