Versions Not Expiring

mtatte

ADSM.ORG Member
Joined
May 20, 2003
Messages
50
Reaction score
0
Points
0
Website
Visit site
I recently changed the "Versions Data Exists" from 8 to 7 in a specific backup copy group. However, several days later, I'm still seeing 8 versions of the data on servers within this MC??!! Is this something to do with the "Retain Extra Versions" parameter (i.e. which one takes precedent?)



The other related retention settings within this copy group are as follows:-



Copy Group Name STANDARD

Versions Data Exists 7

Versions Data Deleted 1

Retain Extra Versions 30

Retain Only Version 30



SINCERE THANKS IN ADVANCE TO ANYONE WHO CAN HELP ME!!
 
When the copy group was updated, did we update the 'active' copy group or the

'inactive' copy group?

If the 'inactive' copy group was updated, did we issue 'activate policyset'?

This will push the update from the 'inactive' copy group to the 'active' copy group.

If this was all done. Did the expire inventory process run?





Version Data Delete works with Retain Extra Version.

Retain Extra Version is how long to keep the file.

If we are keeping 7 version of the file and the file changes every day.

On the 8th day the oldest version will expire, we would not reach the 30 retention limit.

Unless the file does not change very often then there is a possiblity that the 30 day

retention limit will be reach.



Retain Extra Version:

If we did a backup on Monday and another backup on Tuesday ( of course the file change before the next backup).

What was the active file on Monday is now an inactive file on Tuesday. If we do not

do any more backup. The inactive file will expire 30 days from the time it change from active to inactive.





Good Luck,

Sias :)
 
Not to sound presumptuous but

1) Are you running expire inventory?

2) Did you activate the policy in which that MC falls under?





Thanks,



Michael
 
Here is a overview of Copy Goups and how they work .



Remenber the copy group is bound by an Activated Policy Domain Set.



VERE=7 Copy 1 is Monday on Tuesday copy 1 becomes INACTIVE 1 until it counts up to

INACTIVE 7 once it hits that threshold number it is deleated (expired)

VERD=1 If there are 1 active and 3 inactive copies of the file the 1 active will be retained

until the RETE threshold and the RETO thresholds have been met.

RETE=30 If the VERE 7 1 active and 6 inactive copies thresholds have not been met within

a 30 day period all inactive copies will be deleated (expired)

RETO=30 Will retain a deleated or ONLY copy of 30 days after the RETE threshold has been

met.



If your copygroup is in a Activated Policy Domain Set and is not expiring inventory look at the Policy Set again by doing this command val po <domain_name> <policy_set_name> is will verify that the copy groups are going to expire inventory properly. Remember that you can have only an archive and backup copygroup per management class. If the default management class was not re-assighned before activating the policy set the changes to the copy group will not work.



This is the order to do this just TSM commands



1. upd co <domain_name> <policy_set_name> <management_class_name> STANDARD t=b/a (b=backup a=archive) vere=# verd=# rete=# reto=# copydest=<storagepool_name>



2. assign defmgmt <domain_name> <policy_set_name> <management_class_name>



3. val po <domain_name> <policy_set_name>



4. act po <domain_name> <policy_set_name>



I hope this helps you with your problem. If I can help you more let me know.
 
Your description of verdel is not accurate. If a file is active it will remain on tape indefinitely. It is not bound to the same rules as inactive files. Only inactive files will remain retained until retextra or retainonly depending on their status. VERD only applies to files that are deleted on the system. If you have VERD=2, then TSM will retain 2 versions of the deleted file. RETO will control how long it keeps that deleted file. It has nothing to do with the only or active copy. It is simply a misnomer. If this was the case, if you backed up a file that never changed and you set RETO to 30 then if you had a disaster on day 31 you would have nothing to restore.



Hope this helps,



Michael
 
Back
Top