Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Granular Restore after Exchange DB defrag

Created: 02 May 2012 | 3 comments

I am looking to perform an offline defrag on our Exchange 2007 mailbox database.  When performed, this will create a temporary file which will (at the end of the successful process) replace the existing mailbox database.  While I am happy to perform the defrag, I am concerned that I will not be able to restore any backups that were created prior to the defrag - due to the 'new' mailbox database file.

Can anyone advise on this?

Comments 3 CommentsJump to latest comment

Colin Weaver's picture

Doesn't that process leave all the storage details the same and just replaces the background DB file(s) with one(s) of the same name - so BE won't even know it is different for the GRT restore and as such the restores should stil work.

Redeem's picture

from msexchange.org:

Offline degragmentation creates a new mailbox database with new signatures and so on. Therefore, it is no longer possible to recover data from earlier log files. You have to create a new full backup immediately after performing an offline defragmentation using ESEUTIL!

If exchange itself cannot recover data from it's own log files, can BE restore to the new file?

Colin Weaver's picture

BE mounts the copy of Exchnage that it has in your B2D location and plays the log files (in that copy) as part of the mount and then extracts the individual messages out of this mounted copy and writes it back into your live database as an EWS/MAPI request - so against the Exchange server itself we do not touch the log files directly ourselves for a GRT restore as we are in effect doing the same thing an Outlook user does when he creates a new mail message. If using tape we stage the Exchange information to disk and then do the mount from the staging location.

Also if you were looking at a complete DR restore from before your defrag - then we would obviously put back the time matched database and log files so no problem there either.

EDIT: of course if you are doing incremental backups then you must follwo teh defrag with a full backup as otherwise your next eincremental backup will have problems, but this should not affect the restore.