I have worked with Tivoli Storage Manager (TSM) for many years, way back when it would run on an AS400 using PASE. Even after all these years, retention is a HUGE part of TSM. TSM retention can be somewhat confusing whether you are a seasoned TSM admin or a customer just trying to understand what the TSM admin is telling you about retention.

It’s important to understand the different retentions and how they affect capacity and resource utilization (including the TSM DB2 database). Many customers find themselves “over protected”.  This ties directly into retention and capacity, and can leave lots of money on the table. The trick is to strike a balance between protecting data and managing costs.

Example of Over-protecting Data

As an example of over-protecting data, a previous customer of mine was running full Exchange backups daily and keeping them for 7 years…wondering why the capacity kept growing so astronomically…and “why don’t we ever have any scratch tapes?” Their environment was at capacity. We modified the backup schedule to run weekly full backups, and incremental backups twice daily. Then, we discussed retention options in detail with the customer using “what if” scenarios, and the retention was changed from 7 years to 60 days. The customer reclaimed terabytes of storage, decreasing their capacity dramatically.

On the flip side, there are some customers with TSM admin access, who could be making changes that are causing more harm than good. They make modifications to retention without understanding the ramifications. They are extremely happy that they now have all this storage available, and then call you in panic mode because they are unable to restore something they thought would not be affected by the change they made.

Every Environment is Different

Just when you think you’ve seen it all, you haven’t. Would you ever keep 90 versions of the SYSTEMSTATE backup?  I’ve seen it, and TSM did not like it. Too many versions of an object has been known to cause confusion in the TSM DB2 database, affecting the truncation of the activity log, not to mention adding to the capacity. Many TSM customers use capacity based licensing, so before just increasing the license, it would be worth the effort to review current TSM retention vs. company requirements for backup/recovery.

I would almost bet there isn’t a single TSM admin out there who doesn’t get at least a tiny bit apprehensive when making changes to retention. After all, it’s only data, right??