If you are an Exchange Server Administrator, you may know that the Exchange Server crash brings a severe catastrophe on business data. The complete database is lost, and the user cannot access even a single email from the account. The article will show you how to get back the Exchange data after a severe Exchange Server crash.
The efforts involved in restoring Exchange database is directly proportional to why, and how badly, the Exchange Server has crashed. However, in most of the cases the Exchange Server fails due to hard-disk failure or other similar kind of disaster from multiple system failures, or power outage. The below-discussed recovery technique is offered, while considering that your Exchange Server components are functioning well, and only the database has gone through a hard disk failure crash.
In Microsoft Exchange Server, one should not get confused the term recovery with restore. ‘Recovery’ is the process of replaying transactions logs into the restored database, whereas ‘Restore’ is the process of storing database and log files, at the exact place on to the server.
As we know that Exchange comprises three databases, which are Priv.edb, pub.edb and dir.edb, and all of these use Jet database format. However, recovering Exchange database is a little tricky and complicated job, because the EDB files are likely susceptible to corruption. Generally, the corruption issue begins with a small database glitch, which may not highlight at first, until you halt and attempt to restart the Exchange services. When you do so, it comes into notice that Exchange service doesn’t start.
Restore Techniques: There are two techniques to restore your inaccessible data after the Exchange crash.
- Online Restore
- Offline Restore
Online Restore
The online restore is one of the effective solutions that should be implemented in a situation of Exchange crash. However, the proper technique for conducting an online restore depends upon the backup tools that you are using. Though, the process is easy as choosing the required database that you wish to restore from the tape. Once you have done that, the backup tool will start verifying that if there is any Exchange service controlling the running databases. If any, then the backup tool will halt that service. Once the restore operation is done, then the user has to manually restart the Exchange services.
Offline Restore
An offline restore operation is a more complex task than online restore. Before proceeding towards the offline restore procedure, specifically ensure that the Exchange services are stopped and no longer in use. After the full assurance that they are stopped, then start copying the database files to the respective directories. Now initiate the directory service and when it starts, then it indicates that it has recovered empty user mailboxes. To progress further, you have to recover Information Store.
It is very essential that Information Store should match the directory service. In order to make this happen, you have to simply place the pub.edb and priv.edb files in the correct directory. Now you can safely start the information store and MTA. If the store has started, then you have successfully restore the Exchange database. However, if the store fails to start, you have to synchronize it.
To start Information store, simply go to \EXCHSRVR\BIN directory, and now execute the below-mentioned command.
isinteg -patch
However, if your Information Store is of large size, then this command may take longer time for the completion.
Restore Techniques: Exchange recovery can be performed in two ways:
- Software Recovery: It is described as a transaction log replay process which gets generated when transactions logs are replayed in offline file backup of database, or when a database is re-mounted upon an abrupt halt.
- Hard Recovery: This is a transaction log relay process that gets generated upon restoring a database directly from an online backup.
Soft Recovery
The soft recovery technique is successful when any external event has abruptly stopped the Exchange database. But the log files and the database are unaffected and remain at the same place. At this point of time, when database is mounted, then Exchange Server acknowledges the checkpoint file and starts replaying the transaction logs, available in the checkpoint file. When it finds no file, then replay starts from the oldest log file in the transaction log folder.
Now, Exchange Server writes completed transactions that available in the log file to the database file. The uncommitted transactions are reversed back. The user doesn’t have to manually undo the transaction, if uncommitted logs are available when the replay starts. Exchange never initiates writing a transaction to database, unless ensures that all the concerned operations are fully secured to the log files.
Below given is the complete syntax for performing Eseutil.exe soft recovery function:
ESEUTIL /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i
Type the following in the command line:
ESEUTIL /r e01 /Lf:\mdbdata /sc:\exchsrvr\mdbdata /dg:\mdbdata /i
Running soft recovery:
“/a” is for missing log files. Attempt to bring database to a healthy state.
Check log file location and verify how it starts E00 or E01 or E02
Verify the status upon perfoming soft recovery. If it shows clean shutdown, then you can safely mount the database and if not then move the log files and try again in clean shutdown state.
While performing the recovery using soft recovery, there will be certain amount of data losses, mainly from the corrupted portions. It may be helpful to repair 98% of your databases. But it is recommended to move the user mailboxes to different database to be on a safer side.
Hard Recovery
Hard recovery can only be accomplished upon restoring it from the online backup. Hard recovery can be described as a log file replay process, which is quite similar in nature to the soft recovery, but contains certain differences. While performing the hard recovery, simply make sure of these differences:
- Patch information is applicable to the database only during log file replay.
- The checkpoint file is not used in hard recovery. Instead restore.env is employed to determine the start of log file recovery.
When No backup is Available
Some organizations don’t practice to back up their Exchange databases, which could become a total catastrophe at the time of data loss of precious corporate knowledge and email systems. In case, you don’t have the backup, then the recovering process may take a longer time, about 5-10 GB data recovery per hour. Additionally, the recovery also depends upon the external factors like IOPS/processor.
When Nothing Works
We presented you with the detailed process to recover data after Exchange Server is crashed. If you cannot recover the database data manually, you can use Exchange Recovery software to scan the EDB file and recover entire mailboxes. The software will recover the complete data and save it in a Live Exchange Server. There are several filter and destination options available in the software.
