ADSM-L

Re: [ADSM-L] TSM RFE regarding Litigation Hold

2013-05-08 13:48:09
Subject: Re: [ADSM-L] TSM RFE regarding Litigation Hold
From: Paul Zarnowski <psz1 AT CORNELL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 8 May 2013 13:44:42 -0400
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 AT VM.MARIST DOT EDU] On Behalf 
>Of Prather, Wanda
>Sent: Wednesday, May 08, 2013 10:34 AM
>To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf 
>Of Vandeventer, Harold [BS]
>Sent: Tuesday, May 07, 2013 3:36 PM
>To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT EDU] On Behalf 
>Of Paul Zarnowski
>Sent: Tuesday, May 07, 2013 12:54 PM
>To: ADSM-L AT VM.MARIST DOT 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: psz1 AT cornell DOT edu
>719 Rhodes Hall, Ithaca, NY 14853-3801


--
Paul Zarnowski                            Ph: 607-255-4757
Manager of Storage Services               Fx: 607-255-8521
IT at Cornell / Infrastructure            Em: psz1 AT cornell DOT edu
719 Rhodes Hall, Ithaca, NY 14853-3801

<Prev in Thread] Current Thread [Next in Thread>