Search This Blog

Wednesday, October 6, 2010

Exchange 2007 Mailbox Disaster Recovery

Recently I have been called by a Software Provider to help them with their failed Database mount issue.

Setup:
Exchange 2007 SP 2, SCR
SCR: Replication has been disabled. SysAdmin carried out some activity and has disabled the SCR replication
One of the exchange DB's has went down.
Backup: Available for all expect this one as it was being skipped due to some issues.

So here is what we have done in order to bring the Exchange DB online

First Copied the original Db1.edb file to a separate location. Just in case
Checked the consistency of DB using eseutil

Esetuil /mh "location of db.edb file"

State: Dirty Shutdown
Log Required: UncommittedLogSeqNoA - UncommittedLogSeqNoB [usually these will be in hex.dec format something like 0x0000b7ec]

What does this means.

A database is in inconsistent state and has not been detached from the transaction log stream, and it can be mounted only after the appropriate transaction log replay has been performed. After successful replay, the database is detached from the log stream and left in a consistent and mountable state.

Checked the logfile under the TransactionLog folder and fortunately we had the log files. Now next thing was to check the consistency of logfiles itself

We can do that using

eseutil /ml Exx.log

Well so far so good.

Next step is to run a soft recovery since we don't have a valid backup. Sometimes Sys Admin directly jump repair of the db without going through the formal process of soft recovery. Hard Repair should be run with catious understanding the ramification of using it. Simply to put in words you 10gb db can be reduce to 1gb.

Next step
Use esetuil /R Exx /S "location where new chk point will be created"

/r switch is for running soft recovery, basically it will search the existing Transactionlogs and try to replay the logs which are not committed based on Last Log Committed. /s will create a new chk point file in different location other the original chk point file will get overwritten. We wanted to play safe so we had renamed the old check point file.

We can also get last log committed from check point file using eseutil /mk CheckPointFilePath

We got successful replay of the log files and finally we were able to mount the Db

No comments:

Post a Comment