Exchange has encountered a disaster and Exchange administrator has to recover the database! What should be the course of action? Should the database be recovered using soft recovery or decide for hard recovery? The final course of action should be decided basis the available possibilities and resource competency. Understand the difference between inbuilt Exchange utility features of Eseutil soft Recovery and Eseutil Hard recovery.
Before understanding the complete processes, it is important to know the difference between frequently used different but similar considered terms: “Restore” and “Recover”.
Restore involves putting database and log files back into place on a server while recover involves replaying log files into restored database
Inbuilt Utility is differentiated into two forms of recovery:
Soft Recovery: Transaction log replay process performed after the database is remounted after an unexpected stop. Alternately, transaction logs are replayed into an offline database backup.
Hard Recovery: Transaction log replay process performed after restoring database from online backup.
Eseutil Soft Recovery
An Exchange Administrator agrees to the fact that transaction logs hold the same place as Database files when it comes to Exchange Database recovery. This is because Exchange ensures all transactions to be recorded in Log files before these are written on Exchange database. In a nutshell, transaction logs enlists all steps to be performed to update database. Thus, in case the database is not accessible Exchange can be restored through Transaction files.
What exactly happens?
One of the most common issues usually encountered is that the Exchange server database abruptly stops due to an unforeseen external event, however, the database and log files are not affected. When the Exchange Administrator tries to mount the database again, the Exchange tries to read the Checkpoint file and starts replaying the transaction log listed as Checkpoint log. In case the checkpoint file is not available, the Exchange track holds of oldest available log file in the transaction log for storage group.
To perform soft recovery procedure, it is presumed that NO database files and log files have been removed and/or deleted due to failure of by the administrator after the failure.
Fundamental Rules of Transaction Log file Replay
The log files cannot be replayed:
- From one database against a different one
- Unless all uncommitted log files are available from the time the database is unavailable
- If fundamental file path for log files is changed
- If checkpoint file points to a different log
- If any database files for the storage group have been removed
Soft recovery cannot run for other databases in a storage group if one of the database is missing, else there will be complication in future log file replay.
Soft recovery occurs for entire storage group because all databases in a single storage group share a single stream of log files.
Eseutil.exe soft recovery function or syntax as used is:
ESEUTIL /r enn /L [path to log files] /s [path to checkpoint file] /d [path to database file] /i
This is also represented by the following example:
ESEUTIL /r e01 /Lf: \mdbdata /sc: \exchsrvr\mdbdata /dg: \mdbdata /i
- Log file prefix: E01
- Log file resides in f:\mdbdata
- Checkpoint file resides in c:\exchsrvr\mdbdata
- Database and streaming file reside in: c:\exchsrvr\mdbdata
- /I shows missing database is ignored
- Characters are not case-sensitive
Eseutil Hard Recovery
Online backups are a must have as far as Exchange Database Hard recovery is concerned. Hard Recovery differs from soft recovery as shown in the point below:
- During Log file replay, it is mandatory to apply patch information to the database
- No role of checkpoint file. hard recovery uses Restore.env to identify the log file through which recovery starts
How Hard Recovery is better than soft recovery?
- Ignores the database path listed on the log files: Log file replay succeeds even if the database is restored from the path different than where it was backed up.
- Log files from normal transaction log folder is replayed: Exchange administrator designates a temporary folder for restore. Restored transaction log files replay first from a temporary folder as designated by the administrator before restore.
- No failure even if there are missing databases in the storage folder
The database files – EDB and STM restored from available online backup are restored to normal paths defined for the database. Backup program creates a Restore.env file in the temporary folder. The Restore.env file performs the same function as checkpoint file.
Both these process have limitations:
- Log files should not be corrupt/missing
- Database backup should be available online
What if there are broken links between the tables, or the structure improvement needs deletion of internal pages? Exchange Database recovery process remains incomplete even after putting up so much effort and time. Rebuilding database using defragmentation and correct B-structure of database is a lengthy time consuming complicated process with no surety of recovery of healthy database.
The best option is to recover the database using EDB File recovery tool – Stellar Repair for Exchange. This tool repairs corrupt Exchange database
Stellar Repair for Exchange tool is loaded with interactive graphical user interface or GUI to help recover database from EDB file to PST, MSG, EML, RTF, HTML and PDF formats. The tree-format structure promoted three-pane view which helps Exchange administrators to choose amongst the mailboxes and/or particular files to recover. Direct export to live Exchange server option is also available in few easy steps.
Time is precious. There’s no need for Exchange administrators to involve their valuable work hours in executing lengthy steps of Eseutil – soft recovery and hard recovery procedures. And if the processes fail to deploy healthy databases; the whole endeavor is rendered futile. Instead install the Exchange database recovery software – Stellar Repair for Exchange for faster, easier and complete database recovery.