Merge corrupt database to clean database
Hello Experts, recently we have had some corruption issues in our exchange database. After running a defrag and isinteg we still have not been able to shake the corruption. We have devised the plan bellow to merge to a clean database. Please review and hopefully you will concur that this will successfully clean the database or if you foresee any issues with this plan please reply.
1. Copy the FSG database from our active (online) exchange server to a temporary (offline) exchange server
2. Create a new database on that temporary exchange server and mount that new database to the FSG on the temporary server
3. Mount the database copied from the active server to the recovery group on the temporary server
4. Merge/Export all mail from the database mounted in the RG to the database mounted in the FSG on the temporary server
5. Once step 4 is complete, dismount the database in the FSG on the temporary server and copy it off to the active server
6. Dismount the database in the FSG on the active server and mount that database to the recovery group
7. Stop all SMTP services on the active exchange server to avoid new mail from flowing
8. Mount the copied database to the FSG on the active exchange server
9. Merge all mail from the database in the RG to the database in the FSG on the active server
10. Restart all SMTP services
This theoretically leaves us with a new un-corrupt database. The idea here to is reduce the exposure to the users and to reduce downtime.
If we don’t follow the procedure we will have users without their old mail for however many days it takes to merge the mail from the old database to a new one on the active server. All while mail is flowing into the new database we create.
The question left remaining for us:
Since the majority of the mail in the database mounted to the RG is already in the database mounted to the FSG, will that mail be duplicated when we merge those two databases?
Or will only the new mail that has been added to that database be merged?
If this is not clear enough feel free to post with any questions.
Thank you...
1. Copy the FSG database from our active (online) exchange server to a temporary (offline) exchange server
2. Create a new database on that temporary exchange server and mount that new database to the FSG on the temporary server
3. Mount the database copied from the active server to the recovery group on the temporary server
4. Merge/Export all mail from the database mounted in the RG to the database mounted in the FSG on the temporary server
5. Once step 4 is complete, dismount the database in the FSG on the temporary server and copy it off to the active server
6. Dismount the database in the FSG on the active server and mount that database to the recovery group
7. Stop all SMTP services on the active exchange server to avoid new mail from flowing
8. Mount the copied database to the FSG on the active exchange server
9. Merge all mail from the database in the RG to the database in the FSG on the active server
10. Restart all SMTP services
This theoretically leaves us with a new un-corrupt database. The idea here to is reduce the exposure to the users and to reduce downtime.
If we don’t follow the procedure we will have users without their old mail for however many days it takes to merge the mail from the old database to a new one on the active server. All while mail is flowing into the new database we create.
The question left remaining for us:
Since the majority of the mail in the database mounted to the RG is already in the database mounted to the FSG, will that mail be duplicated when we merge those two databases?
Or will only the new mail that has been added to that database be merged?
If this is not clear enough feel free to post with any questions.
Thank you...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
No response was given to my follow up question...
Sorry Ckabs for not answering your follow up question. I missed this..
As you mentioned, if you move the mailbox to different server, users may lose connection. To avoid this you have to schedule to mailbox move on off business hours and also reconfiguring the outlook profile in needed.
what you planned? appears you have fixed it.
As you mentioned, if you move the mailbox to different server, users may lose connection. To avoid this you have to schedule to mailbox move on off business hours and also reconfiguring the outlook profile in needed.
what you planned? appears you have fixed it.
ASKER
There are 2 problems with using your method,
1. We do not have Exchange Enterprise
2. Even if we stood up a Enterprise server elsewhere or upgraded, we would benleft with the issue that while we are copying users loose access to their old mail
Even utilizing cached exchange mode would present the issue of, if thee users close outlook they will only have access to their old mail in offline mode.
Correct me if im wrong here.
P.S. Our database is already past the 75GB limit for Standard.