Windows Server Backup restore of DAG db will not recover using ESEUTIL /r to alternate loc

Status
Not open for further replies.
J

Jason Trimble

Setup: I have a 5 DB DAG over 2 servers. I have created a backup script that ensures all databases are located on the local server then fires off wbadmin.exe to backup 3 out of the 5 volumes. The backup completes fine.
Scenario: Restore databases to an alternate location where I run ESEUTIL /mh on them to see they are in dirty shutdown state, so now I want to recover them to make them consistent. So I try to run ESEUTIL /r with the appropriate options for log prefix, location and database location.
Problem: I get an error with the recovery saying the following:
Operation terminated with error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info)
Now it appears that it wants the database to be in the original location before a recovery can be performed. Why? How am I supposed to restore this database to an alternate location if I can't recover it properly?
I was only able to make the database consistant by doing an ESEUTIL /p to repair the database which ignores the log files. This just doesn't seem right.
Am I doing something wrong here? Am I missing something or is this the recommended Microsoft method for restoring databases using Windows Server Backup?
Thanks,
Jason
 
J

Jason Trimble

I get the error:
Recovery has indicated that there might be a lossy recovery option. Run recovery with the /a argument.
If I run it with the /a switch I get the same error.
 
M

Martin Chisholm -



Can you paste the entire eseutil cmd-line you used?

It should be something like
eseutil -r e12
and also have the -l, -s, and -d options.

-martin

Legal Stuff: This posting is provided "AS IS" with no warranties, and confers no rights.
 
J

Jason Trimble



Here is my session:

[PS] V:\restore\j_\db3\logs>eseutil /r e03 /dv:\restore\j_\db3\data\db3.edb /a /i Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating RECOVERY mode... Logfile base name: e03 Log files: <current directory> System files: <current directory> Database Directory: v:\restore\j_\db3\data\db3.edb Performing soft recovery... Restore Status (% complete) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... Operation completed successfully in 0.406 seconds. [PS] V:\restore\j_\db3\logs>eseutil /mh v:\restore\j_\db3\data\db3.edb Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating FILE DUMP mode... Database: v:\restore\j_\db3\data\db3.edb DATABASE HEADER: Checksum Information: Expected Checksum: 0x1d0f18c1 Actual Checksum: 0x1d0f18c1 Fields: File Type: Database Checksum: 0x1d0f18c1 Format ulMagic: 0x89abcdef Engine ulMagic: 0x89abcdef Format ulVersion: 0x620,17 Engine ulVersion: 0x620,17 Created ulVersion: 0x620,17 DB Signature: Create time:02/18/2010 10:52:18 Rand:684468994 Computer: cbDbPage: 32768 dbtime: 17847 (0x45b7) State: Dirty Shutdown Log Required: 790-790 (0x316-0x316) Log Committed: 0-791 (0x0-0x317) Log Recovering: 0 (0x0)

As you can see, the database still shows dirty shutdown state. Logs are in the current directory so I have not specified the locations on the command line.
 
J

Jason Trimble



This is very strange. I just tried a restore on my production box and the same commands I'm using on my lab server is working fine in my production environment. Not sure I can explain the abnormality. The difference in the two environments that the backup LUN in lab is a VMDK and in production it is a SAN direct mapped LUN.
 
Status
Not open for further replies.
Top