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]
Re: 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]
Re: Sropping expiration for specific clients
I'd consider looking at something like defining a new policy domain with new retention rules, then doing an: update node node name domain=new domain (for the node with your new special retention needs) with the consideration below in mind. from the manual: For servers with data retention protection enabled, an archived registered node cannot be reassigned to a different policy domain. See the Administrator's Guide for more information. never did it myself - Original Message - From: Joy Hanna [EMAIL PROTECTED] To: ADSM-L@VM.MARIST.EDU Sent: Monday, October 22, 2007 12:59 PM Subject: [ADSM-L] 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]
Re: Sropping expiration for specific clients
Been there, done that. There is no way to stop expiration for only some nodes. It is either all or nothing. A few options: - export the data on the clients you do NOT want to expire. That would keep them on their own, but you would need to import it with relative dates when you wanted to look at it. - If the data is all archived to it's own management class, you could raise the retention on that MC to keep it around longer. Ben -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Joy Hanna Sent: Monday, October 22, 2007 10:59 AM To: ADSM-L@VM.MARIST.EDU 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]
Re: Sropping expiration for specific clients
h... 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]
Re: 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 h... 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]
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 h... 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]
Re: Sropping expiration for specific clients
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 h... 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]
