We have a smaller but similar IMAP situation (about 3M files and 60G in
use, with exactly double those amounts stored in *SM).  I'll comment..

1. If restore of files changed in past "n" days is required to shorten
(initial) major restore times, why not just do this at restore time with
standard DSMC restore parms?

2. One could have a separate process that could duplicate portions of
the mailstore, with *SM backing up only those duplicates.  For example,
before backups, one might tar/zip/whatever each mailbox to a single file
(per mailbox). You'd probably be backing up more data (static would be
in with new data for each mailbox changed), but *SM DB would be
substantially smaller. For example, before backups, one might copy "new"
files to a separate folder and backup only the separate folder. (Yuk to
both!).

3. If backups slow because of the "large" number of DB entries, separate
the mailstore and use *SM's virtualmountpoint facility. Cyrus, if that's
your IMAP program let's you do this quite easily.

4. Look at your *SM retention policy to make sure it matches your need.
You might be surprised to learn how much of your *SM DB is used due to
inactive objects (for my "relatively low" values of retention, 50% of my
IMAP objects are inactive; if you keep discarded stuff for a month or
more, inactives may dominate your *SM DB!).

5. Consider that among all those LLBean ads stored on your mailstore are
mail items critical to your organizations long term and efficient
operation.  Maybe it's efficient to have someone ask mailbox owners why
they have a gigabyte of mail stored yet haven't connected in past 3
months?  Maybe it's efficient just to size your backup and IMAP
resources to match the need? (any of the copy options of point #2 above
have additional costs wrt complexity of operation, reliability of
restore, etc.).  Does your organization consider *SM resources to be
part of the cost of IMAP operations?  Maybe it should.

Hope this helps, wayne

Luke Dahl wrote:

Hi All,
    TSM Server - 4.2.1.15, Solaris 9
    TSM Client - 4.2.1.0, Solaris 9

We are backing up an IMAP mail server which creates a new file for every
new mail message received.  The large number of files (new messages)
created is increasing our database size at an alarming rate.  We'd like
to specify a management class that will retain only the last 32 days
worth of NEW messages.  It's my understanding that the Retain Only
Version parameter applies only to inactive files.  Files (messages) are
never deleted from the server (our users basically store their mail on
the server indefinitely) so they never become marked inactive.  So, I'm
wondering if I can somehow specify to only backup the most recent 32
days worth of new files?  I do not want to include all of the files that
reside on the server and I have no way of separating the most recent
files into a separate area.  Basically, if we lose our mail server we
want a method of quickly restoring only the last month's worth of new
mail messages.  The size of the mail server (~400Gb) limits our ability
to provide a restore of all the files in a reasonable amount of time and
is burning up our database capacity.  Anyone else backing up IMAP mail
servers or facing similar issues?  Any thoughts or suggestions are much
appreciated!

Luke Dahl
NASA - Jet Propulsion Laboratory
818-354-7117

--

Wayne T. Smith -- ADSM AT Maine DOT edu -- University of Maine System -- UNET