Database corruption is the bane of Exchange Administrators – and recovering from any type of corruption is complex and time-intensive. When either logical or physical corruption is present, administrators must determine the best path to database recovery. Recovery options include:
· Repairing the database by running the Exchange Server Database Utilities (ESEUTIL). This process entails taking the database itself offline (and thus, not providing messaging services to the users) and using ESEUTIL in repair mode (ESEUTIL /p). ESEUTIL can be destructive in certain circumstances, as database pages that cannot be repaired are discarded. After ESEUTIL has completed in repair mode, it should then be run again in defragment mode (ESEUTIL /d). ESEUTIL. It should be noted that ESEUTIL can process about 9GB of data per hour, so two different ESEUTIL operations on a 50GB database would take approximately 11 hours to complete. After both ESEUTIL operations have completed, database integrity should then be performed by using the Information Store Integrity Checker (ISINTEG) with the “–fix” and “–test alltests” switches. If ISINTEG is able to fix all database errors on the first pass, a report will be presented that shows the error count as zero – if all errors were not able to be corrected with the first ISINTEG operation, ISINTEG will need to be run again until the error count is zero. ISINTEG performance is roughly equivalent to that of ESEUTIL, depending upon the number of errors that must be corrected.
· Restoring an older database copy and letting the transaction logs generated since the backup was taken replay in order to bring the database back to the state when the failure occurred. These operations take less time than running database utilities; however there have been numerous instances where organizations that thought their backups were valid found that the backups could not be restored to operation when necessary. The speed of database recovery varies depending upon the type of backup performed – Volume Shadow Copy Service (VSS) allows third-party vendors to provide quick database backups, and these backups are also quick to restore – but they may only be restored to their original location. The Recovery Storage Group (RSG) introduced in Exchange Server 2003 reduced the complexity of previous recovery methods, however the RSG only works with streaming backups which take much longer to restore than VSS-based backups. Depending upon the number of transaction log files that must be replayed, there may be a significant amount of time that passes before a restored backup will be available to provide messaging services. (No lie - I once experienced a 10+ hour wait while transaction logs replayed. Not fun.)
· In cases where the database is still operational, the best option is often to move the mailboxes themselves to a different information store. This process involves less down time for users (while a mailbox is in the process of being moved, it will be unavailable to the individual with whom it is associated; mailboxes that are not in the process of being moved will remain available for access) and is the preferred path when available. If a database has dismounted due to physical corruption and cannot be remounted, this option will not be available.