[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 750
  • Last Modified:

Exchange 2007 DPM Recovery

I did a test restore today of (2) of our Exchange databases from the DPM backups to a network share. I then ran an eseutil /mh to check the status of the recovered edb files and both came back in dirty shutdown state. Is this reason for concern? I was hoping I might use this to validate that the backups are good, but the utility is telling me they are missing the last 3 log files.  Given that it says all logs were committed for both databases, per the report below  is this an issue? Really hoping there is some part of the automated recovery that addresses this or that its a phantom error. Results for both databases follow:

         Database: e:\dbmail0.edb

        File Type: Database
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,12
 Engine ulVersion: 0x620,12
Created ulVersion: 0x620,12
     DB Signature: Create time:10/01/2008 12:02:09 Rand:3688374 Computer:
         cbDbPage: 8192
           dbtime: 23285689 (0x1634fb9)
            State: Dirty Shutdown
     Log Required: 65041-65043 (0xfe11-0xfe13)
    Log Committed: 0-65043 (0x0-0xfe13)
   Streaming File: No
         Shadowed: Yes
       Last Objid: 6754
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00
 Old Repair Count: 0
  Last Consistent: (0x3,A,43)  12/21/2008 11:48:22
      Last Attach: (0x5,9,86)  12/21/2008 11:48:22
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00

         Database: e:\dbmail2.edb

        File Type: Database
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,12
 Engine ulVersion: 0x620,12
Created ulVersion: 0x620,12
     DB Signature: Create time:10/01/2008 12:02:26 Rand:3734096 Computer:
         cbDbPage: 8192
           dbtime: 120482663 (0x72e6b67)
            State: Dirty Shutdown
     Log Required: 373244-373248 (0x5b1fc-0x5b200)
    Log Committed: 0-373248 (0x0-0x5b200)
   Streaming File: No
         Shadowed: Yes
       Last Objid: 74046
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00
 Old Repair Count: 0
  Last Consistent: (0x1EE1D,98,16D)  12/21/2008 13:54:28
      Last Attach: (0x1EE1F,9,86)  12/21/2008 13:54:28
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00
0
edierks
Asked:
edierks
  • 7
  • 4
1 Solution
 
sandeep_narkhedeCommented:
Correct, you need three log files for your database to come in to 'Clean Shutdown" state. these log files are
0xfe11 to 0xfe13. search for these log files & ensure they are in the right path.

while you were restoring, did you  not choose to restore the log files? your Online backup will always consist of the database + log files that the database would require to come in a consistent state.

These log files are generally placed in the temporary location which the restore wizard prompts you.
0
 
edierksAuthor Commented:
Sandeep -
Since we don't have a test environment, I just  did a flatfile recovery of the DB and logfiles to a server that we were using for migration from Groupwise, which has EMC and powershell on it and ran the eseutil against the DB.

I've got the logfiles, just puzzled as to why DPM would have a backup of the database in "dirty shutdown" state. I know I have this restored in a manner pretty far removed from what an actual recovery would be, but need to understand if something is misconfigured or if this is what its supposed to do. Given its using VSS, it sorta makes sense that not all logfiles would be applied since its a point in time copy and, conceivably, at the point in time the DB was copied there could be logfiles pending.
0
 
edierksAuthor Commented:
For what its worth, this is what I did (hope it might help someone else):
Went to C:\Program Files\Microsoft\Exchange Server\Bin>
Ran the following command: eseutil /r E02 /a /d e:\  /Le:\sgmail0logs

      The database log files in this example are in the folder e:\sgmail0logs
      The switch /L tells eseutil the path to the logfiles

      The checkpoint file is the first file in the logfile folder  in this example E02
      The name of the checkpoint file should immediately follow the recovery switch (/r)

      The database in this example is  in e:\
      The switch /d tells ese the path to the database

Eseutil /mh showed both in "clean shutdown" state after the process completed, so I'm assuming I've got mountable backups at this stage.  

On my 40 GB database it took about 4 minutes to complete/ on by 120 GB database it took around 20 minutes.
0
Efficient way to get backups off site to Azure

This user guide provides instructions on how to deploy and configure both a StoneFly Scale Out NAS Enterprise Cloud Drive virtual machine and Veeam Cloud Connect in the Microsoft Azure Cloud.

 
sandeep_narkhedeCommented:
yeah ..you should monitor event id 301 in application logs that tells you which log file is being currently committed to the store, but glad you got this squared away.

your question about why the database was backed up in "Dirty Shutdown" is because its supposed to be that way, if you are doing an online backup. If you dismount the stores gracefully then only you have all log files commited to the database before the database dismounts. i hope that clarifies your question...

Let me know if you need more info about something specific
0
 
edierksAuthor Commented:
Thanks again Sandeep!
One last issue I ran in to. I completed the recovery process and everything was in "clean shutdown" state - per eseutil /mh. Since this is just a test, I ran the integrity checker against the database (eseutil /g)and it threw back the message: Operation terminated with error -1206 (JET_errDatabaseCorrupted, Non database file or corrupted db) after 2183.140 seconds. Could this similarly be related to either the order that I'm performing these operations in or the environment I'm doing it in - or am I running with no good backups?
0
 
sandeep_narkhedeCommented:
did you make sure your database were brought offline when you tried to run the integrity check? , the -1206 definately means corruption, but only if the 1st is false.

you probably do not have a good backup , could you try restoring another set of your backup tapes & see what results you get?
0
 
edierksAuthor Commented:
The databases are on a totally different/non-exchange server, so they are definitely offline. I'm going to do the same checks against the others databases and see what results and then try a set from another day. The most disturbing thing is I've got nothing in the event logs or any errors on the DPM console itself.....
0
 
edierksAuthor Commented:
Opening a case on this - hoping its just something I'm doing wrong. Will update this post with the results. If its not me, this will definitely be strike 3 for DPM....
0
 
edierksAuthor Commented:
Second database is in "clean shutdown" state as well - eseutil /g says its corrupt though.
0
 
sandeep_narkhedeCommented:
thats strange ..you need to review your backups then
0
 
edierksAuthor Commented:
Thanks Sandeep!
0

Featured Post

Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

  • 7
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now