Solving a problem with Exchange transactional logs after a blackout

The transaction logs were stored on hardware‑mirrored drives. On Friday, a full backup was created to tape. On Monday, a blackout during a storm destroyed the mirror containing the transaction logs. The Information Store service crashed, and the transaction logs did too.

Fortunately, the hardware vendor supplied new disks for the broken mirror with recovered data. The local admin created a RAID without the recovered transaction logs and ran the Information Store (IS). IS created new Transactional logs with a new signature ID. Because the database signature was not the same as the signature of the Transaction logs, the database mount failed. The recreated E00.log file had this signature:

Create time:07/10/2007 16:39:06 Rand:10601899 Computer:

Then a nervous admin ran a restore of the database from Friday, which failed with:

ESE 457 Information Store (3872) Restore0001: The log signature of the existing logfile E00.log doesn't match the logfiles from the backup set. Logfile replay cannot succeed unless all signatures match. ESE BACKUP 904 Information Store (3872) Callback function call ErrESECBRestoreComplete ended with error 0xC8000262 Existing log file has bad signature. ESE BACKUP 903 Information Store (3872) Restore from directory J:\temp\First Storage Group ended with error (Existing log file has bad signature.)

The database had a different signature:

Create time:07/18/2006 18:11:09 Rand:3433931 Computer:

In the “Restore Temporary Path” folder (J:\temp\First Storage Group) the restore left the files restore.env and E004f29.log. I checked the signatures of all databases and logs and saw that the recreated transactional log E00.log was incorrect. Microsoft reported a similar error in KB299000 — “You cannot mount a database after an online restore operation”, but with a different description for Event 903:

ESE BACKUP 903 Information Store (3368) Restore from directory q:\tmp1\SG01 ended with error (Error returned from an ESE function call (-610).

I had to delete the recreated files E00.log, E00.chk, etc., and re‑run the database restore. After that, the problem was resolved.