Perhaps your problem results from what is BOUND to each management class. 90 days is a LONG time to keep backup versions, not surprised your DB grows.
Some things to be careful of: 1) By default, ALL directories are bound to the management class with the longest RETONLY value, even if the FILES belonging to those directories are bound to a different management class. Since you have a management class with a RETONLY value of UNLIMITED, that's where your directories will be bound by default. Unless you specify another mgmt class using DIRMC for the client, NO directories are getting deleted in your environment. Ever. A directory is backed up as a separate object in the TSM DB, and takes up just as much DB space as a file. 2) For your Windows clients, be very careful of where your SYSTEM OBJECT filespaces are bound. If you are keeping 90 days worth, that is at least 3000 files, PER CLIENT, PER BACKUP, for the Windows SYSTEM OBJECT filespaces. I recently worked with a customer having DB growth problems, and calculated they had 35 MILLION entries in the DB just associated with SYSTEM OBJECt/SYSTEM STATE filespaces, because they were keeping them for 90 days. Bind the SYSTEM OBJECT to something more reasonable; a management class that is retained for only 2 weeks, for example. (Ask your Windows admins if they would ever restore a registry that was 90 days old? I sure wouldn't!). Or bind the SYSTEM OBJECT to a management class that doesn't back up every day (backup frequency >1). 3) Also for Windows clients, MAKE SURE you are putting in reasonable EXCLUDES. Junk files that have unique names, but get deleted, will live for 90 days in your environment. Windows creates a LOT of files like that every day that you don't need, esp. in \Temporary Internet Files and \RECYCLE. Results in a lot of DB entries. You just don't need to back those up, period. Been there, felt that pain. Wanda Prather "I/O, I/O, It's all about I/O" -(me) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Levi, Ralph Sent: Wednesday, August 02, 2006 9:00 AM To: [email protected] Subject: Data expiration I am still working understanding why my TSM DB continues to grow and think I may have come upon something. I have many retention policies in the management class for all my file servers. The goal was to keep most data for only 90 days after it was deleted and to keep 90 versions if it was a file that would be updated daily. Incremental backups are run nightly. TSM is AIX 5.3 and TSM 4.2.7. The file servers are mostly W2K with backup-restore client 5.1.x - 5.3.x. My expiration runs successfully daily but I believe what is happening is the majority of data being expired are the files that are overwritten daily. It looks to me like the files that someone overwrites once or twice lives out in TSM forever, certainly beyond the 90 days I was expecting it to be there. Here are my management classes. Is the unlimited "retain extra versions" overriding my 90 days in the primary management class ? Any help would be appreciated. Thanks, Ralph The default management class is defined as: versions data exist: unlimited versions data deleted: 9 retain extra versions: 9 retain only version: 9 The primary management class used (95% of all data) versions data exist: unlimited versions data deleted: 90 retain extra versions: 90 retain only version: 90 The 2 long retention management classes are: versions data exist: unlimited versions data deleted: 366 retain extra versions: 366 retain only version: 366 versions data exist: unlimited versions data deleted: unlimited retain extra versions: unlimited retain only version: unlimited
