 




<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Suggestions to improve Exchange Server disaster recovery</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/suggestions-to-improve-exchange-server-disaster-recovery/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/suggestions-to-improve-exchange-server-disaster-recovery/</link>
	<description></description>
	<lastBuildDate>Sat, 25 May 2013 00:24:16 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: dbtk</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/suggestions-to-improve-exchange-server-disaster-recovery/#comment-59879</link>
		<dc:creator>dbtk</dc:creator>
		<pubDate>Thu, 12 Feb 2009 15:21:41 +0000</pubDate>
		<guid isPermaLink="false">#comment-59879</guid>
		<description><![CDATA[In the name of full disclosure I work for Double-Take Software. Clustering is certainly a good solution for high availability and with the improvements with failover clustering it is even better able to help provide disaster recovery by removing some of the previous MSCS requirements like same subnet and 500MS UDP round trip. This can help you distribute the nodes between greater distances but you still have the shared storage requirement. Depending on your disaster recovery infrastructure, do you have a WAN, hotsite or sister office to use as a DR location, you could use host based asynchronous replication or even a hardware based sychronous replication solution that would replicate all changes from one location to another. Typically, in the event of a failure you simply redirect active/directory (automatically or manulaly) to point at that DR exchange server name which once the database is mounted will redirect users to begin using and can be available as little 5-15 minutes depending on how long it takes to mount the exhcnage stores. I know that MS has LCR and CCR functions to in Exchange 2007 that can help provide some features as well.

Those are a few options for Exchange DR.

Hope this helps,]]></description>
		<content:encoded><![CDATA[<p>In the name of full disclosure I work for Double-Take Software. Clustering is certainly a good solution for high availability and with the improvements with failover clustering it is even better able to help provide disaster recovery by removing some of the previous MSCS requirements like same subnet and 500MS UDP round trip. This can help you distribute the nodes between greater distances but you still have the shared storage requirement. Depending on your disaster recovery infrastructure, do you have a WAN, hotsite or sister office to use as a DR location, you could use host based asynchronous replication or even a hardware based sychronous replication solution that would replicate all changes from one location to another. Typically, in the event of a failure you simply redirect active/directory (automatically or manulaly) to point at that DR exchange server name which once the database is mounted will redirect users to begin using and can be available as little 5-15 minutes depending on how long it takes to mount the exhcnage stores. I know that MS has LCR and CCR functions to in Exchange 2007 that can help provide some features as well.</p>
<p>Those are a few options for Exchange DR.</p>
<p>Hope this helps,</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 6/8 queries in 0.012 seconds using memcached
Object Caching 268/269 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-25 04:50:10 -->