Recovering from a Disaster in an Exchange Server 2010 Environment : Recovering from Database Corruption

2/11/2011 9:05:05 AM
If an Exchange Server database is corrupt, it is not extremely effective to restore the corrupt database to a production server. The server might continue to operate, but database corruption never goes away on its own, and you eventually need to repair the database. In fact, when minor database corruption is not repaired, the corruption can get to the point that entire sections of the Exchange Server database become inaccessible.

A couple of methods can be used to repair a corrupt Exchange Server database, or at least restore the database and extract good information from the database. Key to the successful recovery of as much information as possible is using the right tool. In many cases, administrators jump right into using the ESEUTIL /p repair command; instead of repairing the Exchange Server database to 100% condition, the utility finds a corrupt section of the database and deletes all information from that portion of the database on. So, although the Exchange Server system becomes 100% clean, the utility deleted 20%–30% of the data that was in the database to get the database to a clean state. The ESEUTIL /P command is the task of last resort: Other tools work around corrupt database areas and enable the administrator to recover as much of the data as possible.

Exchange Server 2010 makes this process easier for the new administrator by introducing the Database Recovery Management tool that analyzes the failed databases for the administrator and choose what tools to run against them.

Flat-File Copying the Exchange Server Databases

One of the best techniques Exchange Server experts use when working to recover corruption in a database is to make a flat-file copy of the Exchange Server databases. A flat-file copy is merely an exact copy of the Exchange Server databases copied to another portion of the server hard drive or to another server. To do a manual copy of the databases, do the following:

Dismount the Exchange Server database stores by going into the Exchange System Manager. Traverse the tree past Administrative Groups, Servers, Storage Group. Right-click on the mailbox store, and select Dismount Store.

Dismount the store for all mailbox stores you will be working on.

Copy (using Windows Explorer, or XCOPY) the *.edb files to a safe location.


If the databases need to be manually restored, a simple XCOPY (or Windows Explorer copy) of the databases back to the original subdirectories will bring the data back to the condition the databases were in at the time the databases were copied off the system. If the Exchange Server databases were properly dismounted before they were copied, the logs would have already been committed to the database, and the database can be remounted exactly where it left off.

Moving Mailboxes to Another Server in the Site

One way of extracting mail from a corrupt database is to move the mailbox or mailboxes to a different server in the site. Instead of trying to run utilities to fix the corruption in the database, which can take several hours (or even days, depending on the size of the database and the amount of corruption that needs to be fixed), an administrator can set up another server in the Exchange Server site and move the mailboxes to a new server.

Moving mailboxes grabs all the mail, calendar, contacts, and other mailbox information from one server and moves the information to a new server. As the information is written to the new server, the information is automatically defragmented, and corruption is not migrated. In addition, mailboxes can be moved from one server to another without ever having to bring down the production server. A mailbox user must be logged off Outlook and must not be accessing Exchange Server before the mailbox can be moved. However, if mailboxes are moved when individuals are out of the office, at lunch, or on weekends, the mailboxes can be moved without users ever knowing that their information was moved from one system to another.

The two caveats to moving mailboxes are these: Corrupt mailboxes will not move, and user Outlook profiles will be changed. For Outlook profiles, because a user’s Outlook profiles point to a specific server, when a mailbox is moved from one server to another, the user’s profile also needs to point to the new server. Fortunately, with Exchange Server and Outlook, when a user’s mailbox is moved, Outlook tries to access the mailbox on the original server, and the server notifies Outlook that the mailbox has been moved to a new Exchange server. The user’s Outlook profile automatically changes to associate the profile to the new server where the user’s mailbox resides. So, as long as the old server remains operational and the user attempts to access email from the old server, the profiles will be automatically changed the next time the user tries to access email. Typically, within one to two weeks after moving mailboxes from one server to another, the user profiles are all automatically changed.

As for corrupt mailboxes, unfortunately, Exchange Server typically does not move a corrupt mailbox. So, if a user’s mailbox has been corrupted, the mailbox remains on the old server. Moving the data from the corrupt mailbox needs to be handled in a manner specified in the following section, “Recovering Data with a Recovery Storage Group.” However, if 80%–90% of the user mailboxes can be moved to a new server, the administrators are trying to recover only a handful of mailboxes instead of all mailboxes on a server. This could mean far less downtime for all users who had mail on the server and could limit the exposure of data loss to a limited number of users. It will also result in much faster results when running the database recovery tools as the database will be much smaller.

To move mailboxes between servers in a site, do the following :

Open the Exchange Management Console.

Expand Recipient Configuration and click Mailbox.

Highlight the mailboxes to be moved.

From the Action menu, choose New Local Move Request.

Select the destination for the mailbox to be moved, and click Next.

Choose how you want the tool to deal with corrupted messages, and click Next.

Review the proposed changes and if you are satisfied that they are correct, click New.

You can review the status and results of the move request in the newly added Move Request section by expanding Recipient Configuration in Exchange Management Console.

Running the ISINTEG and ESEUTIL Utilities

When a database is determined to be corrupt, usually an administrator is directed to run the built-in utilities on Exchange Server to run maintenance on the databases. The utilities are the ISINTEG (“eye-ess-in-tehg”) and ESEUTIL (“ee-ess-ee-u-tihl”). However, depending on the condition of the database, a corrupt database can take several hours to run, only to result in the loss of data. Some administrators are incorrectly told to never run the utilities because they will always result in loss of data. It’s typically just a lack of knowledge of how the utilities work that leads to misunderstanding the potential results of the databases.

