Tech

Guides
 

Watch out for this Exchange recovery gotcha

By Scott Lowe, Special to ZDNet Asia
Wednesday, August 23, 2006 10:44 AM
Scott Lowe discusses an actual Exchange recovey endeavor.
In this article, I will discuss how restoring from backup is not always the answer.

Consider this example:

  • You work in a multiple server Exchange environment.
  • One of your Exchange servers, for whatever reason, becomes unstable and backups begin to fail as a result of corruption in one of the databases or log files.
  • Beginning the day the failure is discovered, you begin to move user mailboxes off the afflicted server to another, more stable server. The whole process takes two days.
  • Once the process is complete, you would take a backup of the server, either replace or repair the problem server and move the mailboxes back, but...
  • At the tail-end of the mailbox move process, the server to which you are moving mailboxes suffers a storage problem that renders the Exchange database corrupt.

How would you recover from this situation?

While it doesn't make for a good day, the short answer to the question would be "just restore from backup," right? I'm not going to answer that question, but I am going to throw a serious monkey wrench into your restoration plans: Your restore will be useless.

Yes, useless.

No matter how diligent you are, the fact is that many backup and restore packages, including those from Veritas and Commvault, cannot restore mailboxes from a backup if the mailbox was moved since the backup was taken.

So, how did the organization that was affected by this problem recover from what, for a time, appeared to be a situation for which there would, at the very least, be significant data loss? One option was to go back to a backup that was days old.

However, because this organization is a college, the timing would have meant the loss of important grade information and information about admissions, which is the lifeblood of a college. This would be a worst-case recovery scheme.

Instead, the organization made significant use of a feature included in Outlook 2003--cached mode--which was enabled for most users. Members of the IT staff connected to individual workstations and exported the contents of the users OST file--the Outlook cache information--to PST and copied the PST files to a central network location.

After the PST files were secured, the corrupt Exchange database was archived and sent to a data recovery firm and the database was then manually deleted and automatically recreated empty. All of the individual PST files were then imported into the user’s new mailboxes.

For the few users whose mailboxes could not be recovered in this manner, the data recovery firm was able to extract almost all of the data.

Was it a perfect solution? Definitely not. Was there loss of some data? Very, very little for most users. Importing a PST file does have some drawbacks, such as an increase in the size of the Exchange information store due to the loss of Exchange's inherent single-instance messaging capability. Further, items shared with other users were problematic since the sharing information was lost. Overall, however, users were happier with these drawbacks than with the possibility of losing important information.



WORTHWHILE?

0

0 votes
Blog

Talkback 0 comments

There are currently no comments for this post.


Guest user

Guest user

Level: 
Joined: —
Already a member? Log in »



 

Loading...

Whitepapers/Case Studies

Downloads

Disaster Recovery News



Tech Jobs Now!