Solved

Questions on Exchange corruption

Posted on 2011-09-10
4
227 Views
Last Modified: 2012-05-12
Hi

Environment: Exchange 2007 SP2 on Windows 2008 Server SP2. CCR/SCC clustering in place with SCR.

Example scenario: Due to a driver issue, we recv 10xx alerts on our Exchange servers indicating that there is some corruption within the database. From my understanding, CCR is better in this scenario as the corruption can't be replicated to the passive node due to the Inspector directory. With SCC, on the other hand, there is only one set of data, so my possible options are:

i. Move mailboxes on affected DB to another new DB

ii. Restore from backup

iii. Run ESEUtil /p to hard repair the database (last resort).

I was hoping someone could answer some queries I had on this:

1. Am I correct that most types of data corruption cannot be replicated with CCR/SCR technology. In which case, if the error happened on a CCR cluster, the best option would be to fail over to the passive node.

2. If this happened on an SCC cluster, then the 'move mailbox' idea is the best? However, how can we ensure that we don't carry any corruption across/have any data loss when the mailboxes are moved?

3. If we did decide to use ESEUtil /p, it would be safest to backup the database first. However, I always thought backups would fail if attempting to backup a database that had corruption?

As I mentioned, this is an example scenario.
0
Comment
Question by:wyclef1
  • 2
  • 2
4 Comments
 
LVL 49

Accepted Solution

by:
Akhater earned 500 total points
ID: 36518749
>1. Am I correct that most types of data corruption cannot be replicated with CCR/SCR technology. In which case, if the error happened on a CCR cluster, the best option would be to fail over to the passive node.<
Yes you are totally correct, CCR/SCR should protect from DB corruption and fail to the passive node is the best approach and first thing to try

>2. If this happened on an SCC cluster, then the 'move mailbox' idea is the best? However, how can we ensure that we don't carry any corruption across/have any data loss when the mailboxes are moved?<
You are also correct, if you hare having errors that the DB is corrupted but it is still mounted the reflex should indeed be to create a new DB and move the mailboxes to it. No the corruption will not be carried over with the move operation, typically one or more mailboxes will fail to move and these would be the source of the corruption but at least you would have secured the rest.

 >3. If we did decide to use ESEUtil /p, it would be safest to backup the database first. However, I always thought backups would fail if attempting to backup a database that had corruption?<
if you decide to take ESEUtil /p you should take a copy of the edb file first and not a regular database backup, just a copy of the edb file
0
 

Author Comment

by:wyclef1
ID: 36518761
HI Akhater

Thanks for answering.

For #1, once we fail over the node to the passive CCR and all databases are mounted, is there a command we can run to ensure that the database corruption still doesn't exist?

For #2, is there any recommended switch we need to run with the move mailbox command to ensure that mailboxes with corrupted items are not moved to the new DB? And, I guess if we moved all the non-corrupted mailboxes, then we could take a copy of the EDB and run ESEUtil /p on the database safe in the knowledge that (hopefully) only a few maiboxes would be affected by any data loss, correct?

For #3, sure so we take a copy of the EDB (and transaction log files I guess?) and run ESEUtil /p on it, followed by ISInteg. If we get severe data loss, is it just a question of replacing the repaired DB and log files with the copy we made?

Also, #4, how does Exchange alert for corruption? During online maintenance/ backups only, or will it generate an alert as soon as there is corruption? Apart from the 10## event ID's, anything to look out for?
0
 
LVL 49

Expert Comment

by:Akhater
ID: 36518777
>>For #1, once we fail over the node to the passive CCR and all databases are mounted, is there a command we can run to ensure that the database corruption still doesn't exist? <<
If the DB on the passive node is corrupted you will have entries in the event log about it just like with the active DB, again it shouldn't happen in theory.

>>For #2, is there any recommended switch we need to run with the move mailbox command to ensure that mailboxes with corrupted items are not moved to the new DB? And, I guess if we moved all the non-corrupted mailboxes, then we could take a copy of the EDB and run ESEUtil /p on the database safe in the knowledge that (hopefully) only a few maiboxes would be affected by any data loss, correct?<<
For exchange it is usually not a full mailbox that is corrupted but some items, you could run the move request first with -BadItemLimit 0 and then maybe filter out the less critical mailboxes and increase the bad item limit for those etc... then yes finally do a eseutil /p on the DB hoping that you will be able to recover. Practically speaking, in most cases, I just run BadItemLimit at about 20 and hope for the best unless we are talking about a really very critical mailbox

>>For #3, sure so we take a copy of the EDB (and transaction log files I guess?) and run ESEUtil /p on it, followed by ISInteg. If we get severe data loss, is it just a question of replacing the repaired DB and log files with the copy we made?<<
Once the database is dismounted, the log files are totally worthless, specially with a /p operation but yes it doesn't hurt to copy these too as well.
Usually you keep the edb file copy (that is corrupted) not to replace it instead of the repaired one -with data loss- although you could but more to have different options of repair. For example take a copy of the edb run on it /P and another copy I run on it a edb to pst program for more critical mailboxes and I always keep one safe. Just keep in mind that, if you want to replace an edb with another, that you need to make sure no email gets in or out of the DB during your recovery period.

>>Also, #4, how does Exchange alert for corruption? During online maintenance/ backups only, or will it generate an alert as soon as there is corruption? Apart from the 10## event ID's, anything to look out for?<<
Early sign of corruption will always be in the event log, if they are not noticed in time chances are that some users will start reporting issues like cannot open certain items in inbox etc..




0
 

Author Comment

by:wyclef1
ID: 36519152
Perfectly answered, many thanks!
0

Featured Post

NAS Cloud Backup Strategies

This article explains backup scenarios when using network storage. We review the so-called “3-2-1 strategy” and summarize the methods you can use to send NAS data to the cloud

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Follow this checklist to learn more about the 15 things you should never include in an email signature from personal quotes, animated gifs and out-of-date marketing content.
This article aims to explain the working of CircularLogArchiver. This tool was designed to solve the buildup of log file in cases where systems do not support circular logging or where circular logging is not enabled
In this video we show how to create a User Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >> Mailb…
This video discusses moving either the default database or any database to a new volume.

777 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question