As noted in the previous two sections, there might be better options for recovering information from a corrupt database. Instead of trying to fix a known corrupt database, simply migrating the information off a server or extracting information from corrupt databases is frequently a better fix. However, if the determination is to run the utilities, a few things should be noted:

  • The ISINTEG utility is a high-level utility that checks the consistency of the database, validating the branches of the database that handle data, data directory tables, attachment objects, and the like. Fixing the database table makes way for a more intensive data integrity check of the database.

  • The ESEUTIL utility is a low-level utility that checks the data within the database. ESEUTIL does not differentiate between a corrupt section of the database and how that section impacts mailboxes or messages. So, when a complete repair is performed using ESEUTIL, entire mailboxes can be deleted, or all attachments for the entire database can be eliminated to fix the corruption. This is why running ESEUTIL to repair a database is a function of last resort.

  • To run ISINTEG on a database takes around one hour for every 10GB scanned for a moderately corrupt database. The repairs are done relatively quickly, and the database is ready for more extensive scanning.

  • Running ESEUTIL on a database takes anywhere from one hour for every 10GB to up to one hour per 1GB, depending on the level of repair performed. It is not unreasonable to see a relatively corrupt 30GB database take more than 24 hours to complete the repair.

  • ISINTEG and ESEUTIL can be performed only offline, meaning that the Exchange server is offline during the process. Users cannot access their mailboxes during the ISINTEG and ESEUTIL processes. Thus, if it takes 20 to 40 hours of downtime to complete the repair of a database, the Move Mailbox method that can be run without bringing servers offline is frequently a more palatable solution.

  • However, if run on a regular basis, the ISINTEG and ESEUTIL utilities can clean up an Exchange Server database before serious corruption occurs. Administrators who get scared off performing maintenance because of the potential threat of losing data could actually minimize their chance of data corruption if the utilities are run regularly.

The common parameters used for the ISINTEG and ESEUTIL utilities are as follows. For regular maintenance, such as checking the database structure’s integrity and performing defragmentation of the database, the following commands should be run:

isinteg –s SERVERNAME –test allfoldertests
eseutil /d priv1.edb


The ISINTEG and ESEUTIL utilities typically reside in the \Program Files\Microsoft\Exchange Server\V14\Bin directory of the Exchange server.

When a database needs to be repaired, eseutil /p priv1.edb can be run. Beware: The /p repair command is a brute-force repair and deletes sections of the database to make the integrity of the database clean. A message provides an additional warning about ESEUTIL. When running the /p command in ESEUTIL, entire sections of the database might be deleted to repair and recover the state of the database.


Prior to a disaster, if the ISINTEG or ESEUTIL utilities have not been run against an Exchange Server database for a long period of time, restore the database from tape to an Exchange server in a lab environment to run tests. These tests can tell you how much corruption might be present and give an indication of how long it might take to repair the database.

  •  Recovering from a Disaster in an Exchange Server 2010 Environment : Recovering Exchange Server Application and Exchange Server Data
  •  Recovering from a Disaster in an Exchange Server 2010 Environment : Recovering from a Complete Server Failure
  •  Sharepoint 2007: Add a Column to a List or Document Library
  •  Sharepoint 2007: Create a New Document Library
  •  Sharepoint 2007: Open the Create Page for Lists and Libraries
  •  Exchange Server 2010 : Developments in High Availability (part 3) : Backup and restore
  •  Exchange Server 2010 : Developments in High Availability (part 2) : Configuring a Database Availability Group & Managing database copies
  •  Exchange Server 2010 : Developments in High Availability (part 1) : Exchange database replication & Database Availability Group and Continuous Replication
  •  High Availability in Exchange Server 2010 : Exchange Server database technologies
  •  SharePoint 2010 : Cataloging the Best Scripts to Automate SharePoint Administration
  •  SharePoint Administration with PowerShell (part 2)
  •  SharePoint Administration with PowerShell (part 1)
  •  Sharepoint 2007: Approve or Reject a File or List Item
  •  Exchange Server 2007 : Configure the Client Access Server - Enable POP3 and IMAP4
  •  Exchange Server 2007 : Configure the Client Access Server - Enable and Configure Outlook Anywhere
  •  Exchange Server 2007 : Configure the Client Access Server - Create and Apply ActiveSync Mailbox Policies
  •  SharePoint 2010 : Understanding Windows PowerShell Concepts (part 3)
  •  SharePoint 2010 : Understanding Windows PowerShell Concepts (part 2)
  •  SharePoint 2010 : Understanding Windows PowerShell Concepts (part 1)
  •  Managing and Administering SharePoint 2010 Infrastructure : Using Additional Administration Tools for SharePoint
    Top 10
    Qooq - The First Culinary Tablet Made For The Kitchen
    HP Envy 23 TouchSmart - All-in-One Desktop PC
    Kobo Aura HD - An Excellent Ebook Reader
    Razer Edge Pro - It Combines Tablet, Laptop And Gaming PC In One
    Samsung Galaxy S4 Review (Part 8)
    Samsung Galaxy S4 Review (Part 7)
    Samsung Galaxy S4 Review (Part 6)
    Samsung Galaxy S4 Review (Part 5)
    Samsung Galaxy S4 Review (Part 4)
    Samsung Galaxy S4 Review (Part 3)
    Most View
    Canon EOS M – Is The Final Big Player?
    Windows 7 : Networking and HomeGroup Sharing - Sharing Between PCs (part 1) - HomeGroup Sharing
    KWA 150 SE – The Most Expensive Amplifier Of ModWright
    MSI FM2-A85XA-G65 Motherboard Review (Part 1)
    Nikon D600 Digital SLR Camera - Full-Framed Temptress
    Tips & Tricks Of November 2012 (Part 1)
    Popular GPS Apps Shootout (Part 1)
    Cambridge Audio Azur 751R - The Importance Of Being Earnest (Part 1)
    Google vs Apple vs Microsoft (Part 5)
    Roll Your Own Home Server (Part 1)