Recovery Tools for Exchange Server Database : Options & Operability

Repairing the Exchange Server database can  be a complex, time-consuming, and an effort demanding task. Before opting for repair process, it is important to examine the actual problem with a database that can be found with the event log. When the error is known, you can either go to the Microsoft support site, get more information about the problem from the internet, or contact DR professional. However, the cost of contacting and calling a Microsoft professional would be affordable as  compared to other ideas. Communities such as Experts-Exchange are also a viable source of assistance as the members participate and respond quickly & precisely to each and every query. 

Once the database is repaired, you can check its successful execution by mounting it on the server. You will be either able to mount the DB on Server or again come across another error saying unable to mount database on the server. However, the worst part of opting to repair a database is, you remain unsure if any data will be lost while processing and what is the guarantee that errors will not crop up again.  

  Exchange Server includes command-line utilities that help to monitor and manage the database. ESEutil is one of them that helps to repair, restore, recover, test integrity of the database and do much to work around issues at page level. It can be found under the bin directory of the Exchange Server installation and works against both public and private folders. The good part about this utility is generates a temporary database and the fixed information will be written to new DB.

Size of the database can be determined from Event ID 1221 and white space can be subtracted from the total sized defined. If the size of the database is 25GB and the event ID reports 4GB of white space, then the actual size of DB would be 21GB. There are number of ESEutil switches that can used to perform a number of tasks and for every operation to be performed, there is a standard syntax to be followed that will be available using “eseutil help” command.

/P Repair: It repairs database in offline state by removing pages that it cannot fix. Individual tables are fixed, but no relationship will be built between them. This is the reason why it is mandatory to run the Isinteg utility after repair process so as to rebuild index of the database.


/D Defragmentation: This helps to defragment the database, i.e. remove white space and compact

/R Recovery: This is to bring back internal consistency of the database by replaying log files an offline database after unexpected shutdown.

/G Integrity: Page and ESE level integrity can be checked using this switch. For application level, the Isinteg utility has to be used.

/M File Dump: Details about the database, its header, transaction logs, checkpoint files, database space allocation etc. can be checked with this switch. The file dump mode of Eseutil can be run with following modes:





/K Checksum: It will verify checksum of all pages for database and the transaction logs.

/C Restore: This allows running hard recovery where log files are replayed against data restored from backup. Hard recovery of Exchange database is performed through restore.env that gets saved in a temporary folder after backup restoration. The process involves replaying log files against restore.env file.

It works on database to remove errors at the application level. In short, Isinteg can do what Eseutil can’t. The data that seem to be vaild at physical schema level can be invalid for logical schema level. Basically, the Isinteg utility corrects the index table, relationships at application level.

However, with Exchange 2010 Service Pack 1, Isinteg is  not available as a separate executable file and is rather integrated with Exchange management shell cmdlets “New-MailboxRepairRequest” and “New-PublicFolderDatabaseRepairRequest”. For example: To detect corruption type for a database, following command can be run:

These commands are run against a mounted database on Server to fix logical corruption issues. Once the repair request command is run, its status gets recorded in the event log that can be determined through some IDs like:

 
These command-line utilities for repairing database need expertise to work with them. Adequate disk space and permissions are required to operate them so as to get back database into a functional state.
 
Over the time, administrating Exchange Server platform and working around various issues, what has been realized is only native tools by Microsoft cannot always be a great help. They have advantages, but recovery through them is tricky and highly dependent upon backups most of the times. Third party solutions to get back data from  EDB files are helpful in various recovery contexts like:

#1: Non-dependency upon log files for recovery of the database.
#2: Extracting mailboxes and public folders from a failed Server is easy.
#3: Graphical User Interface and less permissions to recover the database.
#4: Very less scope of failure and high chances of successful recovery.

By the time I recognized the importance of EDB recovery tools and was permitted to use them, there were three names that were recommended by the IT staff:
  The tool has been developed for extraction and recovery of Exchange database. It is a means for EDB to PST recovery and data migration to EDB file of one Server to another.
Pros:

• All contents of the scanned EDB file can be previewed within the software panel.
• Public folders and mailboxes can be exported to different mailbox Server.
• Scanning and export speed of the tool for large sized EDB is praiseworthy.

Cons:

• There is no option in the tool for deleted mailbox or items recovery, which is called-after option for administrators.

Despite help from Microsoft’ end have been quite useful, but definitely the fact is, there are a number of operations that can be quickly performed by third party tools. Extracting selected mailboxes,moving public folders, exporting mailboxes to new Server, recovering data without backup and much more.
  ​This tool gives a GUI platform so that mailboxes and public folders from EDB file can be saved in PST. Even if the database file is dismounted, its data can be exported into PST file.
Pros:

• Emails can be exported from EDB mailbox and public folders to MSG, PDF, EML, and MBOX.
• At a time, multiple database files can be added for recovery and conversion.
• Data recovery from an offline Server to PST file is a helpful feature of the tool.

Cons:
In case of Server failure, the software does not offer any mode for quick recovery and get started in minimum downtime.
There is no option in the tool that can migrate mailboxes from a database to another Server.
The tool is simply an EDB to PST conversion solution that can extract data if the database file is corrupt or is in offline state
   Name of this tool itself suggests that it is completely meant for the job to convert an EDB file into PST file format. Again, like other paid solutions in the market, it selectively extracts mailboxes from EDB file to PST.
Pros:

• The software is tested against various odd scenarios and its potential to fix errors in worth praise.
• Supports recovery from pub.edb as well as priv.edb files which means complete data extraction is possible.
• Mailboxes can be optionally skipped and data can be extracted in bulk from EDB file with a speed.

Cons:

• There is provision for EDB to PST. No additional format for the output file is provided to as to enhance the availability of Exchange database.
• There is no way to check out the contents of EDB mailboxes and move database directly to different Server.

 
Note: The experience shared is inspired by real-time administration of Exchange Server. Be it native solutions, dealing with disasters, or usage of third party solution, everything is an attempt to share what can be done to maintain business continuity. There is no connection with any company for any financial profit. 

Previous Articles : 

• MS Exchange Server Administration and its Challenges
• Monitoring and Validating Backups