WOW ! thanks for pointing that out...
I went ahead and tested it on an AIX 4.3.3 TSM 4.2.2.0 server (with AIX tsm
client) and sure enough...
I archived a few files into a mgmtclass with 365 day retention
cut the retention down to 10 days for that management class
activated the policy
went back to the client & did my "q archive" again and they are ~reported~
to expire in just 10 days now...
then because I'm anal (and wanted to see if what was ~reported~ was to
be...), I set the host forward one month (more than 10 days but less than
365)
accepted the date in tsm & ran expire inventory... sure enough... the data
is NO MORE...
OK, now how many sleepless nights will I experience trying to figure out if
this is Good or Bad ?
Dwight
PS below I've included select output from my test...
tsm> q archive /home/zdec23/decout*
Size Archive Date - Time File - Expires on - Description
---- ------------------- -------------------------------
96 01/22/2003 13:50:00 /home/zdec23/decout 01/22/2004 365
days
54,673 01/22/2003 13:50:00 /home/zdec23/decout2 01/22/2004
365 days
21,684 01/22/2003 13:50:00 /home/zdec23/decout3 01/22/2004
365 days
tsm>
tsm: TSMSRV01>upd copy standard standard archtest retver=10 t=a
ANR1537I Archive copy group STANDARD updated in policy domain STANDARD, set
STANDARD, management class ARCHTEST.
tsm: TSMSRV01>q copy standard standard archtest t=a f=d
Policy Domain Name: STANDARD
Policy Set Name: STANDARD
Mgmt Class Name: ARCHTEST
Copy Group Name: STANDARD
Copy Group Type: Archive
Retain Version: 10
Copy Serialization: Shared Dynamic
Copy Frequency: CMD
Copy Mode: Absolute
Copy Destination: DISKPOOL1
Last Update by (administrator): ZDEC23
Last Update Date/Time: 01/22/2003 13:52:35
Managing profile:
tsm: TSMSRV01>
tsm: TSMSRV01>activate po standard standard
Do you wish to proceed? (Yes (Y)/No (N)) y
ANR1514I Policy set STANDARD activated in policy domain STANDARD.
tsm: TSMSRV01>q copy standard active archtest t=a f=d
Policy Domain Name: STANDARD
Policy Set Name: ACTIVE
Mgmt Class Name: ARCHTEST
Copy Group Name: STANDARD
Copy Group Type: Archive
Retain Version: 10
Copy Serialization: Shared Dynamic
Copy Frequency: CMD
Copy Mode: Absolute
Copy Destination: DISKPOOL1
Last Update by (administrator): ZDEC23
Last Update Date/Time: 01/22/2003 13:52:35
Managing profile:
tsm: TSMSRV01>
tsm> q archive /home/zdec23/decout*
Node Name: DWIGHT
Please enter your user id <DWIGHT>:
Please enter password for user id "DWIGHT":
Session established with server TSMSRV01: AIX-RS/6000
Server Version 4, Release 2, Level 2.0
Server date/time: 01/22/2003 13:54:15 Last access: 01/22/2003 13:51:26
Size Archive Date - Time File - Expires on - Description
---- ------------------- -------------------------------
96 01/22/2003 13:50:00 /home/zdec23/decout 02/01/2003 365
days
54,673 01/22/2003 13:50:00 /home/zdec23/decout2 02/01/2003
365 days
21,684 01/22/2003 13:50:00 /home/zdec23/decout3 02/01/2003
365 days
tsm>
tsm: TSMSRV01>show time
Current Date and Time on the Server
----------------------------------------
02/22/2003 14:09:01
UTC (GMT) Date/Time is: 02/22/03 20:09:01
Last Noted Date/Time is: 02/22/03 14:08:57
tsm: TSMSRV01>expire inv
ANS8003I Process number 62 started.
tsm: TSMSRV01>q pr
ANR0944E QUERY PROCESS: No active processes found.
ANS8001I Return code 11.
tsm: TSMSRV01>q occ dwight
ANR2034E QUERY OCCUPANCY: No match found using this criteria.
ANS8001I Return code 11.
tsm: TSMSRV01>accept date
ANR0893I Are you sure that you want to accept the current system date as
valid
?
Do you wish to proceed? (Yes (Y)/No (N)) y
ANR0894I Current system has been accepted as valid.
tsm: TSMSRV01>
tsm: TSMSRV01>show time
Current Date and Time on the Server
----------------------------------------
01/22/2003 14:09:31
UTC (GMT) Date/Time is: 01/22/03 20:09:31
Last Noted Date/Time is: 01/22/03 14:09:09
tsm: TSMSRV01>
Dwight E. Cook
Software Application Engineer III
Science Applications International Corporation
509 S. Boston Ave. Suite 220
Tulsa, Oklahoma 74103-4606
Office (918) 732-7109
-----Original Message-----
From: Miller, Ryan [mailto:Miller.Ryan AT PRINCIPAL DOT COM]
Sent: Wednesday, January 22, 2003 12:59 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: extending archive retentions
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
>
|
