Sampling Enterprise Retention Policies

[mpfrench]

I am looking to change my companie's retention policy which I think is currently too long. Right now we are using:



Versions Data Exists 8

Version Data Deleted 8

Retain Extra Versions 180

Retain Only Versions 365



I was looking to do something like:



Versions Data Exists 3

Version Data Deleted 1

Retain Extra Versions 30

Retain Only Versions 90



What are you doing and why? Thanks!



Michael French

 

[ccai]

how about trying this command:

upd copygroup domain_name policy_name mgmtclass verexist=3 verdel=1 retextra=30 retonly=90



if no errors are returned, the attributes of the copygroup are updated. good luck :grin:

 

[mpfrench]

Thanks for the comment, but I know how to update the copygroup, I just want to know what options others are doing. If you are keeping 15 deleted versions, why? If you are only keeping 1 deleted version, why? I am trying to get a feel for what a good retention policy would be based upon real world implementations. I feel like the one that I have now is way to long and unmanageable long term.



Michael French

 

[klebesco]

Hi,



I had to deal with this issue last Winter...



I didn't know about this forum at the time and tried to get what others were doing from TSM support and the few other TSM shops I knew about.



The true answer to this question varies by what you are trying to accomplish...



Back then I only had 2 policies which a predecessor set up and they were 6,6,180,180 and 30,30,180,180



If you are talking just strait DR you probably only need 3,1,7,7 or something like that.

If you're also trying to protect against inadvertant data deletion for some period of time you would inflate these values.



If you are wanting to salt thing away for extended period you should establish that period with management and use archive instead of backup.



An area that can cause you problems are emails especially VIP emails ...they only know that TSM costs them a bundle and they think the policy for their data should be 99999,99999,99999,99999 aka an instantly recoverable black hole.



You also may be subject to legislation for keeping records depending on what kind of endeavor you are backing up.



The short of this all is that I have arrived at the conclusion that I need about 7 distinct policies for backups and archives for email, office WP, DBbackups, DBlogfiles,etc,etc,etc



My longest archive is 3 years and my worst policy (best if you don't like getting yelled at!)

is 365,365,365,365 at the same time the bulk of my data is at 6,2,30,180.



I run expires every 48 hours and keep stats: the average (and I mean average) life of an object at this shop is 14 days.



Hope this helps!



Kurt :grin:

 

[mpfrench]

Thanks for the detailed response, just what I was looking for. One question though, how are you keeping track of the number of objects for each client and their average life span? Do you have a script performing this task or just a long select statement? Thanks!



Michael French