I had a customer recently that called saying his Network Attached Storage (NAS) device had crashed and now his Exchange Priv.edb was missing. He tried running checkdisk on it, tried several undelete and file recovery programs with no luck. The weird thing about it was that viewing the properties of the drive letter under windows showed 140 GB in use even though the only other file on the drive was the Priv.stm streaming file which was 60 GB in size.

Luckily for me that it was a network drive, only had one other file on it and had not be written to since the crash. If any data had been written to the drive after the fact the file disappeared, data recovery may have not been possible.

How I ended up fixing it was to use a hex editing piece of software (I happened to use Winhex, though there are others that would work as well) that allowed opening up the drive to view the raw data. I located the file that was already visible on the drive (the .stm file) to be sure I knew what the header looked like so as to not mistake it for the .edb I was looking for.

An Exchange Priv.edb file is made of pages exactly 4096 bytes in length, the header of the database is shadowed so there will be another 4096 bytes identical to the first right after it.

I located what I thought was the header of the Priv.edb and marked the beginning of it, then I counted down about 8 pages (around 32KB) and marked the end of the 8^th page and wrote it to a file (on a different drive of course!) called Priv-Temp.edb. At that point I was able to run eseutil /mh (dumping an exchange header) on my little temp .edb file. I could then verify that it was the correct Priv.edb file I was looking for based on the information provided by the header dump.

Then remembering that windows showed 140 GB in use and knowing the .stm file was only 60 GB, I counted down from the start of the header 80 GB and marked the end, and wrote that data to a file (on a different drive) called Priv.edb and copied over the existing Priv.stm. I used a calculator to make sure my file was perfectly divisible by 4096, it was not. I looked at the end of my new file and trimmed away the excess data I had grabbed so the file would be perfectly divisible by 4096 (the page size).

This was the first time I had done a recovery like this, so I was not very optimistic about it working. We tried to mount the database and SURE ENOUGH it mounted! Even if it had not mounted, other steps I could have taken would have been to run eseutil /p on my new data file, or I could have used other Exchange specific data recovery tools to extract the mailboxes from my created Priv.edb file.

Well, thank you for reading this, and once again if anyone has any questions you can email me at exchangesupport@dtidatarecovery.com

Tags: Email Recovery Exchange Disaster Recovery Exchange Recovery