Expire inventory not behaving

StiffBoard

ADSM.ORG Senior Member
Joined
Mar 1, 2014
Messages
55
Reaction score
3
Points
0
Environment with 2 servers, running 8.1.5.100. Been having problem with tsm database and container pool growing, case with IBM about this, doing manual moves and stuff, I'm not involved with the case myself. But I've discovered files that have expired long ago, so this is also part of the problem with growth. Files are database backups and transcation log backups with a management class of their own. q occ on the server showed 11 TB occupancy in total, after I have cleaned from old files, delete from backup, I'm down to 6 TB. Not sure if this is a bigger problem here, only been checking on my .bak and .trn files and a few checks where I could see the right number of versions. Files left behind is mostly around the same dates. Any ideas on this? Any force expiration or similiar availble :S
 
We used to have Retain only version 30 on the mentioned extensions. Changed to 14 and now 10. The files that are left behind is much older. If I delete files from client and run an exp inv I can see that the files are removed by exp inv. So which process is doing the actual deletion on the files? How do I get Spectrum to run through the filesystem and doublecheck my mgmt classes towards whats in the database and container pools?
 
Have the files changed at all since they were backed up? If they are active files (still exist on the server being backed up) and haven't changed since they were backed up, they will not expire as they are still required.
 
Unique filenames, exist on server until next day database backup is done. So deleted long ago, SQL server backup very rarely fails and this is on just about all our db backup on this server.
 
So the files are only active for 24 hours, keeping each unique file for 10 days back at the moment, as this has taken all our disk capacity.
 
Back
Top