>Paul,
>
>I should have mentioned more in my response. Our nodes have been separated
into
>three domain because they all belong to one of three groups, controlled by
three
>different sections in our company. I do not believe we are limiting these
>clients to one management class because, if need be, more management
classes can
>be defined in each domain. If a group decides they need another archive
>schedule with different retentions defined, we can do that for them. For
our
>setup, one management class with one backup copy group and one archive copy
>group for each domain works well and keeps it simple. We do have DIRMC set
up
>for each client, but I do believe this only applies to backups and not
>archives. The additional benefit is not having to worry about directories
being
>archived to a mgt class that we do not wish which was a big problem for us
a
>while back. A note in the readme for the 3.1.0.7 client says that by
default
>directories will now bind to the default management class rather than the
one
>with the longest retention. I still see this as a problem if I archive
using a
>mgt class that is not the default mgt class and both classes have different
>destination tape pools...
>
>Thank you for the comments and more are welcomed.
>
>Regards,
>adam
>__________________
>Adam Slesinger
>Corporate Information Systems
>Brown & Sharpe, RI
>Phone: (401) 886-2236
>Pager: (800) 913-5395
>Email: aslesinger AT us.bnsmc DOT com
>
>
>Paul Fielding wrote:
>
>> >When we would archive,
>> >files were being managed under the mgt class we specified, but the
>> directories
>> >were getting backed up to the mgt class with the longest retension
period.
>> With
>> >each mgt class having a different destination tape pool, many many tapes
>> were
>> >being mounted! We don't worry about this now when there is only mgt
class
>> per
>> >domain.
>>
>> It seems to me that you're limiting your flexibility alot by doing it
this
>> way. Essentially, you're limiting each client to one mgmt class. I
would
>> personally find that unacceptable. Why don't you try using a Directory
Mgmt
>> Class? If you set a DIRMC in a client options set, point it to a 100 MB
>> (even that is overkill) disk pool that migrates to it's own tape pool
(I've
>> yet to ever go over one tape in the tape pool for any installation I've
>> done), you effectively send all extended directory information to one
place,
>> simplifying your life. Just make sure you give it a good long retention.
>>
>> The way you're using Domains is not the way it was intended. Domains
were
>> intended to allow segregation of clients that have drastically different
>> needs/policies/etc, generally separating large departments that want
>> independant control over their storage. It was not intended as a fix to
>> lots of tape mounts, and I don't think should be taken as such, you only
>> limit yourself in the long term....
>>
>> Paul
>
>--
|