Re: TSM RFE regarding Litigation Hold
We're clearly deep into the mire of exactly how TSM works. But, it the Developers pick up this request, they'll figure something out; either for Client Backup or Expire, or both. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Wednesday, May 08, 2013 12:45 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold I believe the TSM client enforces the # of versions limit specified in the management class, but not the retention attributes (# of days to keep inactive versions). Only the TSM Expiration process will purge inactive objects when they reach their Retain limits (retextra, retonly). If your management class is setup to retain 3 versions, and 3 versions already exist when the TSM client tries to backup a 4th, I believe the TSM client will roll off the oldest version making it unrestorable (and unquery-able). Whether the database entries are actually purged at that point, or if that doesn't happen until expiration runs, doesn't really matter - you won't be able to restore that 4th, oldest version. If you were not running Expiration before, then you would not have been purging inactive objects that exceeded their retention limits. ..Paul At 12:33 PM 5/8/2013, Vandeventer, Harold [BS] wrote: >On the point by Wanda regarding when files are "lost." > >I was just visiting with one of my co-workers that built our original TSM >environment several years ago; IBM was here to help. > >It was observed that storage capacity was filling quickly, even though policy >was set to a few versions and some number of days for the last version. > >IBM reviewed the setup and observed the Field Engineer had forgotten to have >us run expiration; so each node had dozens of versions and long ago deleted >files. > >That makes it sound like the backup event actually marks a file to be deleted >from the DB, and that a later expiration process does the actual removal. > >It apparently took several hours to get through the expire inventory processes >to remove all the old files. > >In my case, my need was/is to make sure nothing is lost for selected file >spaces on 5 nodes. Expiration of other nodes, or even some file space of >these 5, should proceed as normal, allowing to recover storage space. > >However it happens under the cover, hopefully a "simple checkbox" would make >it a very quick and simple task avoiding the management of alternate domains, >etc. > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf >Of Prather, Wanda >Sent: Wednesday, May 08, 2013 10:34 AM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > >Just want to clarify something for people who haven't dealt with this before. >It depends on what you mean when you say "stop expiration". > >Suppose you have the copy group limit set to 30 versions. >If the client is still backing up, the 31st version will still roll off and be >not-restorable, no matter whether you run the command EXPIRE INVENTORY or not. > >If you have the copy group limit set to 30 days, the inactive versions will >still roll off and be not-restorable, whether you run the command EXPIRE >INVENTORY or not. > >So it depends on what you mean by "stop expiration". >The only way to keep versions from expiring, is to change the copy group >settings to NOLIM, whether in the current domain or a new domain or a new >server. > >The only thing you can do by not running "expire inventory", is to >prevent yourself getting back DB space and scratch tapes, as the tape >%utilization values won't get updated. (I've always thought the >command EXPIRE INVENTORY should be renamed to "DBCLEANUP", as it >doesn't really affect expiration of files.) > >Of course a set of data created on external sequential media (via create >backupset or export) isn't mapped by the DB and therefore isn't subject to >rolling off. > >W > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf >Of Vandeventer, Harold [BS] >Sent: Tuesday, May 07, 2013 3:36 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > >Great ideas Paul I'm preparing to build the alternate server without >expiration approach as soon as I can scare up some resources. > >I'll look at the alternate Domain approach also. > > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf >Of Paul Zarnowski >Sent: Tuesday, May 07, 2013 12:54 PM >To: ADSM-L@V
Re: TSM RFE regarding Litigation Hold
I believe the TSM client enforces the # of versions limit specified in the management class, but not the retention attributes (# of days to keep inactive versions). Only the TSM Expiration process will purge inactive objects when they reach their Retain limits (retextra, retonly). If your management class is setup to retain 3 versions, and 3 versions already exist when the TSM client tries to backup a 4th, I believe the TSM client will roll off the oldest version making it unrestorable (and unquery-able). Whether the database entries are actually purged at that point, or if that doesn't happen until expiration runs, doesn't really matter - you won't be able to restore that 4th, oldest version. If you were not running Expiration before, then you would not have been purging inactive objects that exceeded their retention limits. ..Paul At 12:33 PM 5/8/2013, Vandeventer, Harold [BS] wrote: >On the point by Wanda regarding when files are "lost." > >I was just visiting with one of my co-workers that built our original TSM >environment several years ago; IBM was here to help. > >It was observed that storage capacity was filling quickly, even though policy >was set to a few versions and some number of days for the last version. > >IBM reviewed the setup and observed the Field Engineer had forgotten to have >us run expiration; so each node had dozens of versions and long ago deleted >files. > >That makes it sound like the backup event actually marks a file to be deleted >from the DB, and that a later expiration process does the actual removal. > >It apparently took several hours to get through the expire inventory processes >to remove all the old files. > >In my case, my need was/is to make sure nothing is lost for selected file >spaces on 5 nodes. Expiration of other nodes, or even some file space of >these 5, should proceed as normal, allowing to recover storage space. > >However it happens under the cover, hopefully a "simple checkbox" would make >it a very quick and simple task avoiding the management of alternate domains, >etc. > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of >Prather, Wanda >Sent: Wednesday, May 08, 2013 10:34 AM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > >Just want to clarify something for people who haven't dealt with this before. >It depends on what you mean when you say "stop expiration". > >Suppose you have the copy group limit set to 30 versions. >If the client is still backing up, the 31st version will still roll off and be >not-restorable, no matter whether you run the command EXPIRE INVENTORY or not. > >If you have the copy group limit set to 30 days, the inactive versions will >still roll off and be not-restorable, whether you run the command EXPIRE >INVENTORY or not. > >So it depends on what you mean by "stop expiration". >The only way to keep versions from expiring, is to change the copy group >settings to NOLIM, whether in the current domain or a new domain or a new >server. > >The only thing you can do by not running "expire inventory", is to prevent >yourself getting back DB space and scratch tapes, as the tape %utilization >values won't get updated. (I've always thought the command EXPIRE INVENTORY >should be renamed to "DBCLEANUP", as it doesn't really affect expiration of >files.) > >Of course a set of data created on external sequential media (via create >backupset or export) isn't mapped by the DB and therefore isn't subject to >rolling off. > >W > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of >Vandeventer, Harold [BS] >Sent: Tuesday, May 07, 2013 3:36 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > >Great ideas Paul I'm preparing to build the alternate server without >expiration approach as soon as I can scare up some resources. > >I'll look at the alternate Domain approach also. > > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul >Zarnowski >Sent: Tuesday, May 07, 2013 12:54 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > >We deal with a variety of types of litigation hold here, as well. What you >can do now, easily, is to setup a parallel policy domain (i.e., LITHOLD) that >has all the same management classes, but different retention policy (i.e., >retain forever). Then, to avoid expiration you just have to do this: > >UPDATE NODE nodename DOMAIN=
Re: TSM RFE regarding Litigation Hold
On the point by Wanda regarding when files are "lost." I was just visiting with one of my co-workers that built our original TSM environment several years ago; IBM was here to help. It was observed that storage capacity was filling quickly, even though policy was set to a few versions and some number of days for the last version. IBM reviewed the setup and observed the Field Engineer had forgotten to have us run expiration; so each node had dozens of versions and long ago deleted files. That makes it sound like the backup event actually marks a file to be deleted from the DB, and that a later expiration process does the actual removal. It apparently took several hours to get through the expire inventory processes to remove all the old files. In my case, my need was/is to make sure nothing is lost for selected file spaces on 5 nodes. Expiration of other nodes, or even some file space of these 5, should proceed as normal, allowing to recover storage space. However it happens under the cover, hopefully a "simple checkbox" would make it a very quick and simple task avoiding the management of alternate domains, etc. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Wednesday, May 08, 2013 10:34 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Just want to clarify something for people who haven't dealt with this before. It depends on what you mean when you say "stop expiration". Suppose you have the copy group limit set to 30 versions. If the client is still backing up, the 31st version will still roll off and be not-restorable, no matter whether you run the command EXPIRE INVENTORY or not. If you have the copy group limit set to 30 days, the inactive versions will still roll off and be not-restorable, whether you run the command EXPIRE INVENTORY or not. So it depends on what you mean by "stop expiration". The only way to keep versions from expiring, is to change the copy group settings to NOLIM, whether in the current domain or a new domain or a new server. The only thing you can do by not running "expire inventory", is to prevent yourself getting back DB space and scratch tapes, as the tape %utilization values won't get updated. (I've always thought the command EXPIRE INVENTORY should be renamed to "DBCLEANUP", as it doesn't really affect expiration of files.) Of course a set of data created on external sequential media (via create backupset or export) isn't mapped by the DB and therefore isn't subject to rolling off. W -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Tuesday, May 07, 2013 3:36 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Great ideas Paul I'm preparing to build the alternate server without expiration approach as soon as I can scare up some resources. I'll look at the alternate Domain approach also. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Tuesday, May 07, 2013 12:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold We deal with a variety of types of litigation hold here, as well. What you can do now, easily, is to setup a parallel policy domain (i.e., LITHOLD) that has all the same management classes, but different retention policy (i.e., retain forever). Then, to avoid expiration you just have to do this: UPDATE NODE nodename DOMAIN=LITHOLD This works if you have all the same management classes defined in LITHOLD that you had defined in the original domain. You can move the node back and forth between domains as needed. If LITHOLD is missing a management class, then retention would be controlled by the "grace period" definitions of the domain - something you'll probably want to avoid. No changes needed on the client side since you're not changing management class names, just their attributes. If you have associated a schedule with the node, then you'll need to have copies of the schedules in LITHOLD and re-associate the node with the schedule in the LITHOLD domain (which can be defined the same). We also deal with other types of litigation holds that require is to take a snapshot of the data. For this, we simply export (a copy of) the node to another TSM server instance where expiration does not run or has no effect. ..Paul At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >To all... >I created an RFE to affect File Spaces and Expiration. The feature would >cause expiration processing to be skipped for a file space that has been >selected. > >It's RFE ID 33395 if you care to review and vote. > >Briefly, the idea is t
Re: TSM RFE regarding Litigation Hold
Ah, it appears I miss-understood EXACTLY what happens in expiration. The intent of a litigation is, in my case, to satisfy the instruction from legal that says: 'keep everything'. That would include versions and days to retain files going on for an extended time. So, Wanda, you've blown my idea for a simple check box it appears. (insert sad face here.) But, perhaps the checkbox doesn't override expire, but rather alters the way the files are handled during that filespace backup on each backup event. Exporting a node to an alternate server or tape, isn't a real solution if that node is large. I need to look more into the use of the alternate DOMAIN. But, still, a nice little checkbox to avoid loss of data would be great, IMHO. No extra work to manage alternate domains with mgmt classes named the same, but with NOLIM values. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Wednesday, May 08, 2013 10:34 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Just want to clarify something for people who haven't dealt with this before. It depends on what you mean when you say "stop expiration". Suppose you have the copy group limit set to 30 versions. If the client is still backing up, the 31st version will still roll off and be not-restorable, no matter whether you run the command EXPIRE INVENTORY or not. If you have the copy group limit set to 30 days, the inactive versions will still roll off and be not-restorable, whether you run the command EXPIRE INVENTORY or not. So it depends on what you mean by "stop expiration". The only way to keep versions from expiring, is to change the copy group settings to NOLIM, whether in the current domain or a new domain or a new server. The only thing you can do by not running "expire inventory", is to prevent yourself getting back DB space and scratch tapes, as the tape %utilization values won't get updated. (I've always thought the command EXPIRE INVENTORY should be renamed to "DBCLEANUP", as it doesn't really affect expiration of files.) Of course a set of data created on external sequential media (via create backupset or export) isn't mapped by the DB and therefore isn't subject to rolling off. W -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Tuesday, May 07, 2013 3:36 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Great ideas Paul I'm preparing to build the alternate server without expiration approach as soon as I can scare up some resources. I'll look at the alternate Domain approach also. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Tuesday, May 07, 2013 12:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold We deal with a variety of types of litigation hold here, as well. What you can do now, easily, is to setup a parallel policy domain (i.e., LITHOLD) that has all the same management classes, but different retention policy (i.e., retain forever). Then, to avoid expiration you just have to do this: UPDATE NODE nodename DOMAIN=LITHOLD This works if you have all the same management classes defined in LITHOLD that you had defined in the original domain. You can move the node back and forth between domains as needed. If LITHOLD is missing a management class, then retention would be controlled by the "grace period" definitions of the domain - something you'll probably want to avoid. No changes needed on the client side since you're not changing management class names, just their attributes. If you have associated a schedule with the node, then you'll need to have copies of the schedules in LITHOLD and re-associate the node with the schedule in the LITHOLD domain (which can be defined the same). We also deal with other types of litigation holds that require is to take a snapshot of the data. For this, we simply export (a copy of) the node to another TSM server instance where expiration does not run or has no effect. ..Paul At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >To all... >I created an RFE to affect File Spaces and Expiration. The feature would >cause expiration processing to be skipped for a file space that has been >selected. > >It's RFE ID 33395 if you care to review and vote. > >Briefly, the idea is to immediately respond to a situation in which we cannot >allow Expiration Processing to delete information that would otherwise be >deleted. This would be in response to a "Litigation Hold" demand from a legal >issue at hand. I've had three LitHold eve
Re: TSM RFE regarding Litigation Hold
Good points, Wanda. Just to clarify, this is the definition for our "PRESERVE" domain (what I had been calling LITHOLD earlier): tsm: ADSM6>q copy preserve PolicyPolicyMgmt Copy Versions Versions Retain Retain DomainSet Name Class Group Data DataExtraOnly NameName NameExists Deleted Versions Version - - - - --- PRESERVE ACTIVESTANDARD STANDARD No Limit No Limit No Limit No Lim- it And the domain itself: tsm: ADSM6>q dom preserve f=d Policy Domain Name: PRESERVE Activated Policy Set: STANDARD Activated Default Mgmt Class: STANDARD Number of Registered Nodes: 0 Description: R/O; Preserve Data Backup Retention (Grace Period): 9,999 Archive Retention (Grace Period): 9,999 ..Paul At 11:33 AM 5/8/2013, Prather, Wanda wrote: >Just want to clarify something for people who haven't dealt with this before. >It depends on what you mean when you say "stop expiration". > >Suppose you have the copy group limit set to 30 versions. >If the client is still backing up, the 31st version will still roll off and be >not-restorable, no matter whether you run the command EXPIRE INVENTORY or not. > >If you have the copy group limit set to 30 days, >the inactive versions will still roll off and be not-restorable, whether you >run the command EXPIRE INVENTORY or not. > >So it depends on what you mean by "stop expiration". >The only way to keep versions from expiring, is to change the copy group >settings to NOLIM, whether in the current domain or a new domain or a new >server. > >The only thing you can do by not running "expire inventory", is to prevent >yourself getting back DB space and scratch tapes, as the tape %utilization >values won't get updated. (I've always thought the command EXPIRE INVENTORY >should be renamed to "DBCLEANUP", as it doesn't really affect expiration of >files.) > >Of course a set of data created on external sequential media (via create >backupset or export) isn't mapped by the DB and therefore isn't subject to >rolling off. > >W > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of >Vandeventer, Harold [BS] >Sent: Tuesday, May 07, 2013 3:36 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > >Great ideas Paul I'm preparing to build the alternate server without >expiration approach as soon as I can scare up some resources. > >I'll look at the alternate Domain approach also. > > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul >Zarnowski >Sent: Tuesday, May 07, 2013 12:54 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > >We deal with a variety of types of litigation hold here, as well. What you >can do now, easily, is to setup a parallel policy domain (i.e., LITHOLD) that >has all the same management classes, but different retention policy (i.e., >retain forever). Then, to avoid expiration you just have to do this: > >UPDATE NODE nodename DOMAIN=LITHOLD > >This works if you have all the same management classes defined in LITHOLD that >you had defined in the original domain. You can move the node back and forth >between domains as needed. If LITHOLD is missing a management class, then >retention would be controlled by the "grace period" definitions of the domain >- something you'll probably want to avoid. > >No changes needed on the client side since you're not changing management >class names, just their attributes. > >If you have associated a schedule with the node, then you'll need to have >copies of the schedules in LITHOLD and re-associate the node with the schedule >in the LITHOLD domain (which can be defined the same). > >We also deal with other types of litigation holds that require is to take a >snapshot of the data. For this, we simply export (a copy of) the node to >another TSM server instance where expiration does not run or has no effect. > >..Paul > > >At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >>To all... >>I created an RFE to affect File Spaces and Expiration. The feature would >>cause expiration processing to be skipped for a file space that has been >>selected. >> >>It's RFE ID 33395 if you care to review and vote. >> >>Briefly, the idea is to immediately respond to a situa
Re: TSM RFE regarding Litigation Hold
Just want to clarify something for people who haven't dealt with this before. It depends on what you mean when you say "stop expiration". Suppose you have the copy group limit set to 30 versions. If the client is still backing up, the 31st version will still roll off and be not-restorable, no matter whether you run the command EXPIRE INVENTORY or not. If you have the copy group limit set to 30 days, the inactive versions will still roll off and be not-restorable, whether you run the command EXPIRE INVENTORY or not. So it depends on what you mean by "stop expiration". The only way to keep versions from expiring, is to change the copy group settings to NOLIM, whether in the current domain or a new domain or a new server. The only thing you can do by not running "expire inventory", is to prevent yourself getting back DB space and scratch tapes, as the tape %utilization values won't get updated. (I've always thought the command EXPIRE INVENTORY should be renamed to "DBCLEANUP", as it doesn't really affect expiration of files.) Of course a set of data created on external sequential media (via create backupset or export) isn't mapped by the DB and therefore isn't subject to rolling off. W -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Tuesday, May 07, 2013 3:36 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Great ideas Paul I'm preparing to build the alternate server without expiration approach as soon as I can scare up some resources. I'll look at the alternate Domain approach also. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Tuesday, May 07, 2013 12:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold We deal with a variety of types of litigation hold here, as well. What you can do now, easily, is to setup a parallel policy domain (i.e., LITHOLD) that has all the same management classes, but different retention policy (i.e., retain forever). Then, to avoid expiration you just have to do this: UPDATE NODE nodename DOMAIN=LITHOLD This works if you have all the same management classes defined in LITHOLD that you had defined in the original domain. You can move the node back and forth between domains as needed. If LITHOLD is missing a management class, then retention would be controlled by the "grace period" definitions of the domain - something you'll probably want to avoid. No changes needed on the client side since you're not changing management class names, just their attributes. If you have associated a schedule with the node, then you'll need to have copies of the schedules in LITHOLD and re-associate the node with the schedule in the LITHOLD domain (which can be defined the same). We also deal with other types of litigation holds that require is to take a snapshot of the data. For this, we simply export (a copy of) the node to another TSM server instance where expiration does not run or has no effect. ..Paul At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >To all... >I created an RFE to affect File Spaces and Expiration. The feature would >cause expiration processing to be skipped for a file space that has been >selected. > >It's RFE ID 33395 if you care to review and vote. > >Briefly, the idea is to immediately respond to a situation in which we cannot >allow Expiration Processing to delete information that would otherwise be >deleted. This would be in response to a "Litigation Hold" demand from a legal >issue at hand. I've had three LitHold events in the past 24 months; they're >not much fun and I'm not in the court room, just the TSM Server Admin. > >Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. > >When the court case is lifted, simply revert to ""LitigationHold=No". The >next Expiration process would then begin the delete process as is normal. > >The feature would avoid the complexity of assigning a "no expire" management >class to the node and trying to later revert to a more typical class. > >Please take a look at the RFE, and cast a vote if you feel it's a valuable >feature. > >Thanks. > >Harold Vandeventer >Systems Programmer >State of Kansas - Office of Information Technology Services STE 751-S >910 SW Jackson >(785) 296-0631 > > >[Confidentiality notice:] >*** >This e-mail message, including attachments, if any, is intended for the >person or e
Re: TSM RFE regarding Litigation Hold
I found a shortcut on my RFE to share with anyone as a quick way to find it. http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=33395 The link will take you through the DeveloperWorks sign-in process; if you don't have a sign-in, see the links on the page to obtain one. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Skylar Thompson Sent: Tuesday, May 07, 2013 4:46 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Unfortunately we've had expiration holds for tens of terabytes of data, so we haven't been able to use this approach. -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine On 05/07/13 14:39, Richard Rhodes wrote: > Our approach has been to export/import the node to another TSM > instance under a different node name with a suffix or prefix that indicated > the > hold. THe mgt class is set to no-expire.We stop expiration until this > copy is made. This approach has lets the node be processed as usual, > and the copy can sit for as long as needed. > > Rick > > > > > > From: "Vandeventer, Harold [BS]" > To: ADSM-L@VM.MARIST.EDU > Date: 05/07/2013 03:36 PM > Subject:Re: TSM RFE regarding Litigation Hold > Sent by:"ADSM: Dist Stor Manager" > > > > Great ideas Paul I'm preparing to build the alternate server > without expiration approach as soon as I can scare up some resources. > > I'll look at the alternate Domain approach also. > > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of Paul Zarnowski > Sent: Tuesday, May 07, 2013 12:54 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > > We deal with a variety of types of litigation hold here, as well. > What you can do now, easily, is to setup a parallel policy domain > (i.e., > LITHOLD) that has all the same management classes, but different > retention policy (i.e., retain forever). Then, to avoid expiration > you just have to do this: > > UPDATE NODE nodename DOMAIN=LITHOLD > > This works if you have all the same management classes defined in > LITHOLD that you had defined in the original domain. You can move the > node back and forth between domains as needed. If LITHOLD is missing > a management class, then retention would be controlled by the "grace period" > definitions of the domain - something you'll probably want to avoid. > > No changes needed on the client side since you're not changing > management class names, just their attributes. > > If you have associated a schedule with the node, then you'll need to > have copies of the schedules in LITHOLD and re-associate the node with > the schedule in the LITHOLD domain (which can be defined the same). > > We also deal with other types of litigation holds that require is to > take a snapshot of the data. For this, we simply export (a copy of) > the node to another TSM server instance where expiration does not run > or has no effect. > > ..Paul > > > At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >> To all... >> I created an RFE to affect File Spaces and Expiration. The feature >> would > cause expiration processing to be skipped for a file space that has > been selected. >> >> It's RFE ID 33395 if you care to review and vote. >> >> Briefly, the idea is to immediately respond to a situation in which >> we > cannot allow Expiration Processing to delete information that would > otherwise be deleted. This would be in response to a "Litigation Hold" > demand from a legal issue at hand. I've had three LitHold events in > the past 24 months; they're not much fun and I'm not in the court > room, just the TSM Server Admin. >> >> Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. >> >> When the court case is lifted, simply revert to ""LitigationHold=No". >> The > next Expiration process would then begin the delete process as is normal. >> >> The feature would avoid the complexity of assigning a "no expire" > management class to the node and trying to later revert to a more > typical class. >> >> Please take a look at the RFE, and cast a vote if you feel it's a > valuable feature. >> >> Thanks. >> >> Harold Vandeventer &
Re: TSM RFE regarding Litigation Hold
Rick, Your note reminded me that I left out a couple of steps in my description of what we do. We also change the nodename on the node as it is exported to the other server. We don't suspend expiration while the export is running. Instead, we change it's domain on the original server while the export is running. That domain has all the same management classes as the original domain, but with infinite copies and retention. Once the export is complete, we move the original node back to its original domain. Fixing up the schedule association. This allows expiration to continue running for all other nodes on the server. Harold, changing the domain of the node would have the immediate effect that you are looking for. ..Paul At 05:39 PM 5/7/2013, Richard Rhodes wrote: >Our approach has been to export/import the node to another TSM instance >under a different node name with a suffix or prefix that indicated the >hold. THe mgt class is set to no-expire.We stop expiration until this >copy is made. This approach has lets the node be processed as usual, and >the copy can sit for as long as needed. > >Rick > > > > > >From: "Vandeventer, Harold [BS]" >To: ADSM-L@VM.MARIST.EDU >Date: 05/07/2013 03:36 PM >Subject:Re: TSM RFE regarding Litigation Hold >Sent by:"ADSM: Dist Stor Manager" > > > >Great ideas Paul I'm preparing to build the alternate server without >expiration approach as soon as I can scare up some resources. > >I'll look at the alternate Domain approach also. > > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of >Paul Zarnowski >Sent: Tuesday, May 07, 2013 12:54 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > >We deal with a variety of types of litigation hold here, as well. What >you can do now, easily, is to setup a parallel policy domain (i.e., >LITHOLD) that has all the same management classes, but different retention >policy (i.e., retain forever). Then, to avoid expiration you just have to >do this: > >UPDATE NODE nodename DOMAIN=LITHOLD > >This works if you have all the same management classes defined in LITHOLD >that you had defined in the original domain. You can move the node back >and forth between domains as needed. If LITHOLD is missing a management >class, then retention would be controlled by the "grace period" >definitions of the domain - something you'll probably want to avoid. > >No changes needed on the client side since you're not changing management >class names, just their attributes. > >If you have associated a schedule with the node, then you'll need to have >copies of the schedules in LITHOLD and re-associate the node with the >schedule in the LITHOLD domain (which can be defined the same). > >We also deal with other types of litigation holds that require is to take >a snapshot of the data. For this, we simply export (a copy of) the node >to another TSM server instance where expiration does not run or has no >effect. > >..Paul > > >At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >>To all... >>I created an RFE to affect File Spaces and Expiration. The feature would >cause expiration processing to be skipped for a file space that has been >selected. >> >>It's RFE ID 33395 if you care to review and vote. >> >>Briefly, the idea is to immediately respond to a situation in which we >cannot allow Expiration Processing to delete information that would >otherwise be deleted. This would be in response to a "Litigation Hold" >demand from a legal issue at hand. I've had three LitHold events in the >past 24 months; they're not much fun and I'm not in the court room, just >the TSM Server Admin. >> >>Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. >> >>When the court case is lifted, simply revert to ""LitigationHold=No". The >next Expiration process would then begin the delete process as is normal. >> >>The feature would avoid the complexity of assigning a "no expire" >management class to the node and trying to later revert to a more typical >class. >> >>Please take a look at the RFE, and cast a vote if you feel it's a >valuable feature. >> >>Thanks. >> >>Harold Vandeventer >>Systems Programmer >>State of Kansas - Office of Information Technology Services STE 751-S >>910 SW Jackson >>(785
Re: TSM RFE regarding Litigation Hold
I've used the export to another server solution, but this last event was the most troublesome. Five very large nodes, it took nearly a week to export one of them. Complicated by the impact on storage resources. (That's another battle I'm fighting at the moment.) Thus, my comment in the RFE about the "immediate" ability to refrain expiration. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Richard Rhodes Sent: Tuesday, May 07, 2013 4:39 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Our approach has been to export/import the node to another TSM instance under a different node name with a suffix or prefix that indicated the hold. THe mgt class is set to no-expire.We stop expiration until this copy is made. This approach has lets the node be processed as usual, and the copy can sit for as long as needed. Rick From: "Vandeventer, Harold [BS]" To: ADSM-L@VM.MARIST.EDU Date: 05/07/2013 03:36 PM Subject: Re: TSM RFE regarding Litigation Hold Sent by:"ADSM: Dist Stor Manager" Great ideas Paul I'm preparing to build the alternate server without expiration approach as soon as I can scare up some resources. I'll look at the alternate Domain approach also. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Tuesday, May 07, 2013 12:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold We deal with a variety of types of litigation hold here, as well. What you can do now, easily, is to setup a parallel policy domain (i.e., LITHOLD) that has all the same management classes, but different retention policy (i.e., retain forever). Then, to avoid expiration you just have to do this: UPDATE NODE nodename DOMAIN=LITHOLD This works if you have all the same management classes defined in LITHOLD that you had defined in the original domain. You can move the node back and forth between domains as needed. If LITHOLD is missing a management class, then retention would be controlled by the "grace period" definitions of the domain - something you'll probably want to avoid. No changes needed on the client side since you're not changing management class names, just their attributes. If you have associated a schedule with the node, then you'll need to have copies of the schedules in LITHOLD and re-associate the node with the schedule in the LITHOLD domain (which can be defined the same). We also deal with other types of litigation holds that require is to take a snapshot of the data. For this, we simply export (a copy of) the node to another TSM server instance where expiration does not run or has no effect. ..Paul At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >To all... >I created an RFE to affect File Spaces and Expiration. The feature >would cause expiration processing to be skipped for a file space that has been selected. > >It's RFE ID 33395 if you care to review and vote. > >Briefly, the idea is to immediately respond to a situation in which we cannot allow Expiration Processing to delete information that would otherwise be deleted. This would be in response to a "Litigation Hold" demand from a legal issue at hand. I've had three LitHold events in the past 24 months; they're not much fun and I'm not in the court room, just the TSM Server Admin. > >Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. > >When the court case is lifted, simply revert to ""LitigationHold=No". >The next Expiration process would then begin the delete process as is normal. > >The feature would avoid the complexity of assigning a "no expire" management class to the node and trying to later revert to a more typical class. > >Please take a look at the RFE, and cast a vote if you feel it's a valuable feature. > >Thanks. > >Harold Vandeventer >Systems Programmer >State of Kansas - Office of Information Technology Services STE 751-S >910 SW Jackson >(785) 296-0631 > > >[Confidentiality notice:] >*** >This e-mail message, including attachments, if any, is intended for the >person or entity to which it is addressed and may contain confidential >or privileged information. Any unauthorized review, use, or disclosure >is prohibited. If you are not the intended recipient, please contact >the sender and destroy the original message, including all copies, >Thank you. >*** -- Paul Zarnowski
Re: TSM RFE regarding Litigation Hold
Unfortunately we've had expiration holds for tens of terabytes of data, so we haven't been able to use this approach. -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine On 05/07/13 14:39, Richard Rhodes wrote: > Our approach has been to export/import the node to another TSM instance > under a different node name with a suffix or prefix that indicated the > hold. THe mgt class is set to no-expire.We stop expiration until this > copy is made. This approach has lets the node be processed as usual, and > the copy can sit for as long as needed. > > Rick > > > > > > From: "Vandeventer, Harold [BS]" > To: ADSM-L@VM.MARIST.EDU > Date: 05/07/2013 03:36 PM > Subject:Re: TSM RFE regarding Litigation Hold > Sent by:"ADSM: Dist Stor Manager" > > > > Great ideas Paul I'm preparing to build the alternate server without > expiration approach as soon as I can scare up some resources. > > I'll look at the alternate Domain approach also. > > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Paul Zarnowski > Sent: Tuesday, May 07, 2013 12:54 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold > > We deal with a variety of types of litigation hold here, as well. What > you can do now, easily, is to setup a parallel policy domain (i.e., > LITHOLD) that has all the same management classes, but different retention > policy (i.e., retain forever). Then, to avoid expiration you just have to > do this: > > UPDATE NODE nodename DOMAIN=LITHOLD > > This works if you have all the same management classes defined in LITHOLD > that you had defined in the original domain. You can move the node back > and forth between domains as needed. If LITHOLD is missing a management > class, then retention would be controlled by the "grace period" > definitions of the domain - something you'll probably want to avoid. > > No changes needed on the client side since you're not changing management > class names, just their attributes. > > If you have associated a schedule with the node, then you'll need to have > copies of the schedules in LITHOLD and re-associate the node with the > schedule in the LITHOLD domain (which can be defined the same). > > We also deal with other types of litigation holds that require is to take > a snapshot of the data. For this, we simply export (a copy of) the node > to another TSM server instance where expiration does not run or has no > effect. > > ..Paul > > > At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >> To all... >> I created an RFE to affect File Spaces and Expiration. The feature would > cause expiration processing to be skipped for a file space that has been > selected. >> >> It's RFE ID 33395 if you care to review and vote. >> >> Briefly, the idea is to immediately respond to a situation in which we > cannot allow Expiration Processing to delete information that would > otherwise be deleted. This would be in response to a "Litigation Hold" > demand from a legal issue at hand. I've had three LitHold events in the > past 24 months; they're not much fun and I'm not in the court room, just > the TSM Server Admin. >> >> Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. >> >> When the court case is lifted, simply revert to ""LitigationHold=No". The > next Expiration process would then begin the delete process as is normal. >> >> The feature would avoid the complexity of assigning a "no expire" > management class to the node and trying to later revert to a more typical > class. >> >> Please take a look at the RFE, and cast a vote if you feel it's a > valuable feature. >> >> Thanks. >> >> Harold Vandeventer >> Systems Programmer >> State of Kansas - Office of Information Technology Services STE 751-S >> 910 SW Jackson >> (785) 296-0631 >> >> >> [Confidentiality notice:] >> *** >> This e-mail message, including attachments, if any, is intended for the >> person or entity to which it is addressed and may contain confidential >> or privileged information. Any unauthorized review, use, or disclosure >> is prohibited. If you are not the intended recipient, please
Re: TSM RFE regarding Litigation Hold
Our approach has been to export/import the node to another TSM instance under a different node name with a suffix or prefix that indicated the hold. THe mgt class is set to no-expire.We stop expiration until this copy is made. This approach has lets the node be processed as usual, and the copy can sit for as long as needed. Rick From: "Vandeventer, Harold [BS]" To: ADSM-L@VM.MARIST.EDU Date: 05/07/2013 03:36 PM Subject:Re: TSM RFE regarding Litigation Hold Sent by:"ADSM: Dist Stor Manager" Great ideas Paul I'm preparing to build the alternate server without expiration approach as soon as I can scare up some resources. I'll look at the alternate Domain approach also. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Tuesday, May 07, 2013 12:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold We deal with a variety of types of litigation hold here, as well. What you can do now, easily, is to setup a parallel policy domain (i.e., LITHOLD) that has all the same management classes, but different retention policy (i.e., retain forever). Then, to avoid expiration you just have to do this: UPDATE NODE nodename DOMAIN=LITHOLD This works if you have all the same management classes defined in LITHOLD that you had defined in the original domain. You can move the node back and forth between domains as needed. If LITHOLD is missing a management class, then retention would be controlled by the "grace period" definitions of the domain - something you'll probably want to avoid. No changes needed on the client side since you're not changing management class names, just their attributes. If you have associated a schedule with the node, then you'll need to have copies of the schedules in LITHOLD and re-associate the node with the schedule in the LITHOLD domain (which can be defined the same). We also deal with other types of litigation holds that require is to take a snapshot of the data. For this, we simply export (a copy of) the node to another TSM server instance where expiration does not run or has no effect. ..Paul At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >To all... >I created an RFE to affect File Spaces and Expiration. The feature would cause expiration processing to be skipped for a file space that has been selected. > >It's RFE ID 33395 if you care to review and vote. > >Briefly, the idea is to immediately respond to a situation in which we cannot allow Expiration Processing to delete information that would otherwise be deleted. This would be in response to a "Litigation Hold" demand from a legal issue at hand. I've had three LitHold events in the past 24 months; they're not much fun and I'm not in the court room, just the TSM Server Admin. > >Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. > >When the court case is lifted, simply revert to ""LitigationHold=No". The next Expiration process would then begin the delete process as is normal. > >The feature would avoid the complexity of assigning a "no expire" management class to the node and trying to later revert to a more typical class. > >Please take a look at the RFE, and cast a vote if you feel it's a valuable feature. > >Thanks. > >Harold Vandeventer >Systems Programmer >State of Kansas - Office of Information Technology Services STE 751-S >910 SW Jackson >(785) 296-0631 > > >[Confidentiality notice:] >*** >This e-mail message, including attachments, if any, is intended for the >person or entity to which it is addressed and may contain confidential >or privileged information. Any unauthorized review, use, or disclosure >is prohibited. If you are not the intended recipient, please contact >the sender and destroy the original message, including all copies, >Thank you. >*** -- Paul ZarnowskiPh: 607-255-4757 Manager of Storage Services Fx: 607-255-8521 IT at Cornell / InfrastructureEm: p...@cornell.edu 719 Rhodes Hall, Ithaca, NY 14853-3801 - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: TSM RFE regarding Litigation Hold
Great ideas Paul I'm preparing to build the alternate server without expiration approach as soon as I can scare up some resources. I'll look at the alternate Domain approach also. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Tuesday, May 07, 2013 12:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold We deal with a variety of types of litigation hold here, as well. What you can do now, easily, is to setup a parallel policy domain (i.e., LITHOLD) that has all the same management classes, but different retention policy (i.e., retain forever). Then, to avoid expiration you just have to do this: UPDATE NODE nodename DOMAIN=LITHOLD This works if you have all the same management classes defined in LITHOLD that you had defined in the original domain. You can move the node back and forth between domains as needed. If LITHOLD is missing a management class, then retention would be controlled by the "grace period" definitions of the domain - something you'll probably want to avoid. No changes needed on the client side since you're not changing management class names, just their attributes. If you have associated a schedule with the node, then you'll need to have copies of the schedules in LITHOLD and re-associate the node with the schedule in the LITHOLD domain (which can be defined the same). We also deal with other types of litigation holds that require is to take a snapshot of the data. For this, we simply export (a copy of) the node to another TSM server instance where expiration does not run or has no effect. ..Paul At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >To all... >I created an RFE to affect File Spaces and Expiration. The feature would >cause expiration processing to be skipped for a file space that has been >selected. > >It's RFE ID 33395 if you care to review and vote. > >Briefly, the idea is to immediately respond to a situation in which we cannot >allow Expiration Processing to delete information that would otherwise be >deleted. This would be in response to a "Litigation Hold" demand from a legal >issue at hand. I've had three LitHold events in the past 24 months; they're >not much fun and I'm not in the court room, just the TSM Server Admin. > >Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. > >When the court case is lifted, simply revert to ""LitigationHold=No". The >next Expiration process would then begin the delete process as is normal. > >The feature would avoid the complexity of assigning a "no expire" management >class to the node and trying to later revert to a more typical class. > >Please take a look at the RFE, and cast a vote if you feel it's a valuable >feature. > >Thanks. > >Harold Vandeventer >Systems Programmer >State of Kansas - Office of Information Technology Services STE 751-S >910 SW Jackson >(785) 296-0631 > > >[Confidentiality notice:] >*** >This e-mail message, including attachments, if any, is intended for the >person or entity to which it is addressed and may contain confidential >or privileged information. Any unauthorized review, use, or disclosure >is prohibited. If you are not the intended recipient, please contact >the sender and destroy the original message, including all copies, >Thank you. >*** -- Paul ZarnowskiPh: 607-255-4757 Manager of Storage Services Fx: 607-255-8521 IT at Cornell / InfrastructureEm: p...@cornell.edu 719 Rhodes Hall, Ithaca, NY 14853-3801
Re: TSM RFE regarding Litigation Hold
We deal with a variety of types of litigation hold here, as well. What you can do now, easily, is to setup a parallel policy domain (i.e., LITHOLD) that has all the same management classes, but different retention policy (i.e., retain forever). Then, to avoid expiration you just have to do this: UPDATE NODE nodename DOMAIN=LITHOLD This works if you have all the same management classes defined in LITHOLD that you had defined in the original domain. You can move the node back and forth between domains as needed. If LITHOLD is missing a management class, then retention would be controlled by the "grace period" definitions of the domain - something you'll probably want to avoid. No changes needed on the client side since you're not changing management class names, just their attributes. If you have associated a schedule with the node, then you'll need to have copies of the schedules in LITHOLD and re-associate the node with the schedule in the LITHOLD domain (which can be defined the same). We also deal with other types of litigation holds that require is to take a snapshot of the data. For this, we simply export (a copy of) the node to another TSM server instance where expiration does not run or has no effect. ..Paul At 05:05 PM 5/3/2013, Vandeventer, Harold [BS] wrote: >To all... >I created an RFE to affect File Spaces and Expiration. The feature would >cause expiration processing to be skipped for a file space that has been >selected. > >It's RFE ID 33395 if you care to review and vote. > >Briefly, the idea is to immediately respond to a situation in which we cannot >allow Expiration Processing to delete information that would otherwise be >deleted. This would be in response to a "Litigation Hold" demand from a legal >issue at hand. I've had three LitHold events in the past 24 months; they're >not much fun and I'm not in the court room, just the TSM Server Admin. > >Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. > >When the court case is lifted, simply revert to ""LitigationHold=No". The >next Expiration process would then begin the delete process as is normal. > >The feature would avoid the complexity of assigning a "no expire" management >class to the node and trying to later revert to a more typical class. > >Please take a look at the RFE, and cast a vote if you feel it's a valuable >feature. > >Thanks. > >Harold Vandeventer >Systems Programmer >State of Kansas - Office of Information Technology Services >STE 751-S >910 SW Jackson >(785) 296-0631 > > >[Confidentiality notice:] >*** >This e-mail message, including attachments, if any, is intended for the >person or entity to which it is addressed and may contain confidential >or privileged information. Any unauthorized review, use, or disclosure >is prohibited. If you are not the intended recipient, please contact >the sender and destroy the original message, including all copies, >Thank you. >*** -- Paul ZarnowskiPh: 607-255-4757 Manager of Storage Services Fx: 607-255-8521 IT at Cornell / InfrastructureEm: p...@cornell.edu 719 Rhodes Hall, Ithaca, NY 14853-3801
Re: TSM RFE regarding Litigation Hold
Ditto -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Plair, Ricky Sent: Tuesday, May 07, 2013 12:52 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Sure could have used this in the past! Got my vote! -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Ben Bullock Sent: Tuesday, May 07, 2013 1:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Got it. Voted. Thanks -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Reese, Michael A (Mike) CIV USARMY 93 SIG BDE (US) Sent: Tuesday, May 07, 2013 11:01 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold I agree this is a great RFE, and I have added my vote to it. Go to https://urldefense.proofpoint.com/v1/url?u=http://www.ibm.com/developerworks/rfe/?BRAND_ID%3D90&k=Kv4nkNfjdxVgeJz6Pg57qw%3D%3D%0A&r=I1HLMFJ6m%2BiVcavWgCBtVd78uShy4GoDLiStkJAJ6wk%3D%0A&m=x%2B6alTX5na7BL9zpHHo5bVZ89hIdgEmEAeC8GEPEa%2Bg%3D%0A&s=ae4c9e66642e3d122c6b1cff72603aa38cde0082ba1db6bf819f1f4a2336a5d2. You will need to sign in with your IBM ID to vote. Search by RFE ID to go to the desired RFE. Open the RFE and then click "Add vote" under RFE actions. From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of Ben Bullock [bbull...@bcidaho.com] Sent: Tuesday, May 07, 2013 10:59 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold That sounds like a great RFE, one I could have used a couple times in the past. How can we "vote" on this? I'm not familiar with how to do that with IBM RFEs. Thanks, Ben -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Friday, May 03, 2013 3:06 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM RFE regarding Litigation Hold To all... I created an RFE to affect File Spaces and Expiration. The feature would cause expiration processing to be skipped for a file space that has been selected. It's RFE ID 33395 if you care to review and vote. Briefly, the idea is to immediately respond to a situation in which we cannot allow Expiration Processing to delete information that would otherwise be deleted. This would be in response to a "Litigation Hold" demand from a legal issue at hand. I've had three LitHold events in the past 24 months; they're not much fun and I'm not in the court room, just the TSM Server Admin. Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. When the court case is lifted, simply revert to ""LitigationHold=No". The next Expiration process would then begin the delete process as is normal. The feature would avoid the complexity of assigning a "no expire" management class to the node and trying to later revert to a more typical class. Please take a look at the RFE, and cast a vote if you feel it's a valuable feature. Thanks. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. *** -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Blue Cross of Idaho, 3000 E. Pine Ave, Meridian, ID 83642 -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Blue Cross of Idaho, 3000 E. Pine Ave, Meridian, ID 83642 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CONFIDENTIALITY NOTICE: If you hav
Re: TSM RFE regarding Litigation Hold
Sure could have used this in the past! Got my vote! -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Ben Bullock Sent: Tuesday, May 07, 2013 1:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold Got it. Voted. Thanks -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Reese, Michael A (Mike) CIV USARMY 93 SIG BDE (US) Sent: Tuesday, May 07, 2013 11:01 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold I agree this is a great RFE, and I have added my vote to it. Go to https://urldefense.proofpoint.com/v1/url?u=http://www.ibm.com/developerworks/rfe/?BRAND_ID%3D90&k=Kv4nkNfjdxVgeJz6Pg57qw%3D%3D%0A&r=I1HLMFJ6m%2BiVcavWgCBtVd78uShy4GoDLiStkJAJ6wk%3D%0A&m=x%2B6alTX5na7BL9zpHHo5bVZ89hIdgEmEAeC8GEPEa%2Bg%3D%0A&s=ae4c9e66642e3d122c6b1cff72603aa38cde0082ba1db6bf819f1f4a2336a5d2. You will need to sign in with your IBM ID to vote. Search by RFE ID to go to the desired RFE. Open the RFE and then click "Add vote" under RFE actions. From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of Ben Bullock [bbull...@bcidaho.com] Sent: Tuesday, May 07, 2013 10:59 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold That sounds like a great RFE, one I could have used a couple times in the past. How can we "vote" on this? I'm not familiar with how to do that with IBM RFEs. Thanks, Ben -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Friday, May 03, 2013 3:06 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM RFE regarding Litigation Hold To all... I created an RFE to affect File Spaces and Expiration. The feature would cause expiration processing to be skipped for a file space that has been selected. It's RFE ID 33395 if you care to review and vote. Briefly, the idea is to immediately respond to a situation in which we cannot allow Expiration Processing to delete information that would otherwise be deleted. This would be in response to a "Litigation Hold" demand from a legal issue at hand. I've had three LitHold events in the past 24 months; they're not much fun and I'm not in the court room, just the TSM Server Admin. Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. When the court case is lifted, simply revert to ""LitigationHold=No". The next Expiration process would then begin the delete process as is normal. The feature would avoid the complexity of assigning a "no expire" management class to the node and trying to later revert to a more typical class. Please take a look at the RFE, and cast a vote if you feel it's a valuable feature. Thanks. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. *** -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Blue Cross of Idaho, 3000 E. Pine Ave, Meridian, ID 83642 -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Blue Cross of Idaho, 3000 E. Pine Ave, Meridian, ID 83642 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown.This email transmission may contain confidential information.This information is intended only for the use of the individual(s) or entity to wh
Re: TSM RFE regarding Litigation Hold
Got it. Voted. Thanks -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Reese, Michael A (Mike) CIV USARMY 93 SIG BDE (US) Sent: Tuesday, May 07, 2013 11:01 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold I agree this is a great RFE, and I have added my vote to it. Go to https://urldefense.proofpoint.com/v1/url?u=http://www.ibm.com/developerworks/rfe/?BRAND_ID%3D90&k=Kv4nkNfjdxVgeJz6Pg57qw%3D%3D%0A&r=I1HLMFJ6m%2BiVcavWgCBtVd78uShy4GoDLiStkJAJ6wk%3D%0A&m=x%2B6alTX5na7BL9zpHHo5bVZ89hIdgEmEAeC8GEPEa%2Bg%3D%0A&s=ae4c9e66642e3d122c6b1cff72603aa38cde0082ba1db6bf819f1f4a2336a5d2. You will need to sign in with your IBM ID to vote. Search by RFE ID to go to the desired RFE. Open the RFE and then click "Add vote" under RFE actions. From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of Ben Bullock [bbull...@bcidaho.com] Sent: Tuesday, May 07, 2013 10:59 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold That sounds like a great RFE, one I could have used a couple times in the past. How can we "vote" on this? I'm not familiar with how to do that with IBM RFEs. Thanks, Ben -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Friday, May 03, 2013 3:06 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM RFE regarding Litigation Hold To all... I created an RFE to affect File Spaces and Expiration. The feature would cause expiration processing to be skipped for a file space that has been selected. It's RFE ID 33395 if you care to review and vote. Briefly, the idea is to immediately respond to a situation in which we cannot allow Expiration Processing to delete information that would otherwise be deleted. This would be in response to a "Litigation Hold" demand from a legal issue at hand. I've had three LitHold events in the past 24 months; they're not much fun and I'm not in the court room, just the TSM Server Admin. Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. When the court case is lifted, simply revert to ""LitigationHold=No". The next Expiration process would then begin the delete process as is normal. The feature would avoid the complexity of assigning a "no expire" management class to the node and trying to later revert to a more typical class. Please take a look at the RFE, and cast a vote if you feel it's a valuable feature. Thanks. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. *** -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Blue Cross of Idaho, 3000 E. Pine Ave, Meridian, ID 83642 -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Blue Cross of Idaho, 3000 E. Pine Ave, Meridian, ID 83642
Re: TSM RFE regarding Litigation Hold
I agree this is a great RFE, and I have added my vote to it. Go to http://www.ibm.com/developerworks/rfe/?BRAND_ID=90. You will need to sign in with your IBM ID to vote. Search by RFE ID to go to the desired RFE. Open the RFE and then click "Add vote" under RFE actions. From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] on behalf of Ben Bullock [bbull...@bcidaho.com] Sent: Tuesday, May 07, 2013 10:59 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold That sounds like a great RFE, one I could have used a couple times in the past. How can we "vote" on this? I'm not familiar with how to do that with IBM RFEs. Thanks, Ben -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Friday, May 03, 2013 3:06 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM RFE regarding Litigation Hold To all... I created an RFE to affect File Spaces and Expiration. The feature would cause expiration processing to be skipped for a file space that has been selected. It's RFE ID 33395 if you care to review and vote. Briefly, the idea is to immediately respond to a situation in which we cannot allow Expiration Processing to delete information that would otherwise be deleted. This would be in response to a "Litigation Hold" demand from a legal issue at hand. I've had three LitHold events in the past 24 months; they're not much fun and I'm not in the court room, just the TSM Server Admin. Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. When the court case is lifted, simply revert to ""LitigationHold=No". The next Expiration process would then begin the delete process as is normal. The feature would avoid the complexity of assigning a "no expire" management class to the node and trying to later revert to a more typical class. Please take a look at the RFE, and cast a vote if you feel it's a valuable feature. Thanks. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. *** -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Blue Cross of Idaho, 3000 E. Pine Ave, Meridian, ID 83642
Re: TSM RFE regarding Litigation Hold
I'd also like to vote this up. We're a research organization so we don't have litigation per se, but there are times when we need to freeze expiration for other reasons. -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine On 05/07/13 07:59, Ben Bullock wrote: > That sounds like a great RFE, one I could have used a couple times in the > past. > > How can we "vote" on this? I'm not familiar with how to do that with IBM RFEs. > > Thanks, > Ben > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Vandeventer, Harold [BS] > Sent: Friday, May 03, 2013 3:06 PM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] TSM RFE regarding Litigation Hold > > To all... > I created an RFE to affect File Spaces and Expiration. The feature would > cause expiration processing to be skipped for a file space that has been > selected. > > It's RFE ID 33395 if you care to review and vote. > > Briefly, the idea is to immediately respond to a situation in which we cannot > allow Expiration Processing to delete information that would otherwise be > deleted. This would be in response to a "Litigation Hold" demand from a > legal issue at hand. I've had three LitHold events in the past 24 months; > they're not much fun and I'm not in the court room, just the TSM Server Admin. > > Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. > > When the court case is lifted, simply revert to ""LitigationHold=No". The > next Expiration process would then begin the delete process as is normal. > > The feature would avoid the complexity of assigning a "no expire" management > class to the node and trying to later revert to a more typical class. > > Please take a look at the RFE, and cast a vote if you feel it's a valuable > feature. > > Thanks. > > Harold Vandeventer > Systems Programmer > State of Kansas - Office of Information Technology Services STE 751-S > 910 SW Jackson > (785) 296-0631 > > > [Confidentiality notice:] > *** > This e-mail message, including attachments, if any, is intended for the > person or entity to which it is addressed and may contain confidential or > privileged information. Any unauthorized review, use, or disclosure is > prohibited. If you are not the intended recipient, please contact the sender > and destroy the original message, including all copies, Thank you. > *** > > -- > NOTICE: This email message is for the sole use of the intended recipient(s) > and may contain confidential and privileged information. Any unauthorized > review, use, disclosure or distribution is prohibited. If you are not the > intended recipient, please contact the sender by reply email and destroy all > copies of the original message. > Blue Cross of Idaho, 3000 E. Pine Ave, Meridian, ID 83642 >
Re: TSM RFE regarding Litigation Hold
That sounds like a great RFE, one I could have used a couple times in the past. How can we "vote" on this? I'm not familiar with how to do that with IBM RFEs. Thanks, Ben -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Friday, May 03, 2013 3:06 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM RFE regarding Litigation Hold To all... I created an RFE to affect File Spaces and Expiration. The feature would cause expiration processing to be skipped for a file space that has been selected. It's RFE ID 33395 if you care to review and vote. Briefly, the idea is to immediately respond to a situation in which we cannot allow Expiration Processing to delete information that would otherwise be deleted. This would be in response to a "Litigation Hold" demand from a legal issue at hand. I've had three LitHold events in the past 24 months; they're not much fun and I'm not in the court room, just the TSM Server Admin. Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. When the court case is lifted, simply revert to ""LitigationHold=No". The next Expiration process would then begin the delete process as is normal. The feature would avoid the complexity of assigning a "no expire" management class to the node and trying to later revert to a more typical class. Please take a look at the RFE, and cast a vote if you feel it's a valuable feature. Thanks. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. *** -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Blue Cross of Idaho, 3000 E. Pine Ave, Meridian, ID 83642
TSM RFE regarding Litigation Hold
To all... I created an RFE to affect File Spaces and Expiration. The feature would cause expiration processing to be skipped for a file space that has been selected. It's RFE ID 33395 if you care to review and vote. Briefly, the idea is to immediately respond to a situation in which we cannot allow Expiration Processing to delete information that would otherwise be deleted. This would be in response to a "Litigation Hold" demand from a legal issue at hand. I've had three LitHold events in the past 24 months; they're not much fun and I'm not in the court room, just the TSM Server Admin. Allowing a "LitigationHold=Yes" would avoid expiration on the File Space. When the court case is lifted, simply revert to ""LitigationHold=No". The next Expiration process would then begin the delete process as is normal. The feature would avoid the complexity of assigning a "no expire" management class to the node and trying to later revert to a more typical class. Please take a look at the RFE, and cast a vote if you feel it's a valuable feature. Thanks. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***
Re: Litigation Issue
We just went through this. I immediately exported the node to tape. That way nothing would affect what's on the tape. Also changed the MC values to never expire. On Mar 26, 2013 5:05 PM, "Vandeventer, Harold [BS]" < harold.vandeven...@ks.gov> wrote: > I've just learned about a "keep everything" issue for 5 of our nodes > related to a pending litigation. > > All are Windows servers, running TSM client 6.x, server is TSM 5.5.x. > > Default mgmt class is to retain 3 versions, deleted for 30 days. > > I'm looking for advice on how to quickly/easily keep all the files > including historical versions. > > My read of GENERATE BACKUPSET refers to "active data"; that would put only > current files into the backup set but NOT include versions. Correct? > > Applying an option set with a filter for "* no_expire_mgmt_class" might > work. > Does that modify the expiration date of historical versions of a file or > just the current version? > Does that modify the expiration date for the "deleted" files that are > going to expire out within the 30 day period? > > I also have a 6.2.4 TSM server in the environment. Perhaps an export node > to that 6.2.4 server and get files into a Stg Pool where we don't process > expiration? > > Any suggestions? > > Thanks in advance to all > > > Harold Vandeventer > Systems Programmer > State of Kansas - Office of Information Technology Services > STE 751-S > 910 SW Jackson > (785) 296-0631 > > > [Confidentiality notice:] > *** > This e-mail message, including attachments, if any, is intended for the > person or entity to which it is addressed and may contain confidential > or privileged information. Any unauthorized review, use, or disclosure > is prohibited. If you are not the intended recipient, please contact > the sender and destroy the original message, including all copies, > Thank you. > *** >
Re: Litigation Issue
export node fileda=all On 26 mrt. 2013, at 22:04, "Vandeventer, Harold [BS]" wrote: > I've just learned about a "keep everything" issue for 5 of our nodes related > to a pending litigation. > > All are Windows servers, running TSM client 6.x, server is TSM 5.5.x. > > Default mgmt class is to retain 3 versions, deleted for 30 days. > > I'm looking for advice on how to quickly/easily keep all the files including > historical versions. > > My read of GENERATE BACKUPSET refers to "active data"; that would put only > current files into the backup set but NOT include versions. Correct? > > Applying an option set with a filter for "* no_expire_mgmt_class" might work. > Does that modify the expiration date of historical versions of a file or just > the current version? > Does that modify the expiration date for the "deleted" files that are going > to expire out within the 30 day period? > > I also have a 6.2.4 TSM server in the environment. Perhaps an export node to > that 6.2.4 server and get files into a Stg Pool where we don't process > expiration? > > Any suggestions? > > Thanks in advance to all > > > Harold Vandeventer > Systems Programmer > State of Kansas - Office of Information Technology Services > STE 751-S > 910 SW Jackson > (785) 296-0631 > > > [Confidentiality notice:] > *** > This e-mail message, including attachments, if any, is intended for the > person or entity to which it is addressed and may contain confidential > or privileged information. Any unauthorized review, use, or disclosure > is prohibited. If you are not the intended recipient, please contact > the sender and destroy the original message, including all copies, > Thank you. > *** -- Met vriendelijke groeten/Kind regards, Remco Post r.p...@plcs.nl +31 6 24821622
Litigation Issue
I've just learned about a "keep everything" issue for 5 of our nodes related to a pending litigation. All are Windows servers, running TSM client 6.x, server is TSM 5.5.x. Default mgmt class is to retain 3 versions, deleted for 30 days. I'm looking for advice on how to quickly/easily keep all the files including historical versions. My read of GENERATE BACKUPSET refers to "active data"; that would put only current files into the backup set but NOT include versions. Correct? Applying an option set with a filter for "* no_expire_mgmt_class" might work. Does that modify the expiration date of historical versions of a file or just the current version? Does that modify the expiration date for the "deleted" files that are going to expire out within the 30 day period? I also have a 6.2.4 TSM server in the environment. Perhaps an export node to that 6.2.4 server and get files into a Stg Pool where we don't process expiration? Any suggestions? Thanks in advance to all Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***
Re: Litigation!
With 5.4 out, anyone find out if it includes help for "retention forever" while maintaining a separate storage pool for "two back?" Regards, Orin Orin Rehorst * e-mail: [EMAIL PROTECTED] ( Phone: (713)670-2443 7Fax: (713)670-2457 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Prather, Wanda Sent: Tuesday, November 21, 2006 10:50 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Litigation! 5.4 is due out sometime 1st quarter, although still subject to change in the presentation I saw. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Hughes Sent: Tuesday, November 21, 2006 11:45 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Litigation! Hello, While were on the subject of Backup Sets, I read somewhere that Generation of Backup Sets to point in time along with other Backup Set enhancements may be coming in a future release 5.4. Has anyone heard anything about that? Also, Does anyone have any idea when 5.4 is due out? Regards, Prather, Wanda wrote: >My understanding is that coming in a future release of TSM (probably >5.4), we will be able to stack multiple backupsets on a tape, and >restore individual files more easily. > >That might be a possible solution for data that is very unlikely to ever >be needed, but has to be retained. At least it won't cause massive DB >growth. > > > >-Original Message- >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of >Robin Sharpe >Sent: Monday, November 20, 2006 2:33 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: Litigation! > >Interesting approach Paul. (i.e. Why didn't I think of that?) Will you >just do a weekly backup to the litigation server, or something like >that? >Perhaps I can move to a similar design... > >RS > > > > Paul Zarnowski > <[EMAIL PROTECTED] > > >To > Sent by: "ADSM: ADSM-L@VM.MARIST.EDU > Dist Stor >cc > Manager" > <[EMAIL PROTECTED] >Subject > .EDU> Re: Litigation! > > > 11/20/2006 01:31 > PM > > > Please respond to > "ADSM: Dist Stor > Manager" > <[EMAIL PROTECTED] > .EDU> > > > > > > >Robin, > >This is exactly why we are looking to segregate the litigation data >on a separate TSM server. We do anticipate that the database will >grow large due to lack of expiring data. This is the primary reason >we want to keep this data separate from our production TSM >servers. And yes, we will also have the requirement to continue >backing up forward in time and not expiring any of the backup >data. Keeping the data segregated leaves our options open more, too. > >Thanks for the comments. They're helpful. > >..Paul > >At 11:25 AM 11/20/2006, Robin Sharpe wrote: > > >>Hey guys, >> >>I've been watching this thread for a few days now... >> >>We have been down this road. Still on it actually. The thing is, how >>diligent does your legal department want to be? Is a point in time >> >> >export > > >>enough? In our case, we were directed to not only keep all backups >> >> >that > > >>had been taken, but also to keep everything going forward. Reason >> >> >being, > > >>there may be further discussions/data pertaining to the subject of >>litigation. As a result, we have not done an expiration in 2.5 years, >> >> >and > > >>I have created new policy sets with unlimited retention for all >> >> >parameters. > > >>As you might imagine, this has resulted in incredible tape consumption, >>since we cannot reclaim much (nothing from primary pools, and only the >>fractional part of secondaries that were sent offsite). We use new >> >> >LTO2 > > >>tapes at a rate of about 100 per week. Also, our StorageTek L700 >> >> >library > > >>has long since overflowed... it has 618 slots; we have well over 3500 >> >> >tapes > > >>onsite (plus another 3500+ offsite). This has of course changed our >> >> >nice > > >>automated environment into a much more manually intensive operation. >> >> >Oh > > >>yeah, and our original TSM database grew to 529+GB, so I had to split >> >> >it > > >>into four new ones... >> >>This is a problem that will not go away... we have had several oth
Re: Litigation! Wish
Now, that's cool -- getting competitive advantage from a product like TSM! I wonder if the API could be used to provide the much-sought-after "restore preview" function? My guess is no... I think I read somewhere that the API cannot access data backed up by the regular BA client. RS Steven Harris <[EMAIL PROTECTED] IS.INFO> To Sent by: "ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager" <[EMAIL PROTECTED] Subject .EDU> Re: Litigation! Wish 12/26/2006 11:58 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] .EDU> Speaking of needles in haystacks, a one time colleague of mine was working for a company that analyzed oil seismic survey data on a large array of IBM clustered machines. He was a very smart cookie and understood the geophysics of it all (Hi Stephen if you are listening) The data came in on reels of tape and represented survey data from a surveyed line. A full survey consisted of a series of evenly spaced lines that mapped an area. He took this data and using the TSM API somehow stored it on 3590s (this was back in the old ADSM 3 days). The smart part was that oil companies could ask for an analysis of an area and give the coordinates that they wanted. His software would figure out which bits of data he needed from TSM mount the appropriate tapes and gather the data then feed it into the machines for analysis. This enabled his company to effectively leverage their investment in surveys and also provide the data faster to customers than anyone else could. At least that's what he told me :) The TSM API could be used to do a whole stack of this sort of storage work, but it is hampered by the lack of an API in something we can use, eg perl, python, or my current favourite ruby. I've taken a brief look at writing a library interface to ruby, but it is somewhat difficult - especially for an old COBOL programmer like me - why does everyone have to write in C anyway! Has anyone on the list done any work along these lines? Regards Steve Steven Harris AIX and TSM Admin Brisbane Australia
Re: Litigation! Wish
Speaking of needles in haystacks, a one time colleague of mine was working for a company that analyzed oil seismic survey data on a large array of IBM clustered machines. He was a very smart cookie and understood the geophysics of it all (Hi Stephen if you are listening) The data came in on reels of tape and represented survey data from a surveyed line. A full survey consisted of a series of evenly spaced lines that mapped an area. He took this data and using the TSM API somehow stored it on 3590s (this was back in the old ADSM 3 days). The smart part was that oil companies could ask for an analysis of an area and give the coordinates that they wanted. His software would figure out which bits of data he needed from TSM mount the appropriate tapes and gather the data then feed it into the machines for analysis. This enabled his company to effectively leverage their investment in surveys and also provide the data faster to customers than anyone else could. At least that's what he told me :) The TSM API could be used to do a whole stack of this sort of storage work, but it is hampered by the lack of an API in something we can use, eg perl, python, or my current favourite ruby. I've taken a brief look at writing a library interface to ruby, but it is somewhat difficult - especially for an old COBOL programmer like me - why does everyone have to write in C anyway! Has anyone on the list done any work along these lines? Regards Steve Steven Harris AIX and TSM Admin Brisbane Australia Robin Sharpe wrote: Well, what I meant was "move data" or "move nodedata"... but now that I think about it, those commands will have no effect on retention. They will only move the data to different volumes, maybe in different storage pools. A "generate backupset" would make a copy that has it's own retention criteria, but IMO backupsets are too hard to manage effectively... but then I haven't really used them that much. Also, backupsets will only contain active data, and so may be incomplete in a litigation context. I think the bottom line here, unfortunately, is that we're trying to make TSM fulfill a need it was not designed for. TSM is great for backing up a system and getting it back to a known operational state. It's also great for restoring a single file, set of files, directories, filesystems, etc. It's not too useful for finding a "needle in a haystack", like "we need all emails from John Doe to XYZ Corp regarding product X"... there are archiving systems emerging that can do that kind of function. It would be nice if TSM could serve as the back end for such a system so you can minimize the back-end data store. I believe there are a couple that can do that. Of course, there's no free lunch... implementing an archive solution like that will cost significant bucks. -Robin
Re: Litigation! Wish
Well, what I meant was "move data" or "move nodedata"... but now that I think about it, those commands will have no effect on retention. They will only move the data to different volumes, maybe in different storage pools. A "generate backupset" would make a copy that has it's own retention criteria, but IMO backupsets are too hard to manage effectively... but then I haven't really used them that much. Also, backupsets will only contain active data, and so may be incomplete in a litigation context. I think the bottom line here, unfortunately, is that we're trying to make TSM fulfill a need it was not designed for. TSM is great for backing up a system and getting it back to a known operational state. It's also great for restoring a single file, set of files, directories, filesystems, etc. It's not too useful for finding a "needle in a haystack", like "we need all emails from John Doe to XYZ Corp regarding product X"... there are archiving systems emerging that can do that kind of function. It would be nice if TSM could serve as the back end for such a system so you can minimize the back-end data store. I believe there are a couple that can do that. Of course, there's no free lunch... implementing an archive solution like that will cost significant bucks. -Robin Orin Rehorst <[EMAIL PROTECTED] > To Sent by: "ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager" <[EMAIL PROTECTED] Subject .EDU> Re: Litigation! Wish 12/25/2006 11:40 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] .EDU> Thank you, Robin, for the confirmation of my suspicion. I understand "special" (second) backups with different parameters. Can you give me an example of "or data movements within the server?" TIA Orin Rehorst -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Robin Sharpe Sent: Thursday, December 21, 2006 8:55 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Litigation! Wish Yes, this is a major shortcoming of TSM, especially in today's litigious business climate: the fact that data retention in TSM is tied to Management Class/Copy Group, and is the same throughout the storage hierarchy and across storage pool backups. The only way around it is to perform additional "special" backups and/or data movement within the server. Robin Sharpe Berlex Labs Orin Rehorst <[EMAIL PROTECTED] > To Sent by: "ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager" <[EMAIL PROTECTED] Subject .EDU> Litigation! Wish 12/20/2006 09:57 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] .EDU> Added VTL to increase capacity. Dream wish: set Version Data Exists to 20 for vtlpool and to 2 for copypool. No way to accomplish that (there isn't a Santa, after all)? TIA Orin Rehorst
Re: Litigation! Wish
Thank you, Robin, for the confirmation of my suspicion. I understand "special" (second) backups with different parameters. Can you give me an example of "or data movements within the server?" TIA Orin Rehorst -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Robin Sharpe Sent: Thursday, December 21, 2006 8:55 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Litigation! Wish Yes, this is a major shortcoming of TSM, especially in today's litigious business climate: the fact that data retention in TSM is tied to Management Class/Copy Group, and is the same throughout the storage hierarchy and across storage pool backups. The only way around it is to perform additional "special" backups and/or data movement within the server. Robin Sharpe Berlex Labs Orin Rehorst <[EMAIL PROTECTED] > To Sent by: "ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager" <[EMAIL PROTECTED] Subject .EDU> Litigation! Wish 12/20/2006 09:57 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] .EDU> Added VTL to increase capacity. Dream wish: set Version Data Exists to 20 for vtlpool and to 2 for copypool. No way to accomplish that (there isn't a Santa, after all)? TIA Orin Rehorst
Re: Litigation! Wish
Yes, this is a major shortcoming of TSM, especially in today's litigious business climate: the fact that data retention in TSM is tied to Management Class/Copy Group, and is the same throughout the storage hierarchy and across storage pool backups. The only way around it is to perform additional "special" backups and/or data movement within the server. Robin Sharpe Berlex Labs Orin Rehorst <[EMAIL PROTECTED] > To Sent by: "ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager" <[EMAIL PROTECTED] Subject .EDU> Litigation! Wish 12/20/2006 09:57 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] .EDU> Added VTL to increase capacity. Dream wish: set Version Data Exists to 20 for vtlpool and to 2 for copypool. No way to accomplish that (there isn't a Santa, after all)? TIA Orin Rehorst
Litigation! Wish
Added VTL to increase capacity. Dream wish: set Version Data Exists to 20 for vtlpool and to 2 for copypool. No way to accomplish that (there isn't a Santa, after all)? TIA Orin Rehorst
Re: Litigation!
GENERATE BACKUPSET and save it. Write it to a tape, CDs, DVDs, or something. At least this way, it can be restored without the server. This is exactly the kind of situation the Backup Set feature was invented for. Good instructions on how to do it in the TSM Administrator's Guide. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Orin Rehorst Sent: Thursday, November 16, 2006 9:05 AM To: ADSM-L@VM.MARIST.EDU Subject: Litigation! Yipes, we have pending litigation and an "E-discovery." I've been told to "freeze" our TDP for Exchange backups. How do you do dat? The backups roll off. (Just keeping one backup may be good enough.) Regards, Orin Orin Rehorst
Re: Litigation!
They don't "just roll off", it's based on your management class/copy group settings. Change them. And if you really want to have a "frozen" copy of the data, do an EXPORT to tape of the filespace. That way, if needed, you can recreate the situation exactly as it is today, at some future point in time. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Orin Rehorst Sent: Thursday, November 16, 2006 9:05 AM To: ADSM-L@VM.MARIST.EDU Subject: Litigation! Yipes, we have pending litigation and an "E-discovery." I've been told to "freeze" our TDP for Exchange backups. How do you do dat? The backups roll off. (Just keeping one backup may be good enough.) Regards, Orin Orin Rehorst
Re: Litigation!
Orin, Del, I think you could accomplish this by exporting the backups for the node to a separate TSM server. The domain you export it into could have policy settings to effectively never expire anything, even the inactive copies that already exist. You can do this by having the default management class have no limit on versions and an infinite retention, and also make sure that the grace periods in the domain are set as high as possible. We are not currently doing this, but are thinking about implementing something along these lines. ..Paul At 11:43 AM 11/16/2006, Del Hoobler wrote: Orin, You can't freeze just "one" particular backup. Short term, you can solve this by creating a new NODENAME for your future Data Protection for Exchange backups. This will keep all of your current active backups "frozen". In the future, you should look into using Data Protection for Exchange COPY type backups, and bind the "COPY" backups to a different management class that solves your longer term "archival" needs. Thanks, Del "ADSM: Dist Stor Manager" wrote on 11/16/2006 09:04:51 AM: > Yipes, we have pending litigation and an "E-discovery." > > I've been told to "freeze" our TDP for Exchange backups. How do you do > dat? The backups roll off. (Just keeping one backup may be good enough.) > > Regards, > Orin > > Orin Rehorst -- Paul ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: [EMAIL PROTECTED]
Re: Litigation!
Orin, You can't freeze just "one" particular backup. Short term, you can solve this by creating a new NODENAME for your future Data Protection for Exchange backups. This will keep all of your current active backups "frozen". In the future, you should look into using Data Protection for Exchange COPY type backups, and bind the "COPY" backups to a different management class that solves your longer term "archival" needs. Thanks, Del "ADSM: Dist Stor Manager" wrote on 11/16/2006 09:04:51 AM: > Yipes, we have pending litigation and an "E-discovery." > > I've been told to "freeze" our TDP for Exchange backups. How do you do > dat? The backups roll off. (Just keeping one backup may be good enough.) > > Regards, > Orin > > Orin Rehorst
Re: [SPAM: 4.000] [ADSM-L] Litigation!
Orin There are a number of different ways of achieving this and the best method will probably depend on your environment. It may be that a combination of methods may suit for you. You can generate a backupset of the active data using the command 'generate backupset'. For further info, do 'help generate backupset' or take a look at the server reference manual. The main benefit is that it is stored and managed as a single object. You may wish to use this method to get a 'snapshot' of the baclient data for the exchange server. It saves on objects in the DB. Backupsets don't work for TDP data, therefore I would create a new node. Give it a recognisable name, something like Exchsvr_Litigation_15Nov06 Change the TDP nodename in the dsm.opt file to this temp nodename and perform a manual backup of the exchange db. This does assume that you have a window big enough in the evening to run a manual before the scheduled or that you can run a manual full during the day. Providing that you do not backup to this node again, the backup will always be active and never expire. If you are really concerned about expiration, set the retention values that you associate to the new node to no limit. You may also want to take the precaution of marking the tape(s) that the data is written to as read-only and also setting the read-only switch physically on the tapes. Leigh -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Orin Rehorst Sent: 16 November 2006 14:05 To: ADSM-L@VM.MARIST.EDU Subject: [SPAM: 4.000] [ADSM-L] Litigation! Yipes, we have pending litigation and an "E-discovery." I've been told to "freeze" our TDP for Exchange backups. How do you do dat? The backups roll off. (Just keeping one backup may be good enough.) Regards, Orin Orin Rehorst
Litigation!
Yipes, we have pending litigation and an "E-discovery." I've been told to "freeze" our TDP for Exchange backups. How do you do dat? The backups roll off. (Just keeping one backup may be good enough.) Regards, Orin Orin Rehorst
