A newly released “flash” with a collection of information about Multi-site Data Replication and Exchange:

The Exchange Product Group has received numerous queries regarding deploying Exchange in a Multi-site/data replication environment. In order to respond to those queries, we have published a white-paper on deployment guidelines and a Knowledge Base article outlining support policies. The purpose of this posting is to increase the awareness of the white-paper and the KB article, and answer some common questions on this topic.

Microsoft Exchange does not encourage nor discourage customers from deploying asynchronous data replication solutions. It is a business decision to choose how to achieve data redundancy and the tolerance for potential data loss. However, before making data replication technology decisions, customers should be clearly informed about the suitability of the technology for the intended purpose. The white-paper and the KB article contain information that may be useful to customers in making such determinations. This is general information, however, and customers should contact vendors to obtain more specific information. .

For example, consider the issue of replication write ordering. As a general guideline, Microsoft advises that it is critical to preserve correct write ordering. With regard to a specific solution, it is the customer’s responsibility to get assurance from the vendor that this requirement is met. Customers must also be aware of the support boundaries between Microsoft and the third party vendors.

Testing should be done in each of these categories:

• Storage Reliability: At the least, common hardware failures should be simulated. If the data is replicated asynchronously, then testing should include verification of the replicated databases after simulating sudden primary storage failures. The goal of this testing is to find out any caveats which may cause data corruption.

For example, one issue that has been seen with some solutions is that replicated data may be stored in a cache at the primary site but is not immediately transferred to the replication site. When the cache becomes full; it may convert the data changes into a bitmap, and lose the time stamp and ordering for each data write. This could potentially lead to data corruption if the full bitmap is not updated on the remote site after a failure.

• Performance: The majority of data replication solutions have occasional or steady performance impact experience and overhead. Careful testing is required to validate that the solution provides acceptable end user performance in both average and peak load conditions. This is applicable to both synchronous and asynchronous environment. Synchronous solutions typically have larger impact than asynchronous solutions. However, if insufficient cache or improper links are used in the solution design, asynchronous replication can also produce poor performance results.
• Backup strategy: The importance of having a backup plan in addition to data replication is explained in the white-paper. The testing is to ensure their backup plan is adequate and the storage is designed to support such plan.
• Disaster Recovery plan: Replicating data is only the first step in a disaster recovery plan. It is necessary to have a disaster recovery plan that describes step by step how to bring the replicated data online in the time window defined by your SLA.

There are a couple of tools developed by Microsoft Exchange team which can be used to perform the testing mentioned above.

When discussing data replication, both the white-paper and the KB refer to "hot" data. I.e. the data being replicated is also being accessed by the Exchange application.

Cold data refers to data has committed to the disk locally and is not being accessed by the Exchange application. e.g. The data has been backed up using VSS or streaming backup software. There are solutions provided by third party vendors which replicate cold data asynchronously to a secondary site. The benefit of such solution is to provide a second copy of the data for a standby DR solution.

Microsoft Exchange supports the replication or copying of "cold" data, provided that the Exchange data was backed up using a supported backup methodology. For example, if the database is backed up using VSS, the VSS solution must comply with KB.822896.

Yes. Geo-clustering provides site resiliency, but not cold data recovery and retention. Having an adequate backup plan allows you to restore the database to a past point in time. This may be necessary to meet legal requirements, to recover inadvertently deleted data or to recover from a database corruption.