Exchange recovery types

Exchange server crash is a common headache for most exchange server admins out there. It can occur randomly due to many unforeseen reasons, the trigger may be something as trivial as a unintentional human error to something serious as security breach by malicious software, system failures etc.When one tries to access the exchange database file after such an event, it often throws up an exception, this error is most likely due to the exchange database (.edb) being inaccessible. Being inaccessible indicates there is some database corruption.Let's look at some likely solutions in case of database corruption.

Most of the times the first and foremost impulse of exchange server administrators will be to make use of Microsoft's own native 'Eseutil' Exchange management shell utility. It is a powerful tool that can help recover exchange database when used correctly. Before using Eseutil , however, one must understand the types of exchange recovery that it can perform.Eseutil mainly allows for two types of recovery, namely - Soft Recovery and Hard recovery.

Soft Recovery

A soft recovery is performed when an external event disrupts exchange server but the database itself and log files remain intact or in other words the database and log files are not moved, deleted or tampered with manually by the administrator or by the unforeseen failure.When a soft recovery starts, the exchange mounts the database again and starts replaying the transaction logs. In case the checkpoint file is not available, the oldest available logs are used. The transactions found in the logs are written into the database if they haven't been already written and any incomplete transactions are reversed .

Syntax:

ESEUTIL /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file]] /i

If the paths to log and checkpoint files aren't specified, eseutil assumes them to be in the the current working directory. The switch '/i' tells Eseutil to ignore missing databases.

Some important points to keep in mind when it comes to transaction replay:

• Log files from one database cannot be replayed against another

• All uncommitted log files from the time database was last up and running needs to be available to be able to replay log files

• Replay of logs is not possible if the checkpoint file points to a wrong log file

• All databases that were running at the time of unexpected failure should still be present for replay of logs

Hard Recovery

Hard recovery is performed after database restore from online backup. Hard recovery is a log file replay process that is similar to soft recovery but with few significant differences:

• The database is patched during log replay itself

• Checkpoint file is ignored and Restore.env is used instead

As you begin restoration of online backup the exchange asks you to provide a location for temporary folder and the transaction logs files from the backup are placed in this folder. The Restore.env defines the range of transaction log files that should be present in the temporary folder for hard recovery.

Syntax

ESEUTIL /cc [path to the restore.env folder]

Alternatives to Eseutil

Although it can be useful at times, eseutil can sometimes not yield desired results and can often be tricky to use. One easy way to get around this is by using EdbMails EDB to PST exchange recovery tool that can easily recover corrupt databases. EdbMails doesn't require log files and its deep scan can recover most data out of corrupt offline databases and convert mailboxes to Outlook PST effortlessly. It can also perform EDB to Office 365 and EDB to Live exchange.