Lossless Exchange Recovery using StorageCraft or other Imaging Backup Software

As an avid proponent of image-based backup products like StorageCraft, I became frustrated with their "recommended" procedure to recover a corrupted Exchange database. Microsoft Exchange has the ability to perform a "lossless" recovery of the mailbox database, where the system "replays" a series of log files to rebuild missing data after recovery from backup. In effect, you could theoretically restore the database from several days before and still lose no data at all.  

While this article is targeting admins of Exchange 2010 and later, the functionality dates back to Exchange 5.5, and while some file naming conventions may be different in the older versions, these steps should be generally applicable to earlier versions of Exchange. While Microsoft's built-in Windows backup (Server 2008 and later) supports this lossless recovery in a single step without requiring any special considerations or even knowledge of what happens behind the scenes, many IT admins have adopted more powerful (in other ways) backup software that does not "talk" to Exchange while recovering, which breaks this process if certain steps are not performed. These systems are sometimes referred to as "offline" backup systems, and while there are a great many excellent features of image-based backup systems like StorageCraft, recovery of Exchange requires some additional consideration to prevent data loss. 

The documentation for StorageCraft and other offline backup software vendors reports they can indeed recover databases like Exchange, but they work from the assumption that there will be data loss, which can be very disruptive to business when talking about lost emails. Even StorageCraft's add-on software for granular recovery only works with the .edb file, and cannot "roll forward" the data since the last database commit. While I have not yet had the privilege of attempting a lossless recovery from a StorageCraft image, knowing how to do this was very important for my disaster recovery plan. 

By scouring the Internet, I confirmed that Microsoft Exchange does still have the ability to replay the log files and rebuild missing data after an offline recovery of the database file, as long as all the files you need are intact, and you recover it the right way. While this procedure may not always work, depending on the database and log file states when backed up, the attempt can be well worthwhile.  

Because this article outlines a "lossless" recovery procedure, keep in mind that taking things further to perform "repairs" on the database would likely take you back into the realm of data loss, so keep in mind that if for any reason this procedure fails, you should seriously consider simply following the standard recovery process outlined by StorageCraft, which is to restore the entire Exchange store directory.

There are two scenarios where this "rolling forward" concept becomes really helpful:

A. You have your backups running only once or twice a day, and the Exchange database crashes at the end of time period, right before the next backup, so a recovery would result in significant data loss.

B. You find the database has corruption but is still running, and you want to restore it to a consistent state without losing data.

So, here is how to perform the lossless recovery of Exchange from an image backup:

1. Please take note of the location of your Exchange database and log files, as it will be important to recover to the same directory. The default location of these files are C:\Program Files\Microsoft\Exchange Server\vXX\Mailbox\Mailbox Database. (XX is the Exchange version). In Exchange 2007, 2010, using the Exchange Management Console you can right-click on the first storage group and go to properties to see the location. In Exchange 2013 and 2016, you can use the following powershell command: Get-MailboxDatabase 0status | select edbfilepath

2.  If Exchange is still mounting, dismount the corrupted data store, and copy or rename the .edb and .stm,  and .chk (checkpoint file)

3. Recover the .EDB, .STM file AND the .chk file, but do not recover any old .log files, leaving all the newer .log files intact

4. You must recover these files to the same, original path

5. Mount the Recovered Exchange store
    a. If the mount fails, the most recent log file is either damaged, or was never renamed, and you must rename the next most recent log “Enn.log” (nn is the next incremental number) if it does not work go to the next step
    b. If you still get an error, you may have to delete the checkpoint file, and it will replay all log files which can take a long time, so here are some commands to make that process faster:
        i. Run the following commend eseutil /mh database_file_name | find /i "Shutdown" twice, once for each file (e.g.,  edb, then stm) which will identify the first and last log files that are required to successfully recover all data without generating a -1216 error. The lowest last consistent value across all databases is the last log and the highest last consistent value is the first log
        ii. Now remove any log files not in the range you determined in step i, delete the checkpoint file, and remount

6. If you are still unable to get Exchange to mount the store, or you successfully mount the store, but determine that the lost data is not recovered, then it is time to either restore the entire mailbox directory accepting the partial data loss, or call Microsoft Support Services to assist you further. Do keep in mind, as mentioned earlier, any "repair" of the data files will likely result in data loss, negating much of the benefit of performing this procedure.