Yep, I tested it over a weeks time, archiving data and changing the retention
period, it worked as designed. This can actually be found in TSM
documentation, the doc is not real clear about doing this, but if you break it
down you can see it, the part about the default(If you later change or replace
the default management class, the server uses the updated default management
class to manage the archive copy)...here is the doc that is from the TSM
publications, the Server Guide.
Archive Copies
Archive copies are never rebound because each archive operation creates a
different archive copy. Archive copies remain bound to the management class
name specified when the user archived them.
If the management class to which an archive copy is bound no longer exists or
no longer contains an archive copy group, the server uses the default
management class. If you later change or replace the default management class,
the server uses the updated default management class to manage the archive
copy.
If the default management class does not contain an archive copy group, the
server uses the archive retention grace period specified for the policy domain.
-----Original Message-----
From: Cook, Dwight E [mailto:DWIGHT.E.COOK AT SAIC DOT COM]
Sent: Wednesday, January 22, 2003 12:25 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: extending archive retentions
Have you actually tested that ?
My understanding (from long ago) was that internally, archives are/were
stored with an ~expires on date~ or ~expires after so many days~. A
~security~ feature... once an archive was created, that was it, no changing
it... because if you could extend a retention period, you could also shorten
it. (but then again, an admin with sys auth would just delete the
filespace)
I might have to test that...
Dwight
-----Original Message-----
From: Miller, Ryan [mailto:Miller.Ryan AT PRINCIPAL DOT COM]
Sent: Wednesday, January 22, 2003 12:13 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: extending archive retentions
Actually, you can't assign a different management class to an already
performed archive, but you CAN alter the management class retention period
itself and effectively alter the retention period for all archives that used
that management class, so there in lies the possible problem. If other
archives have used this management class, they will also be retained for the
longer period. But if the number of archives that have used this management
class is low, this may be your best and easiest solution. I have done that
before to save myself considerable time and effort when things like this
need to be done. Once the 5 years is up, change the management class
retention time back and all will be normal again.
Ryan Miller
Principal Financial Group
Tivoli Certified Consultant
Tivoli Storage Manager v4.1
-----Original Message-----
From: Cook, Dwight E [mailto:DWIGHT.E.COOK AT SAIC DOT COM]
Sent: Wednesday, January 22, 2003 11:59 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: extending archive retentions
NO but YES, sort of...
NO, you can't alter the management class (and thus the retention period) of
archived files
BUT you could do something like export the node (or as little data as
possible but still including the data you need)
then you could save those export tapes for 5 years...
When you import a node, you can request that is use "relative" dates, so
archived data will still be available for the same number of remaining days
as when it was exported. (that was about as clear as mud...)
Dwight
-----Original Message-----
From: Glass, Peter [mailto:Peter.K.Glass AT WELLSFARGO DOT COM]
Sent: Wednesday, January 22, 2003 11:19 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: extending archive retentions
I have some clients who have archived files with 1-year retentions. Now they
say these files need to be retained for 5 years.
Is there a way we can extend these retentions without having to retrieve and
re-archive these files?
If so, how?
Thanks, in advance.
Peter Glass
Distributed Storage Management (DSM)
Wells Fargo Services Company
> * peter.k.glass AT wellsfargo DOT com
>
|
