Is there a way to determine the retention time on a per client basis within TSM??

PENNYWISE

ADSM.ORG Member
Joined
Nov 15, 2005
Messages
27
Reaction score
0
Points
0
Website
Visit site
I need a way to produce a report showing the amount of data contained within TSM on a per server basis and when that data will expire. DOes anyone know of a way to do this?
Thanks for reading my post!
 
It will be a tough exercise because an object can expire off the TSM Server if the number of versions is exceeded or if the number of days is exceeded, whichever comes first. Also if the object is deleted on the client or not, which you cannot easily tell from the backups table.

You can look at the BACKUPS table.
select * from backups where state='INACTIVE_VERSION'

By server, I imagine you mean client/node. In that case, you can order by nodename:
select * from backups where state='INACTIVE_VERSION' order by node_name

Or select a particular node:
select * from backups where state='INACTIVE_VERSION' where node_name='NODENAME'

The deactivation date is the date the object went inactive. Look at the retention of the CLASS_NAME to see when it may actually expire.
 
Thanks for the reply. I will try the queries you suggested. The problem I'm seeing is it seems I have many clients that have been retired (not backing up any longer) and yet I still see data when I run query occ commands (as if the data is not expiring even though expiration processing runs every day)??
 
Keep in mind that active versions never expire.

For those nodes try:
select state,count(*) from backups where node_name='NODENAME' group by state

If the active_version count > 0 and the inactive_version = 0, then the data you see in Q OCC is the active versions.

The only way to get rid of the active versions is deleting the filespaces before deleting the nodes.
 
I see stats for both:

STATE Unnamed[2]
------------------ -----------
ACTIVE_VERSION 11254
INACTIVE_VERSION 53

The node I picked hasn't been around for over two years. Why would there still be inactive versions? Wouldn't they have expired by now?
 
Primary reason for objects not expired yet is that the retention is longer than the time elapsed since deactivated.

Use this to get the list of those 53:
select * from backups where state='INACTIVE_VERSION' where node_name='NODENAME'

Then check the retention of the class.
 
OK, that makes sense. And the reason for the number of active versions is because TSM holds on to them forever until the filespace (and then the node) is deleted even though backups haven't run on this server for years?
 
The "select * from backups where state='INACTIVE_VERSION' where node_name='NODENAME'" query gives an error "ANR2904E Unexpected SQL key word token - 'WHERE'". It doesn't like the second where.
 
Try this:
select * from backups where state='INACTIVE_VERSION' and node_name='NODENAME'
 
Back
Top