Recovering from Database Corruption in Exchange 2007 with LCR enabled
Two nights back I received that dreaded call that inevitably comes late at night & bears the bad news of sleeplessness along with it. One of my clients had power problems in their data centre & their primary Exchange Server had fallen over, well the database servicing the largest number of clients had some corruption & just would not mount no matter what!
Fortunately, our company is currently evaluating Webex Remote Support which meant that I was able to assist my client from home. (I highly recommend this tool, it is safe, secure & reliable).
Once the session was setup, I ran all the standard checks against the database & came up with a strange error (something about the database page sizes being inconsistant). At this point it became obvious, the dreaded ESEUTIL /P or Database Restore from Backup was necessary to recover..... Or was it?
See the thing is, we implemented LCR when we deployed Exchange 2007 for the client, and along with that came a strict SLA with a Call to Repair time of 6hrs.
Now at the time this was all sold on concept, we understood the technology, how it works, the point of having it implemented etc. So we went ahead with the SLA along those lines. I knew I had to stick with in this SLA & ensure the clients server was running within the shortest possible time if I were to get some sleep that night.
The solution implemented? Well I ran two simple EMS Powershell cmdlet:
Restore-StorageGroupCopy -Identity "Server\StorageGroup" -ReplaceLocations:$True -Confirm:$False
Mount-Database -Identity "Server\StorageGroup\Database"
With-in 20 Minutes, from time of session start to time of completion, I had recovered the functionality of their Exchange Server & ensured the integrity of their data without having to resort to Eseutil or Backup.
Note: The Restore-StorageGroupCopy cmdlet breaks the LCR Replication for the storage group. As such you need to manually enable reverse LCR after running the cmdlet.
Fortunately, our company is currently evaluating Webex Remote Support which meant that I was able to assist my client from home. (I highly recommend this tool, it is safe, secure & reliable).
Once the session was setup, I ran all the standard checks against the database & came up with a strange error (something about the database page sizes being inconsistant). At this point it became obvious, the dreaded ESEUTIL /P or Database Restore from Backup was necessary to recover..... Or was it?
See the thing is, we implemented LCR when we deployed Exchange 2007 for the client, and along with that came a strict SLA with a Call to Repair time of 6hrs.
Now at the time this was all sold on concept, we understood the technology, how it works, the point of having it implemented etc. So we went ahead with the SLA along those lines. I knew I had to stick with in this SLA & ensure the clients server was running within the shortest possible time if I were to get some sleep that night.
The solution implemented? Well I ran two simple EMS Powershell cmdlet:
Restore-StorageGroupCopy -Identity "Server\StorageGroup" -ReplaceLocations:$True -Confirm:$False
Mount-Database -Identity "Server\StorageGroup\Database"
With-in 20 Minutes, from time of session start to time of completion, I had recovered the functionality of their Exchange Server & ensured the integrity of their data without having to resort to Eseutil or Backup.
Note: The Restore-StorageGroupCopy cmdlet breaks the LCR Replication for the storage group. As such you need to manually enable reverse LCR after running the cmdlet.
Comments