We've identified that our TSM 6.2.4 server is not binding files to the default management class but is assigning the node data to the management class with the highest retention setting, as if the default management class was not set. Attempts to update the policy's default management class, reactivate the policy, and rerun a backup have not yielded any rebinding on the TSM side. What does work is placing an INCLUDE * FSMGMT at the top of the include/exclude list. Pretty weird behavior and would explain why we seem to be eating through more storage than we should be. Anyone else seeing this? It might be an isolated incident, but we are checking all our TSM 6.2.x servers to verify. The best way to check is to identify the management class with the largest retention setting for backups and query a nodes backup in that domain to see if it is using it to bind the data.
SELECT * FROM BACKUPS WHERE NODE_NAME='<NAME HERE>' and CLASS_NAME='<MGMT NAME WITH HIGHEST RET IN DOMAIN>'
I have a PMR open with IBM and will post what I find.
Hey Chad, I believe I am having the same issue on my 6.3.2 server. Did you ever hear from IBM for a fix? I am eating up space like crazy!ReplyDelete