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]" <harold.vandeven...@ks.gov> > 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" <ADSM-L@VM.MARIST.EDU> > > > > 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 Ph: 607-255-4757 > Manager of Storage Services Fx: 607-255-8521 > IT at Cornell / Infrastructure Em: 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. >
