After a database crash, How to mount the Exchange database?

Microsoft Outlook is configured with MS Exchange, and Exchange server saves user mailboxes into Exchange Database (EDB) files. If there is anything erroneous with Exchange Database, it causes a significant effect on email communication till the user remounts the database. Further, database crash directly affects Outlook users due to which they are unable to access their emails or work on their contacts, calendars, emails, and more. Under such circumstances, restore your database with the help of updated backup, but if the backup is not updated, then go for Exchange database recovery either through the manual method or professional software.

When an Exchange database crashes, the user tries to recover the crashed database by moving the ‘log files’ and ‘chk files’ to mount the database and the process was successful, except that a few mailbox users are unable to send or receive emails and the following message is displayed:

1. Restore from backup

The most straightforward solution to overcome this situation is to restore from exchange backup. Exchange users are aware of the fact that they may have to face the problem of Exchange Database crash. Hence they always configure a backup of their database. Use this backup to restore the Exchange database.

• Check if the backup is up-to-date. Only the latest backup is with complete communication-information.
• Check if the user can restore the exchange database from available backup.
• Check the health of database backup. In case the backup is not healthy, then it may cause further corruption in Exchange database.

If the backup meets all the three conditions, then restore Exchange database from available backup, else use the next best option for repair.

2, Mount Exchange Database

If few of the mailboxes are unable to send and receive emails even after repairing the crashed database, then there are chances of corruption in the underlying database structure. Users have an option to overcome this issue by creating a new database – DB02, and moving all mailboxes from the old database (DB01) to the new database (DB02). Creating a new database ensures that:

1. The core database structure is good
2. Database is free from corruption
3. No need of data-repair process which could not result in corruption-free database
4. Prevention of data store crash and server problem

Run the following command after creating the new database:

Get-Mailbox -Database DB01 | New-MoveRequest -TargetDatabase DB02 -BatchName "DB01toDB02"

This process transfers all available data within the damaged databases to the new EDB. However, there are chances of data loss. If the mailbox contains important organizationaldata, then the loss may affect business operations. A better solution is to use Stellar Phoenix Mailbox Exchange Recovery to repair the corrupt mailbox and recover all mailbox components without data loss.

3. Recover by creating two EDB Files

Perform the following steps, in case the repair and recover Exchange database process, as described earlier, does not yield desired results. Creating two EDB files separates the corrupt mailboxes from the healthy ones as these corrupt mailboxes are available in a different EDB file. The recovery steps are:

1. Move all mailbox to DB02
2. Once all the mailboxes have moved to DB02, take the folder offline and rename this folder
3. Next, create a new folder with the same name. In this case, it is DB02 and mount the database
4. Exchange server displays a message server stating that it cannot find one or more of the DB files and suggest that if you continue, a new Database is generated.
5. Click on Yes button and a new EDB file is generated
6. Move the mailboxes to the new EDB file, but the problem is that the previous information contained in the mailbox is no longer available.

Since the previous information is not available, then mailbox user may end-up losing some critical data and recovery of this data is also not possible due to newly created Exchange database and absence of backup.

4. Repair using Eseutil

1. Run the Eseutil/P command against the old damaged EDB files to clean the corruption
2. Use MS RDB or Exchange PowerShell Management method to restore previous data on the mailbox.

The drawbacks of restoring with Exchange PowerShell Management method are

1. It is time consuming and lengthy process.
2. User needs to copy the corrupt Exchange database before starting the procedure because in case the PowerShell commands fail, the database goes into the dismounted state
3. If MS RDB process fails to restore databases, then the database has to be restored using an alternate method, which requires further consumption of resources
4. Even after completing the whole process there is no surety if it results in database restoration

Relying on Stellar Phoenix Mailbox Exchange Recovery Software helps in saving time and efforts which is required to use the lengthy and time-taking processes to mount the repaired Exchange database. Deploying professional software to repair the corrupt Exchange database ensures recovery of the entire database in case the database crashes.

Conclusion

All Exchange administrators face issues related to Exchange server or Exchange database and most of the time these issues are resolved either by backup restore or following the disaster recovery plans. However, some database crash issues are beyond repair and users are unable to mount the Exchange database. These problems have a permanent solution, and that is using the professional software like Stellar Phoenix Mailbox Exchange Recovery software. The Stellar Exchange Recovery software repairs the corrupt database and mounts the Exchange database and exports recovered mailboxes to Live Exchange server or MS Office 365.