One of your primary Exchange servers has just failed, so—just as designed—your system cuts over to its corresponding recovery server. And because your DR solution has been regularly mirroring every last file or block right along to that recovery system, you’ve got nothing to worry about, right?

Wrong. Because there’s a good chance you’ll find that, even though the server is running and all your data is there, Exchange itself isn’t available because it can’t mount the Exchange information stores.

And what would be the reason for that? Data corruption. File and block replication solutions, you see, just go about mirroring everything—corruption and all—without resorting to any sort of data validation. And how often does that become an issue? Well, Meta Group reports that 16% of all server failures are due to database corruption. Draw your own conclusions.

So what now? Your DR solution vendor can claim that its RTO commitment has been met since your recovery server was up within the promised amount of time and all your (corrupt) data proved to be intact. Well, bully for the vendor, but you’ve still got work to do.

It’s possible you’ll be able to quickly remedy the corruption using ESEUTIL. But then again, maybe not. You may end up having to resort to an older backup, doing what you can to reconstruct state from your log files. And while you’re at that exceedingly tedious task, industry norms reported by Meta Group suggest your users may have to find a way to get along without their email for some number of hours—or maybe even days. So you may want to ask yourself: just how patient and understanding are your users anyway?

MailShadow® avoids this mess by employing a transaction-based replication scheme. That is, for each protected Outlook® user, MailShadow acquires from Exchange all email, folder, calendar and contact transactions and then transmits them to the corresponding user mailbox on the recovery server. Each of these transactions then is processed on the live recovery Exchange server just as they are on the primary server, with MailShadow working to ensure in real time that each replicated mailbox is fully synchronized with its equivalent on the primary server.

MailShadow also validates that each transaction is complete and fully formed before transferring it. Which is to say that MailShadow has been specifically designed not to transfer any corrupted transactions so as to avoid propagating bad data to the recovery server.