Recover Exchange database (EDB) without log files
Exchange server is a Microsoft email and calendaring service that stores a large number of emails, folders, attachments, and contacts. An Exchange server in a very large enterprise may have TBs of data, and it is important to keep the Exchange server operational to ensure continuous workflow and communication. Exchange server runs on the Windows Server operating system, and it is essential to understand where the server is installed and the components that make it up. When you install the Exchange server in its default location C:\Program Files\Microsoft\Exchange, it creates a database file called database.edb as well as additional log files.
What are Exchange log files and why are they important?
The log files, also known as transaction log files, are required for the Exchange database to function properly. Any changes made to the database are first written to the log files as a temporary buffer to speed up write and read operations before being committed to the database The database is said to be in a 'Clean Shutdown' state when all transactions are up to date. In most cases, the Exchange server can recover data from these log files after restarting. However, in some cases, these log files go missing or they are deleted, resulting in mounting issues for the Exchange database. It is also possible that the database itself becomes corrupted due to physical and logical errors while the entries in the log files have not yet been committed to the database. This situation is commonly referred to as the ‘Dirty Shutdown’ of the database and requires a deep recovery.
Summarizing the preceding points we can briefly say that the user’s mailboxes are stored in the Exchange database file (.edb file) and the transaction details are stored in the log files. Exchange log files are used to prevent data loss as it records all the transactions before they are committed to the database file. This operation is called write-ahead logging and in the case of database failure, the transactions can be recovered when the log files are available.
Common reasons for missing or deleted log files
One of the reasons for missing log files is the abrupt shutdown of the Exchange server or accidental deletion due to hard drive failure. The following are some of the other reasons:
- Sudden or abrupt power loss situation.
- Unexpected shutdown of Exchange server.
- Virus attack resulting in data corruption.
- System hardware or hard-disk failure.
- Faulty server updates or accidental data deletions.
- Oversized log files resulting in corruption.
What happens when Exchange log files go missing?
When Exchange log files are lost before they are committed to the database, the data in the logs is no longer written to the EDB, causing the database to become inconsistent. The Exchange server develops Jet Errors such as JET-Error -533 (0xffffdeb), JET-Error -515 (0xffffdfd), JET-Error -501 (0xffffe0b), and JET-Error -514 (0xffffdfe), and the database fails to mount as a result. You cannot access your mailbox in such a situation you must perform a complete database recovery to recover the Exchange server from Jet Engine Errors.
How to recover an Exchange database without log files?
There are two methods to recover an Exchange database without log files. In the first method, you can retrieve the most recent log files from a backup copy and so that the Exchange server can replay the log files and restore the database to a consistent state. If you do not have a prior backup of the Exchange server data, use the Eseutil utility to repair and remount the database, or use EdbMails Exchange recovery solution to thoroughly repair and convert the EDB file to PST.
Steps to recover Exchange EDB file without log files
To check the status of the database and perform the recovery, you must use the Eseutil tool, which is installed in the same location as your Exchange server. On most systems, this is located in the C\Program Files\Microsoft\Exchange server\bin folder. Eseutil is used for verifying, defragmenting, and recovering the corrupted Exchange database files. It is also important to take a complete backup of the Exchange database file, as well as any log files, and unmount the database before you attempt the recovery operation.
- Step 1: Run the command eseutil/mh to check the database state
- If the status shows Clean Shutdown, you do not need any log files.
- Run the cmdlet Mount-Database -Identity name.edb to directly mount the database to the Exchange server.
- If the state shows Dirty Shutdown, you need the log files to recover the database.
- Step 2: Perform a soft database recovery by replaying the log files
If the database displays Dirty Shutdown, you must perform a soft recovery first. Copy paste the missing transaction log files to the folder in the Exchange server directory and run the cmdlet eseutil/r to replay them to the database.
eseutil /r “log_prefix” /l “path_to_the_folder_with_log_files” /d “path_to_the_folder_with_the_database”
For example, we ran the following command for demonstration purposes. After you run the cmdlet, check your database state again.
eseutil /r E00 /l "C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 1534595733" /d "C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 1534595733"
In case of failure, you may get the following error messages indicating issues with the transaction log files.
Error Number JET Error Description
Error -501 (0xfffffe0b) JET_errLogFileCorrupt Log File is Corrupt
Error -514 (0xfffffdfe) JET_errBadLogVersion Log file generated with different Exchange Server or edition
Error -515 (0xfffffdfd) JET_errInvalidLogSequence Any log file from the sequence is missing
Error -533 (0xfffffdeb) JET_errCheckpointCorrupt Checkpoint file is deleted or corrupt
- Step 3: Perform a hard recovery if the soft recovery fails
- If you do not have the log files and the database remains in the Dirty Shutdown, you must perform hard recovery. This step is also required if the log files are corrupted or have a sequence missing as seen from the Jet errors.
- Run the command eseutil/p ‘Database path’ to hard repair the database
Note: The hard recovery causes permanent data loss if eseutil is not able to recover the data from the EDB. Try this method as the last attempt to recover the database because there is no guarantee that this would work. After this operation, the defragmentation and indexing of the database takes place and the damaged pages are removed from the database.
- Step 4: Defragment the Exchange database and run an integrity check
Run the cmdlet eseutil/d to defragment the database and run an integrity check with the IsInteg tool to scan for any errors. If no errors are found, run the cmdlet Mount-Database -Identity name.edb to mount the EDB to the Exchange server.
Limitation of the Eseutil and alternate Exchange recovery solutions
There are a few things to consider here. When the Exchange log files are missing or the Exchange database is severely corrupted, the only option is to run the eseutil/p command, which should only be used as a last resort. Because this command causes data loss, administrators and IT professionals do not recommend it. You can also recover log files from a previous Exchange backup. However, if the backup is not recent, you may end up losing data due to a date mismatch. In such cases, the best option is to use a professional tool, such as EdbMails, which can restore your database file without the need for transaction logs.
Restore EDB without log files in Exchange 2019, 2016, 2013, 2010, 2007 and 2003
EdbMails is Microsoft-partnered Exchange recovery software that can repair and convert EDB to PST from Exchange 2019, 2016, 2013, 2010, 2007 and 2003. It can fix Exchange server problems, database corruption, and mounting issues by recovering offline, disconnected EDB files without connecting to an Exchange server. You can export mailboxes from EDB to Outlook PST format or directly migrate EDB to Office 365 or to another Exchange server.
EdbMails, unlike Eseutil, does not require any transaction log files to recover your data. It completely recovers and restores your EDB file to its previous working state when your database failed to mount or entered the Dirty Shutdown state. It also allows you to view the entire EDB file a, preview specific items, and easily migrate/import all of your data without the need for any technical commands.
Steps recover and migrate an EDB file without Exchange log files
- Step 1: Download and install
After you install the software setup, click Start Your Free Trial. You can also directly log in to the application with your registered email address. In the recovery method, select EDB to PST. EDB to Exchange and EDB to Office 365.
- Step 2: Select the offline or corrupted database file (.EDB) that failed to mount
EdbMails can recover any type of EDB files including STM, pub.edb, priv.edb and EDB files from older versions of Exchange such as 2003 and 2000. You can completely recover mailbox data from an Exchange server crash without requiring the log files.
- Step 3: Select the mailboxes and mail items and migrate to another Exchange server
Select the mailboxes that you wish to export or migrate and click 'Migrate to Live Exchange'. You can also export the mailboxes to Outlook PST or migrate to Office 365. Follow the steps to connect to the Exchange server, map the mailboxes and start the Exchange migration.
This method allows you to restore your Exchange server data immediately without any downtime and is far more reliable than other manual methods that result in data loss. EdbMails keeps the exact folder hierarchy and data formatting of the source EDB file without modifications and supports mailbox migration to Exchange 2010, 2013, 2016 and 2019.
