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 -- [EMAIL PROTECTED] -- University of Maine System -- UNET
