You're going to want to check the integrity of your database file using the eseutil /k command. Unfortunately, that means you'll need to dismount the store. Did your Exchange server crash sometime recently? Or was it just after the issue you were having with the disk in the shared storage that you started having problems? Since you got to take down the store to check the database integrity, you might want to go ahead and perform an offline backup, too. Check out KB Article 237767 (XADM: Understanding Offline and Snapshot Backups) for additional information on how to do so. Be sure to grab a copy of all log files between the last time you took a successful backup and now to be sure you can reply them against the offline backup, if necessary. So, if you're not able to take a backup, what's your log file free disk space looking like? My guess would be that it's filling up. Dismounting the store should commit any data in the log files to the database. You can confirm this by running the eseutil /mh command against your database file once you stop the store. The state should be listed as Clean Shutdown. 90GB database file in and of itself isn't necessarily problematic. It is, however, unwieldy. We're running off of a fibre SAN with fibre drives in our environment. Even so, backup and restore takes a long time. It's probably in your best interest to separate your users, if only to decrease the total size of a single database. While this may increase the complexity of your Exchange and disk configuration, it will help minimize the issues that can occur when you do have large stores. For backup, restore, and archival (I realize you're already using a solution but I figured I'd throw this out anyway since it addresses all functionality), take a look at the NearPoint solution from Mimosa Systems (www.mimosasystems.com). It uses a pretty slick architecture that enables pretty much near realtime restoration of Exchange data right down to the individual mail message level. It does this by copying your production database from your Exchange server to itself and then through log shipping (both periodic [you set the period between shipments] and dynamic [each time a log file is created, it's copied to the NearPoint server]), it replays those log files directly against its copy of your Exchange database. It also has a zero footprint on both your Exchange servers and clients (no agents). If you have more questions about any of this, feel free to ping me offlist. :) Cordially yours, Jerry G. Young II MCSE (4.0/W2K) Atlanta EES Implementation Team Lead HHS Engineering Unisys 11493 Sunset Hills Rd. Reston, VA 20190 Office: 703-579-2727 Cell: 703-625-1468 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: Thor (Hammer of God) [mailto:Thor@xxxxxxxxxxxxxxx] Sent: Monday, March 13, 2006 6:08 PM To: [ISAserver.org Discussion List] Subject: [isalist] RE: OT: Good source for Exchange Mailstore Management http://www.ISAserver.org Hi Gerald - thanks for the response (and to everyone else, as well.) Inline (easier) On Mar 13, 2006, at 12:39 PM, Young, Gerald G wrote: > http://www.ISAserver.org > > Thor, > > I help support an Exchange 2003 environment where we have about 16 > mailbox stores, each about 100GB in size. What specific kind of > mailbox > store management are you asking about? Archival, backup/restore, > policy > enforcement? My backup is now saying that my message store file is corrupt, but everything is working OK now from an access standpoint (see below for story) > > How many mailboxes make up that 90 GB? Are you on SCSI, ATA, SATA, or > SAN storage? How big are you looking to grow? Do you have any > compliance (FISMA, HIPAA, FDA, SEC) policies you need to follow with > regards to retention? About 65 mailboxes. My users are crazy "CYA" people, and keep every email they've ever gotten forever. I guess that's OK as long as mailbox size/backups don't become an issue. The disk subsystem is a PowerVault 220s with a RAID5 SCSI array. It's the shared storage for my current Dell 2650 cluster servers. I'm moving to the HP DL380 G4 Cluster Servers with the MSA500 G2 subsystem, but that won't be for a few weeks. From a hardware standpoint, I think we're good to go. No retention policy issues - even if there were, I've got GFI MailArchiver on a separate system logging all email to a SQL box. But I've had different people tell me different things about splitting up my mailstores, defragging them regularly, etc. Is 90 gig in itself problematic? We recently had a drive go bad in the array, and we had to rebuild it. However, there was an issue with the rebuild - during this time, I wanted to get a copy of my mailstore either on disk, or on tape. But it wouldn't copy (CRC) and it wouldn't back up. Seemed like some data errors on another drive kept the array from rebuilding. I was able to manually fix the drive with issues, and then the array rebuilt. I then rebuilt it again with a new drive instead of the "problem" drive. (Note one drive completely failed, and one had a data error.) Even after all of that, though everything seems to be working fine, the backup of the file still fails with a "corrupt file" error. I'm wondering now if I should break up my users into different mail- stores to make them more manageable, etc. Any advise? t