They are, but for retention purposes they do work as the same one. In
other words, when a node is moved from one domain to another, no rebinding
takes place. Which I'm very glad of, since I don't know how we'd do this
otherwise. :-)
_________________________________
Kathleen Hallahan
Freddie Mac
Larry Clark <lclark01 AT NYCAP.RR DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
10/22/2007 02:01 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Re: Sropping expiration for specific clients
Ok, just wanted to clarify. Those would be different management classes
even
though they have the same name.
----- Original Message -----
From: "Kathleen M Hallahan" <Kathleen_Hallahan AT FREDDIEMAC DOT COM>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Monday, October 22, 2007 1:33 PM
Subject: Re: [ADSM-L] Sropping expiration for specific clients
> Yes, exactly. We have a domain with its own copygroup, storage pools,
> etc. We just reuse the names of the management classes and assign
> different retention to them inside of those. Since our management
classes
> are pretty standardized anyway, it's not too complicated to do.
>
> _________________________________
>
> Kathleen Hallahan
> Freddie Mac
>
>
>
>
>
> Larry Clark <lclark01 AT NYCAP.RR DOT COM>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 10/22/2007 01:29 PM
> Please respond to
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To
> ADSM-L AT VM.MARIST DOT EDU
> cc
>
> Subject
> Re: Sropping expiration for specific clients
>
>
>
>
>
>
> hmmmm.......
> so would you define a new copygroup in the new domain with new retention
> rules using the same managment class (name)?
>
> ----- Original Message -----
> From: "Kathleen M Hallahan" <Kathleen_Hallahan AT FREDDIEMAC DOT COM>
> To: <ADSM-L AT VM.MARIST DOT EDU>
> Sent: Monday, October 22, 2007 1:15 PM
> Subject: Re: [ADSM-L] Sropping expiration for specific clients
>
>
>> Joy,
>>
>> Our approach has been to create a separate domain which contain the
same
>> management classes that the data is already bound to. In this way, we
> can
>> move the affected nodes to the new domain with no rebinding of data,
and
>> maintain the inactive as well as the active data. It also allows TSM
to
>> continue tracking and protecting the data We then, of course, expect
> the
>> platform areas to restore the data they need to a separate location, so
>> that we aren't stuck with open-ended interminable retention
requirements
>> that no one can agree to revert....
>>
>> Hope this is useful!
>>
>> Kathleen
>>
>> _________________________________
>>
>> Kathleen Hallahan
>> Freddie Mac
>>
>>
>>
>>
>>
>> Joy Hanna <JoyHanna AT FREIGHTLINER DOT COM>
>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>> 10/22/2007 12:59 PM
>> Please respond to
>> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>
>>
>> To
>> ADSM-L AT VM.MARIST DOT EDU
>> cc
>>
>> Subject
>> Sropping expiration for specific clients
>>
>>
>>
>>
>>
>>
>> Hello,
>> Due to a legal request we are being asked not to expire any data for
>> some specific TSM clients. Is there a way to exclude a group of clients
>> from expiring any data for a time period? I see there is a way to do
>> this for archived data. I'm talking incremental backup data. If I stop
>> expiring altogether I think it wouldn't be long before I put my whole
>> environment at risk. The only way I can think of to do this would be to
>> rename all filespaces where I suspect there might be data I do not want
>> to expire. This however would cause all those renamed filespaces to
back
>> up in full tonight. We're talking several TB of file server data. Any
>> ideas? Sincerely, Joy
>>
>> Joy Hanna
>> Enterprise Storage Group
>> I.T. Computer Operations
>> (503)745-7748
>> Joyhanna AT freightliner DOT com
>>
|