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 <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 10/22/2007 02:01 PM Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To ADSM-L@VM.MARIST.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" <[EMAIL PROTECTED]> To: <ADSM-L@VM.MARIST.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 <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > 10/22/2007 01:29 PM > Please respond to > "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > To > ADSM-L@VM.MARIST.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" <[EMAIL PROTECTED]> > To: <ADSM-L@VM.MARIST.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 <[EMAIL PROTECTED]> >> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> >> 10/22/2007 12:59 PM >> Please respond to >> "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> >> >> >> To >> ADSM-L@VM.MARIST.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 >> [EMAIL PROTECTED] >>
