Exchange 2007 DBs inconsistent in Recoverpoint

You may be right. That's why I started posting. To see if anyone else was doing something different. I'll open a ticket. THANKS EVERYONE!!

Drozz,

Agree with you, application consistent should is not  required and the tighter your RPO the less feasible they are.  I believe the dirty shutdown is confusing , in reality all shutdowns except a VSS or controlled shutdown is dirty, the error message you are getting is beyond just a dirty shutdown and is indicating corruption of some sort. kutils is not needed on the server if you are not using vss to get application consistent, so this will not help you to install. I suggest you open a ticket and let support take a look at it.

Are you sure you have the appropriate DB and logs in the same CG?

-rick

Are they all in the same Consistency Group in RP?

I have not. I will check it out and also open a ticket. I'll reply back with what I find out. Thanks

drozz,

Have you looked at the following white paper?

Improving Microsoft Exchange Server Recover with EMC RecoverPoint

Page 9 discusses recovery options for Exchange and reiterate that the data will be crash consistent unless an application aware utility is used in addition to RecoverPoint. How long does it take to recover the database in Exchange 2010 using the replicas? I assume it is successful but just takes some time?

Aran

Also please look at the latest  RecoverPoint Technical Note which covers Exchange 2003, 2007 and 2010.  You can find it on Powerlink and it was revised to contain detailed information on protection and recovery for Exchange 2010.  The version you want is P/N 300-004-904 REV A04 Dated May 2, 2010

drozz,

Here is the link to the docuemnt:

https://powerlink.emc.com/nsepn/webapps/btg548664833igtcuup4826/km/live1/en_US/Offering_Technical/Technical_Documentation/300-004-904.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tDb250ZW50RXZlbnQsZG9jdW1lbnRJZD0wOTAxNDA2NjgwNGVkZGEyLG5hdmVOb2RlPVNvZndhcmVEb3dubG9hZHMtMQ__

The section on Exchange 2010 starts on page 65. Does this help any?

EDIT:

Looks like there are some detailed steps when performing a recovery of a 2010 DB and it does cover a crash consistent 'dirty shutdown' scenarion which is what you are using.

Message was edited by: AranH

Oh man, you're not going to give us the answer? We actually have to go read it?

Gentleman, after working in detail with the exchange team, turns out our public folders are in Storage Group 2 which they did not create on the DR side. What this did was changed the log file prefix every database was looking for by 1 (E03 was looking for E02 and so on). So DB1 would mount fine, DB3 through 13 would not. Once this was changed BLAMMO...up and running with no issues. They created an empty spot for DB2 to hold the prefix numbers in line.

Thanks for all the help and documentation! Hopefully this will help someone out in the future and this was very helpful for me

Thanks for the update Drozz.  I suspected this might be a configuration issue.  typically when we see some corruption issue it is because either a host has access to the data luns outside of RP's view or we do not have our luns mapped correctly.