<?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: Recoverpoint vs. Conventional Replication</title>
	<atom:link href="http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/</link>
	<description>Ranting and raving about storage and technology</description>
	<lastBuildDate>Mon, 19 Dec 2011 15:36:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: assaf</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-7597</link>
		<dc:creator>assaf</dc:creator>
		<pubDate>Thu, 14 Jan 2010 14:28:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-7597</guid>
		<description>recover point journal is on the replica site and not on production thus, you claim is about building destroyed is not corret</description>
		<content:encoded><![CDATA[<p>recover point journal is on the replica site and not on production thus, you claim is about building destroyed is not corret</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-7583</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Tue, 15 Dec 2009 00:22:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-7583</guid>
		<description>After reading the EMC docs, this is my current working theory: When not using a host splitter, a switch (e.g. Cisco MDS 9000 with SSM line card) is a part of the  RP (RecoverPoint) solution data path, RP is in the primary data path, along with switch+appliance latency and cost. Turn off either the switch or the RP appliance and storage writes stop. That means that both the RP splitter switch and the RP appliance are in-band to the data path.  This is the host write data path: (1) Host writes to SSM line card, (2) SSM card adds latency by sending a Pending Write Log [PWL] command to the RP appliance and holds up the storage write waiting for a reply. (3) RP appliance acknowleges the PWL to the SSM card. (4) Then, and not until then, the SSM card sends duplicate writes to the storage and the RP appliance. The RP appliance not only adds additional latency, but IS IN THE PRIMARY WRITE PATH.  The SSM line card design includes an ARL - &quot;for the detection of host writes that never reached the RP appliance&quot;, and a PWL - &quot;for the detection of host writes that reached the RP appliance but never reached the storage&quot;.</description>
		<content:encoded><![CDATA[<p>After reading the EMC docs, this is my current working theory: When not using a host splitter, a switch (e.g. Cisco MDS 9000 with SSM line card) is a part of the  RP (RecoverPoint) solution data path, RP is in the primary data path, along with switch+appliance latency and cost. Turn off either the switch or the RP appliance and storage writes stop. That means that both the RP splitter switch and the RP appliance are in-band to the data path.  This is the host write data path: (1) Host writes to SSM line card, (2) SSM card adds latency by sending a Pending Write Log [PWL] command to the RP appliance and holds up the storage write waiting for a reply. (3) RP appliance acknowleges the PWL to the SSM card. (4) Then, and not until then, the SSM card sends duplicate writes to the storage and the RP appliance. The RP appliance not only adds additional latency, but IS IN THE PRIMARY WRITE PATH.  The SSM line card design includes an ARL &#8211; &#8220;for the detection of host writes that never reached the RP appliance&#8221;, and a PWL &#8211; &#8220;for the detection of host writes that reached the RP appliance but never reached the storage&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-6711</link>
		<dc:creator>Jesse</dc:creator>
		<pubDate>Sun, 10 May 2009 19:26:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-6711</guid>
		<description>So it becomes a &quot;You can have it fast, *OR* you can have it reliable&quot; type situation.

That&#039;s fine and dandy, but ethically shouldn&#039;t it be marketed that way?  When i started asking for numbers on latency I thought the Recoverpoint dude was going to burst a seam..  

&quot;No measurable latency&quot; was his basic response...

Sorry, but I can&#039;t buy that for any measurable time increment.  I think it&#039;s more likely that they&#039;ve either never tested it or just never released the results.  Handling data takes time, no matter how you handle it.  Even simply passing an IO through an ASIC can take time, even if it is a fraction of a millisecond, it&#039;s still time, and that time still ads up.</description>
		<content:encoded><![CDATA[<p>So it becomes a &#8220;You can have it fast, *OR* you can have it reliable&#8221; type situation.</p>
<p>That&#8217;s fine and dandy, but ethically shouldn&#8217;t it be marketed that way?  When i started asking for numbers on latency I thought the Recoverpoint dude was going to burst a seam..  </p>
<p>&#8220;No measurable latency&#8221; was his basic response&#8230;</p>
<p>Sorry, but I can&#8217;t buy that for any measurable time increment.  I think it&#8217;s more likely that they&#8217;ve either never tested it or just never released the results.  Handling data takes time, no matter how you handle it.  Even simply passing an IO through an ASIC can take time, even if it is a fraction of a millisecond, it&#8217;s still time, and that time still ads up.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dimitris Krekoukias</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-6709</link>
		<dc:creator>Dimitris Krekoukias</dc:creator>
		<pubDate>Sun, 10 May 2009 00:32:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-6709</guid>
		<description>The other main advantage of recoverpoint is that you can arbitrarily roll back your data, not so much that it efficiently replicates...</description>
		<content:encoded><![CDATA[<p>The other main advantage of recoverpoint is that you can arbitrarily roll back your data, not so much that it efficiently replicates&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-6701</link>
		<dc:creator>Jesse</dc:creator>
		<pubDate>Thu, 30 Apr 2009 20:25:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-6701</guid>
		<description>Sorry for the late response, this got lost in the bit-bucket and I didn&#039;t catch it.

SANCopy on the remote clariion will work, but you&#039;ll need FibreChannel connectivity end-to-end, which might be more expensive than you want.  

Do you own timefinder on the DMX and SNAP on the clariion?  If so, you can buy one copy of SANCopy for the remote, and do pull replications from the sources (snaps)

You can&#039;t do a pull from a hot source (IE from the actual production volumes) because SANCopy isn&#039;t capable of halting the IO remotely to provide a consistency point.

It&#039;s a good alternative, though in your situation I would actually recomend RecoverPoint (and those that know me know I don&#039;t do that lightly) as a single point replication engine.  Otherwise it&#039;s OpenReplicator for DMX--&gt;Clariion and SANCopy or Mirrorview for the Clariion--&gt;Clariion.</description>
		<content:encoded><![CDATA[<p>Sorry for the late response, this got lost in the bit-bucket and I didn&#8217;t catch it.</p>
<p>SANCopy on the remote clariion will work, but you&#8217;ll need FibreChannel connectivity end-to-end, which might be more expensive than you want.  </p>
<p>Do you own timefinder on the DMX and SNAP on the clariion?  If so, you can buy one copy of SANCopy for the remote, and do pull replications from the sources (snaps)</p>
<p>You can&#8217;t do a pull from a hot source (IE from the actual production volumes) because SANCopy isn&#8217;t capable of halting the IO remotely to provide a consistency point.</p>
<p>It&#8217;s a good alternative, though in your situation I would actually recomend RecoverPoint (and those that know me know I don&#8217;t do that lightly) as a single point replication engine.  Otherwise it&#8217;s OpenReplicator for DMX&#8211;&gt;Clariion and SANCopy or Mirrorview for the Clariion&#8211;&gt;Clariion.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-6700</link>
		<dc:creator>Jesse</dc:creator>
		<pubDate>Thu, 30 Apr 2009 20:25:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-6700</guid>
		<description>Sorry for the late response, this got lost in the bit-bucket and I didn&#039;t catch it.

SANCopy on the remote clariion will work, but you&#039;ll need FibreChannel connectivity end-to-end, which might be more expensive than you want.  

Do you own timefinder on the DMX and SNAP on the clariion?  If so, you can buy one copy of SANCopy for the remote, and do pull replications from the sources (snaps)

You can&#039;t do a pull from a hot source (IE from the actual production volumes) because SANCopy isn&#039;t capable of halting the IO remotely to provide a consistency point.

It&#039;s a good alternative, though in your situation I would actually recomend RecoverPoint (and those that know me know I don&#039;t do that lightly) as a single point replication engine.  Otherwise it&#039;s OpenReplicator for DMX--&gt;Clariion and SANCopy or Mirrorview for the Clariion--&gt;Clariion.</description>
		<content:encoded><![CDATA[<p>Sorry for the late response, this got lost in the bit-bucket and I didn&#8217;t catch it.</p>
<p>SANCopy on the remote clariion will work, but you&#8217;ll need FibreChannel connectivity end-to-end, which might be more expensive than you want.  </p>
<p>Do you own timefinder on the DMX and SNAP on the clariion?  If so, you can buy one copy of SANCopy for the remote, and do pull replications from the sources (snaps)</p>
<p>You can&#8217;t do a pull from a hot source (IE from the actual production volumes) because SANCopy isn&#8217;t capable of halting the IO remotely to provide a consistency point.</p>
<p>It&#8217;s a good alternative, though in your situation I would actually recomend RecoverPoint (and those that know me know I don&#8217;t do that lightly) as a single point replication engine.  Otherwise it&#8217;s OpenReplicator for DMX&#8211;&gt;Clariion and SANCopy or Mirrorview for the Clariion&#8211;&gt;Clariion.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: StorageGuy201</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-6688</link>
		<dc:creator>StorageGuy201</dc:creator>
		<pubDate>Wed, 08 Apr 2009 22:36:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-6688</guid>
		<description>Well this is more a question but still on-topic. We have a DMX and a Clariion (tier 1 and tier 2). We&#039;re considering replication to another site (doesn&#039;t exist yet) so we want a single product that will replicate both DMX, Clariion to the secondary storage (perhaps another clariion). We also have a celerra but we could potentially use celerra replicator for that. Unfortunately our budget is small and so both SRDF and recoverpoint are out. We were thinking about building our own rsync based solution but then for DR we want something bullet proof with end-to-end resiliency. I miss my old NetApp days...snapvault or snapmirror turn it on and forget about it - RPO/RTO well within specs but I&#039;m sure SRDF is similar except in my situation I have a clariion to account for too - it&#039;s a shame that while they&#039;re both EMC products they don&#039;t natively talk to eachother.</description>
		<content:encoded><![CDATA[<p>Well this is more a question but still on-topic. We have a DMX and a Clariion (tier 1 and tier 2). We&#8217;re considering replication to another site (doesn&#8217;t exist yet) so we want a single product that will replicate both DMX, Clariion to the secondary storage (perhaps another clariion). We also have a celerra but we could potentially use celerra replicator for that. Unfortunately our budget is small and so both SRDF and recoverpoint are out. We were thinking about building our own rsync based solution but then for DR we want something bullet proof with end-to-end resiliency. I miss my old NetApp days&#8230;snapvault or snapmirror turn it on and forget about it &#8211; RPO/RTO well within specs but I&#8217;m sure SRDF is similar except in my situation I have a clariion to account for too &#8211; it&#8217;s a shame that while they&#8217;re both EMC products they don&#8217;t natively talk to eachother.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-6669</link>
		<dc:creator>Jesse</dc:creator>
		<pubDate>Wed, 18 Mar 2009 05:04:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-6669</guid>
		<description>It&#039;s hard to argue RecoverPoint against something like SRDF or MV when a lot of the stories I&#039;m getting are like that one...  

Bottom line is:

SRDF works.  It just works, there is never a question about it, it&#039;s the backbone product and what makes a Symm uniquely a Symm.

Mirrorview works.  Maybe with a few more gotchas and caveats than SRDF, but it also, once configured, is fire and forget.

When it comes to mirroring technology for DR purposes, I want something that just...works.

Of course I say this as I sit on a customer site waiting for an SRDF script that bombed out at 5 this evening to finish.  Guess that will teach me to run a config change without rebooting the SP&#039;s first.</description>
		<content:encoded><![CDATA[<p>It&#8217;s hard to argue RecoverPoint against something like SRDF or MV when a lot of the stories I&#8217;m getting are like that one&#8230;  </p>
<p>Bottom line is:</p>
<p>SRDF works.  It just works, there is never a question about it, it&#8217;s the backbone product and what makes a Symm uniquely a Symm.</p>
<p>Mirrorview works.  Maybe with a few more gotchas and caveats than SRDF, but it also, once configured, is fire and forget.</p>
<p>When it comes to mirroring technology for DR purposes, I want something that just&#8230;works.</p>
<p>Of course I say this as I sit on a customer site waiting for an SRDF script that bombed out at 5 this evening to finish.  Guess that will teach me to run a config change without rebooting the SP&#8217;s first.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Superstar</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-6668</link>
		<dc:creator>Superstar</dc:creator>
		<pubDate>Wed, 18 Mar 2009 05:00:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-6668</guid>
		<description>Greetings,
We took a look at this a few years back (2 years now?) EMC had quite a time getting it running with our Cisco MDS 9509 switch using their recommended firmware levels throughout the stack. While it eventually worked -- the Firmware on the switch broke other things. Split writes were pretty sweet -- just be sure to get it in house to test before you find it breaks other things!</description>
		<content:encoded><![CDATA[<p>Greetings,<br />
We took a look at this a few years back (2 years now?) EMC had quite a time getting it running with our Cisco MDS 9509 switch using their recommended firmware levels throughout the stack. While it eventually worked &#8212; the Firmware on the switch broke other things. Split writes were pretty sweet &#8212; just be sure to get it in house to test before you find it breaks other things!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Storagezilla</title>
		<link>http://blog.50micron.com/2009/03/17/recoverpoint-vs-conventional-replication/comment-page-1/#comment-6667</link>
		<dc:creator>Storagezilla</dc:creator>
		<pubDate>Wed, 18 Mar 2009 02:36:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.50micron.com/?p=474#comment-6667</guid>
		<description>No problem. I&#039;ve asked all these questions myself hence I have more answers. 

SRDF and MV are not being replaced by RecoverPoint. It fits in places they don&#039;t. They fit in places it doesn&#039;t.</description>
		<content:encoded><![CDATA[<p>No problem. I&#8217;ve asked all these questions myself hence I have more answers. </p>
<p>SRDF and MV are not being replaced by RecoverPoint. It fits in places they don&#8217;t. They fit in places it doesn&#8217;t.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

