Repair corrupt mailbox database

Question

I have a standalone Exchange 2010 server (virtual server in vmware) with a corrupt mailbox database.  The server (VMDK file) resides in a vmware HA cluster fiber connected to a SAN.  The SAN experienced a hard drive failure (RAID 5 volume which
contained Exchange server).  Replaced the hard drive and the volume rebuilt without error.  However,
after the rebuild the Mailbox database started blowing errors about being corrupt.  I ran a chkdsk /f /r on both the C: and D: drives.  C: drive was clean.  Chkdsk on D: reported that
Windows replaced bad clusters in the file mbdata1.edb (mailbox database) file.
I can see the following errors:
ESE Event 474, 2007
ExchangeStoreDB Event 203, 233
Storage Group Consistency Check Event 254, 306, 401, 403 and 405
MSExchangeIS Event 9782
I ran an integrity check (ESEUTIL /g) which completed with errors:
Integrity check completed.
Database is CORRUPTED, the last full backup of this database was on 12/17/2011 08:44:37
Operation terminated with error -1206 (JET_errDatabaseCorrupted, Non database file or corrupted db) after 631.407 seconds.
I am finding [what seems to me to be] conflicting information on how to proceed.  It seems that I can attempt repair of the DB (using eseutil and isinteg) and risk possible additional damage to the file or create a new mailbox database and move
the mailboxes to the new database.
Looking for advice on how to proceed.

Answer 1

Good suggestions from Simon and a few additional points
1. Before doing any of the following I would ensure I made a complete backup of the appropriate files  i.e. the EDB as well as the VMDK to ensure you have the possibility to do a rollback if needed.
2. Since this is a VMware system I would suggest to you verify the VMDK is without issue and there are different methods for this dependent upon the version of VMware that you are running.  Just do a search in Google for something like "how to verify
a VMDK file"
3. ISinteg is no longer around in Exchange 2010 so the most you can do is to run eseutil  to attempt to repair the EDB and if that did work you would need to do a move mailbox which has integrity checking built in as part of the move process
4. That said IF the database is still online and accessible I would suggest that you;
A: Create a NEW/FRESH VMDK
B:  Then create a new DB on the NEW/FRESH VMDK
C: Start moving mailboxes from the old EDB into the new EDB. NOTE: You may want to temporarily enable circular logging during the move process to avoid log build up and then turn it off post process and get a new backup.
D: If you encounter errors in moving any mailboxes I would go on to the next and move all of them that you can and then come back and address     the problem mailboxes.
E: if they all move then you can kill off the old EDB.
F: of course you will also want to modify your backup process to protect the new EDB
The other option as Simon pointed out would be to;
A: Take the DB offline and copy it off to a safe place
B: Recover from your last known good backup
C: Then take that copy of the database that you have, make a new copy and use the MS Recovery DB process
http://technet.microsoft.com/en-us/library/dd876954.aspx or a 3rd party product like Lucid8's DigiScope
http://www.lucid8.com/product/digiscope.asp to open the old damaged offline database so that you can merge the delta data into the restored database in the Production Exchange Server.
Troy Werelius
www.Lucid8.com
Search, Recover, & Extract Mailboxes, Folders, & Email Items from Offline EDB's and Live Exchange Servers with Lucid8's DigiScope