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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Levi, Ralph
Sent: Wednesday, August 02, 2006 9:00 AM
To: ADSM-L AT VM.MARIST DOT EDU
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
|
