How to Restore an Exchange Server by Overwriting an Existing Database?

Consider a situation when your Exchange database is lost or damaged. You have created a backup of Exchange server database which is stored at a safe location. Now, you want to restore your Exchange database from the existing backup copy. You can easily restore it but your current Exchange database may get overwritten by the backup restoration. Before performing the restore process, you must dismount the Exchange databases that you want to restore. If a database that you want to restore is still mounted, the restore process will fail. To make sure that the restore process overwrites Exchange databases, you must configure the Exchange databases that are being restored. 

 

To make more copies of the damaged Exchange database so that you can try to repair it later if essential, there are few important points that you need to take care of. 
 

• 1.  Determine the location of the Exchange database and log files so that you can move or copy them.
  
  
  
• 2. Record information from the properties dialog boxes from both the database and the storage group that contains the database. In addition,
• 3. Preserve the existing Exchange database files before they are overwritten by a copy of Exchange server backup in case of unsuccessful.
  

Keeping other copies of the damaged Exchange database files allows for more recovery options. 
 

The names of the Exchange storage groups and databases (mailbox stores or public folder stores) must match with the names of the storage groups and databases as they exist as objects in Active Directory for the server to which they are being restored. In case Exchange System Manager is running on any Exchange server in the organization, it will read this data from Active Directory to verify data against the names of the storage groups and databases as they appear in your Exchange backup. If the names do not match, the restore process will fail. 

In case a database or storage group name has changed, you only have to rename the database or storage group to perform this operation. If you are setting up a new server and the database or storage group is missing, you have to create them. Furthermore, you must ensure that the Microsoft Exchange Information Store Service (MSExchangeIS) Is Running. If you are restoring differential and incremental backups, make sure to restore the backups in chronological order. You must restore the normal backup first and then restore any incremental or differential backups in chronological order. After completing Exchange database restoration process, you may find database in an inconsistent state. To make it consistent, you must replay the transaction logs to bring the database up-to-date or make it consistent. 

 Mounting the Exchange database store is the last step in recovering or restoring an Exchange database. Before you mount the store, make sure that the hard recovery has been completed and you can check whether the Restore.env file has been deleted. Restore.env is not deleted until the hard recovery succeeds. 

 

In spite of that, if you are not satisfied with the result then you should look for a professional tool like Lepide Exchange Recovery Manager. It is much capable to fix all Exchange server issues and restoring data from any Exchange backup copy. In fact, it is a multipurpose Exchange recovery software solution that helps you extract only required or complete Exchange database from the existing backup created by NT, Symantec, HP, VERITAS or CA ARCserve backup. Get additional information about restore exchange, please click here : http://www.lepide.com/exchange-manager/restore-from-backup.html