This segment highlights the concept of recovery in case of Exchange Sever and what types of schemes are adopted to reply log files to bring back the most updated database. Also, a recovery technique is suggested here that can help to recover Exchange 2010 database without log files.
When it comes to recovering Exchange database, the first thing that clicks an administrator’s mind is transaction log files. Recovery is ideally defined as the process of replaying the log files against its database. There are two ways in which recovery can be processed for Exchange Server DB:
Soft Recovery: In this scenario, recovery takes place automatically. The transaction logs are replayed against the database after an unexpected shut down. The checkpoint file defines which log files has to be replayed against the database once the server gets started. In case, no checkpoint file exists, the recovery will take place through the oldest log file.
The checkpoint file keeps a track of log files that have not been written to the database yet. The incomplete or uncommitted transactions are written to the database through soft recovery procedure. Although, it is an automated procedure, it can be performed manually using ESEutil /r parameter.
Hard Recovery: This process involves restoring database from the backup and then replaying logs against it. When the DB is restored from the backup, a restore.env file will be created under the temporary folder which works like a checkpoint file, i.e. defines which logs should be replayed.
It should be noticed that no log file can be externally added for replaying because the restore.env file restricts doing it. After restoration, hard recovery takes place through the ESEutil /c parameter. This proves extremely useful in cases of scenarios like server crash, mailbox database recovery where there is requirement to restore the updated data.
Note: It is strictly prohibited to replay log files of a database against another database. Also, the replaying process will fail if the checkpoint file points to an incorrect log or the log file is corrupt or missing from the series.
Exchange Database Recovery When Log File is Unavailable
If the log file is unavailable, the other option available to get the lost database is to go for repair process. Using ESEutil to repair the database does not call for log files availability but generally taken as a last resort by the administrators as it is a time consuming process and leaves database in an unmountable state in most of the cases.
If the log files are missing or in corrupt state, the database can be recovered using a EDB file recovery tool.These data recovery solutions for Exchange are developed with specialized algorithms and thus support recovery of permanently deleted items from Exchange mailboxes along with extracting the database from EDB files. Entrusting one such tool can offer solution to multiple database related problems of Exchange Server.
It looks like you're new here. If you want to get involved, click one of these buttons!