Exchange has encountered an error and Exchange administrator has to recover the database! What should be the course of action? Should the database be recovered by using Eseutil Soft Recovery or the Exchange admin should go for Eseutil Hard Recovery?
To know the final course of action, you need to understand Eseutil and the difference between two recovery options i.e., Eseutil Soft Recovery and Eseutil Hard Recovery.
Before understanding the Eseutil recovery process, 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.
Eseutil Database Recovery Options
Eseutil is an Exchange utility that helps Exchange and IT admins to repair minor mailbox or database corruption. It is also used to check the database consistency and run database integrity or health checks to ensure database availability. Following are the two database recovery options that you can use to recover corrupt or inconsistent database in Exchange:
- Eseutil 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.
- Eseutil 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 enlist all steps to be performed to update database. Thus, in case the database is not accessible, Exchange can be restored through transaction files.
How Eseutil Soft Recovery Works?
One of the common issues usually encountered is that the Exchange server database abruptly dismounts or stops working 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, Eseutil Soft Recovery can be performed to recover the database.
However, if the transaction log files are missing or deleted, Soft Recovery may fail and display an error message, such as -1022 jet_errdiskio.
Things to Remember While Running Exchange Eseutil Soft Recovery
To perform soft recovery procedure, it is presumed that NO database files and log files have been removed, missing, and/or deleted due to hardware or software failure or accidental deletion.
Fundamental Rules of Transaction Log File Replay and Soft Recovery
Log files cannot be replayed or Soft Recovery won’t work,
- From one database against a different one
- On a copied database file
- 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
Also, Soft Recovery cannot be performed on other databases in a storage group, if one of the databases is missing. Otherwise, there will be complication in future log file replay.
Soft Recovery occurs for the entire storage group because all databases in a single storage group share a single stream of log files.
To run Eseutil Soft Recovery, you need to navigate to Eseutil.exe directory C:\Program Files\Microsoft\Exchange Server\V15\Bin in PowerShell and then use the following syntax for Exchange Soft Recovery:
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 /L F:\mdbdata /s C:\exchsrvr\mdbdata /d G:\mdbdata /i
Here, E01 is Log File Prefix that resides in F:\mdbdata
C:\exchsrvr\mdbdata represents Checkpoint, Database, and streaming files Location
/i switch is used to ensure missing database is ignored and avoid streaming error.
All characters are not case-sensitive.
Once Soft Recovery is successful, you can use the Eseutil /mh command to check the database status. If the database is recovered, the status should be Clean Shutdown.
However, if the database status is Dirty Shutdown, it indicates Soft Recovery failure. In such a case, you can attempt Hard Recovery to recover the corrupt database and restore mailbox connectivity.
Eseutil Hard Recovery
Eseutil Hard Recovery is performed when Soft Recovery fails. However, Hard Recovery requires at least 1.2 times additional storage space than the size of corrupt database as it creates a temporary database during the repair process. If the storage space isn’t available, Hard Recovery may fail.
Further, you must backup the current database to avoid data loss as Eseutil Hard Recovery deletes non-recoverable data or mailboxes during recovery. However, you may also use an automated tool, such as Stellar Repair for Exchange to fix database corruption, recover mailboxes, and restore them to live Exchange server in a few clicks. Unlike Eseutil, the software features a graphical user interface and supports Exchange 5.5, 2000, 2003, 2007, 2010, 2013, 2016, and 2019 versions.
When compared to Soft Recovery, Hard Recovery differs at following points:
- During log file replay, it is mandatory to apply patch information to the database.
- There’s no role of checkpoint file in Hard Recovery. It uses Restore.env to identify the log file through which recovery starts.
- 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.
NOTE: The database files – EDB and STM, 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.
Syntax for using Eseutil Hard Recovery
Following is the syntax for using Eseutil Hard Recovery to recover corrupt database:
ESEUTIL /P <path_to_the_database>
Eseutil /p C:\program Files\ExchSrvr\MyDB.edb
Once Hard Recovery is performed, it’s important to check the database integrity by using IsInteg command,
Isinteg –s <server_name> -fix –test alltests
Limitations of Eseutil Hard Recovery and Soft Recovery
Eseutil Soft Recovery and Hard Recovery may not always work. They may also fail or stuck due to severe database corruption. There’s also a risk of data loss and further damage to database.
Thus, the best option is to recover the database by using EDB file recovery tool – Stellar Repair for Exchange. This tool repairs corrupt Exchange database with 100% integrity, precision, and without the risk of data loss.
Stellar Repair for Exchange features an interactive graphical user interface to help recover database from corrupt or damaged EDB file to PST, MSG, EML, RTF, HTML, and PDF formats. You may also export the mailboxes from repaired database to live Exchange and Office 365 accounts.
The software previews mailboxes and data in tree-format structure, within three-pane view that helps Exchange administrators to recover specific mailboxes. It also helps admins to recover deleted mailboxes.
With Eseutil, Exchange administrators can manage the Exchange database and keep a check on the database health. However, if the database gets damaged or corrupt, Eseutil can be used to recover the database. It features two recovery options i.e., Soft Recovery and Hard Recovery that must be used carefully to avoid any further damage to database or data loss. But Eseutil recovery is a lengthy process. Also, if the processes fail to deploy healthy databases, the whole endeavour is rendered futile. However, you can save your time and efforts by installing an Exchange database recovery software, such as Stellar Repair for Exchange for faster, easier, and complete database recovery without any risk of data loss.