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
Policy Policy Mgmt Copy Versions Versions Retain Retain
Domain Set Name Class Group Data Data Extra Only
Name Name Name Exists Deleted Versions Version
--------- --------- --------- --------- -------- -------- -------- -------
PRESERVE ACTIVE STANDARD 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 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
|
