<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Can you have a backup system based solely on snapshots and replication?</title>
		<description>Discuss Can you have a backup system based solely on snapshots and replication?</description>
		<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html</link>
		<lastBuildDate>Fri, 10 Feb 2012 11:22:31 +0000</lastBuildDate>
		<generator>JComments</generator>
		<atom:link href="http://www.backupcentral.com/component/jcomments/feed/com_content/299/10.html" rel="self" type="application/rss+xml" />
		<item>
			<title>Peter Eicher says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-850</link>
			<description><![CDATA[I've had several inquiries about the precise meaning of the statement "snapshot based backups, searchable within nodes" in my last comment. To clarify: BEX backup jobs to the NetApp target are stored as SnapVault snapshots. On the recovery side, the data is viewed via the BEX console from a drive perspective, e.g. the D: drive of a server. The search function works across the full backup history of that drive. So, if I needed all versions of "File-x" across 100 existing backup jobs, I could search through all 100 snaps in a single operation (wildcards are supported). I could also target a specific date range to narrow the search, and/or a file size range. Peter Eicher Syncsort]]></description>
			<dc:creator>Peter Eicher</dc:creator>
			<pubDate>Fri, 19 Feb 2010 13:48:10 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-850</guid>
		</item>
		<item>
			<title>Peter Eicher says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-848</link>
			<description><![CDATA[Curtis, very interesting discussion. Just a quick technical note on NetApp. Syncsort integrates its BEX backup software with NetApp snaps. That is, BEX provides OS agents and leverages SnapVault on secondary storage. This combo gives you: snapshot based backups, searchable within nodes; policy based export of data to tape; application integration (including VMware hooks for P2V and V2V restore); and full backup reporting. Snapshots replicated using SnapMirror can also serve as restore sources for BEX on the far end. I believe this combined solution provides many of those things you list that NetApp lacks. Peter Eicher Syncsort]]></description>
			<dc:creator>Peter Eicher</dc:creator>
			<pubDate>Thu, 18 Feb 2010 15:38:53 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-848</guid>
		</item>
		<item>
			<title>But replicated snapshots are also copies...</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-843</link>
			<description><![CDATA[Note - if you are using volume SnapMirror to replicate to your DR site, you also automatically have all the snapshot copies of the original production filers (up to the last mirror sync), available in your DR filers. If you use SnapVault, you can also keep snaps even further back in history than are still on the prod site. If you declare a disaster and promote DR to production, you still have those snaps to revert to, if needed, as well as any new snaps created while you run the DR filers as prod (depending on DR filer capacity, of course). This has been a real lifesaver to me on a few occasions. Admittedly these snaps are not as "safe" as a third "real" copy elsewhere, but still they are there, just in case. Once you declare a DR, you do still need to protect the DR data that is now prod. Personally, I favor cascading SnapMirror or SnapVault to a 3rd filer, and/or backup to NDMP tapes from DR. Belt AND suspenders. :-)]]></description>
			<dc:creator>Eric Sherrill</dc:creator>
			<pubDate>Thu, 11 Feb 2010 11:58:25 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-843</guid>
		</item>
		<item>
			<title>It\'s all about what you want to pay for</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-840</link>
			<description><![CDATA[Your concern is a valid one. A fourth copy would solve that. Or you can have a third copy with no local copy onsite. (Personally I'd go with the local copy onsite and forgo the fourth copy if I had to make a choice between those two.) Just to stick with the post, however, the fourth copy could still be another "copy," not something on tape or in traditional backup format. It's all about what you want to pay for.]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Mon, 08 Feb 2010 21:49:01 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-840</guid>
		</item>
		<item>
			<title>Rick Lindgren says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-839</link>
			<description><![CDATA[Curtis,	You've put down some really good points to consider regarding whether or not snapshots can be used in place of traditional backups (preferably combined with replication) and how they compare/contrast to the role backup applications typically play. However, there was one point that you didn't discuss, in regards to overall backup architecture, and I was a little surprised to see it wasn't called out as a concern.	In the scenarios you've described, if the primary site goes offline for any reason and you move your operations to the DR site, you are now actively transacting on the array containing the only copy (or copies) of your critical data. You are also doing so in an inherently stressful situation that is prone to missteps. I've always viewed the complete lack of an independent copy of the data at the DR location as a serious flaw in a pure snapshot and replication architecture. I suppose you could have a fourth array deployed with a third replication copy (Primary copy@primary site, HA/BC replication copy@primary site, DR replication copy@DR site, and DoubleDR replication copy@DR site).	I'm curious to hear your stance on whether you feel this simply isn't a valid concern, was overlooked in the original points, or was simply outside the bounds of the original discussion. Thanks.]]></description>
			<dc:creator>Rick Lindgren</dc:creator>
			<pubDate>Mon, 08 Feb 2010 18:30:17 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-839</guid>
		</item>
		<item>
			<title>I only know what I read and hear</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-827</link>
			<description><![CDATA[You have said in your blog that &#34;PIT copies aren't backups.&#34; Scott has said the same in his blog, specifically pointing out SnapMirror and SnapVault. Sales reps have said the same in sales meetings. Here's your blog entry: http://storagezilla.typepad.com/storagezilla/2009/09/are-point-in-time-copies-backups.html In comments in that post you say that PIT copies (aka snapshots) are NOT a replacement for backup -- even if they're replicated off the system. You said that they just &#34;a fast and non-disruptive way of giving you an image to backup.&#34; In a later comment in that same post, you also say not to use RecoverPoint for &#34;months of retention,&#34; which is what I'm suggesting to do in this post. Scott Waterhouse has argued this particular point very vehemently both publicly and privately. When discussing a customer's options in comments on this blog, he said that SnapMirror and SnapVault are &#34;not backup.&#34; http://thebackupblog.typepad.com/thebackupblog/2009/08/something-doesnt-add-up-and-never-will.html (link removed because the article has disappeared. See comment below.) And he blogged about it in detail here: http://thebackupblog.typepad.com/thebackupblog/2009/04/is-a-copy-a-backup.html (link removed because the article has disappeared. See comment below.) And... I was at a very large customer (I say very large only to tell you that the size of this company dictates that they get the best and brightest sales reps EMC had to offer) and they told the EMC sales reps that they wanted to do what I described in this post (90 days of snaps on one celerra replicated to another celerra) and they told the customer that this was the stupidest thing they've ever heard of. &#34;Why?&#34; They asked. &#34;Because it would kill the performance of the Celerra?&#34; &#34;How much?&#34; &#34;We don't know, because no one does that, but I'd guess at least 50%.&#34; As to the customer (&#64;sharney) doing what I described in this blog, he has now explained that he has to snap both source and destination. If he's replicating application data, that's not a valid method of getting a good backup of it. You have to put the app in a backup mode, then snap it. How do you do that with a replica? This is another part of what I meant when I said &#34;EMC can't do snapshots the way NetApp can.&#34;]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Mon, 08 Feb 2010 16:57:03 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-827</guid>
		</item>
		<item>
			<title>Deleted blog posts</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-838</link>
			<description><![CDATA[Scott's posts I linked to above appear to be gone from his site. So I grabbed them from google cache and will quote from them liberally here because I don't want people thinking I'm making things up. In http://thebackupblog.typepad.com/thebackupblog/2009/08/something-doesnt-add-up-and-never-will.html he said: And in http://thebackupblog.typepad.com/thebackupblog/2009/04/is-a-copy-a-backup.html he said this: It seems pretty clear to me that the author of this post believes that backup has to change forms in order for it to be called a backup. By inference, this means that the system I described above does not meet his definition of a backup.]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Mon, 08 Feb 2010 16:54:22 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-838</guid>
		</item>
		<item>
			<title>Mark Twomey says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-837</link>
			<description><![CDATA[Yes, I think we're both on the exact same track we just started out looking out the windows on the opposite side of the carriage.]]></description>
			<dc:creator>Mark Twomey</dc:creator>
			<pubDate>Mon, 08 Feb 2010 09:40:15 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-837</guid>
		</item>
		<item>
			<title>Deleted paragraphs</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-836</link>
			<description><![CDATA[These paragraphs were in the original post. I moved them down here in hopes that future readers will read the main point of the article and not get bogged down in some stuff I really wish I hadn't posted. --- I am aware that the anti-snapshot argument is often proffered by EMC folks and the pro-snapshot argument often comes from NetApp folks. While I'm sure that they all strongly believe what they're saying, it's still a point-of-view that is based partly on where they work. EMC can't do snapshots the way NetApp can -- and they sell some of the backup and reporting software that you might do without if you went down the snapshot-only route. So I highly doubt that there are any training sessions within the Hallowed Halls of Hopkinton about any advantages that such a system might have. Their employees also have no reason to learn the advantages of the other approach. So it's no surprise that anyone that works there would have a dim view of such. On the flip side, NetApp doesn't sell backup software. It doesn't sell backup reporting software. Heck, it no longer even sells a target for traditional backups that I would buy (No, Val, I don't consider FAS w/ASIS a target dedupe system), so they are pretty much out of that business as far as I'm concerned. So they have a vested interest in espousing their point of view as well. Why buy any of that EMC software when you can buy everything from them? Do I have a frame of reference too? Of course. Having worked in hundreds of customers of both approaches, I have seen first hand what they offer, and I still see the merits of both. Usually I am defending the monolithic, central backup software world (as opposed to many, non-integrated point solutions), but today I am arguing that the approach is also valid. I want to say firmly that while the EMC and NetApp guys will interpret this as a pro-NetApp post, I am NOT arguing NetApp over EMC here. I am defending the concept of snapshot-based backups, which the EMC guys are saying is absolute bollocks. (That was just for you, Mark. I could have said &#34;pants,&#34; but I like to see UK/AUS audiences giggle when I throw that word into a preso) Yes, I am well-aware that NetApp is the only major company that is pushing this idea, but there are other companies (e.g. Compellant, FalconStor, Dell) that also go down this route, albeit with less success than NetApp has had. In addition, Microsoft has had quite a bit of luck selling Data Protection Manager. Guess what? Totally snapshot-based. Then, of course, there's Time Machine, Mac OS's built-in backup tool. Also totally snapshot based, although only at the file level. I am not, nor have I ever been, an employee of NetApp, Dell, Microsoft, FalconStor. I don't own stock in NetApp, Compellant, FalconStor, or any other snapshot-based company either. And they're not slipping me cash on the side for these posts. So anyone who wants to accuse me of blogging what I'm blogging because I'm in someone's pocket obviously has no idea who they're talking about. FWIW, I have seen at least two people post on the other side of this issue that aren't EMCers, and they're Preston deGuise (&#64;prestondeguise) and Stephen Foskett (&#64;sfoskett) in his comments on my blog post. I believe that I've addressed both of their concerns in the rest of this post. Feel free to check out their blogs for any anti-responses. They're both people I respect a lot, even if Preston does talk funny and likes to live with Koalas, and Stephen likes to work for San Diego-based companies (where I live) but can't bring himself to move here.]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Mon, 08 Feb 2010 03:56:42 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-836</guid>
		</item>
		<item>
			<title>Sounds like we agree, then</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-835</link>
			<description><![CDATA[@Mark Twomey I honestly have to say that I'm very surprised by your response, and in the end we were mainly arguing about what we thought the other person was saying. It sure doesn't seem to match what I've historically run into when talking EMC folks. Snapshot backup discussions very quickly become discussions about NetApp, and then EMC people start seeing red, so I've never had a snapshot discussion with an EMCer that ended well. Which is all I meant when I started out the post saying that the anti-stuff on this topic often comes from EMCers. I honestly wasn't trying to pick a fight. If I had it to do all over again, I'd take that paragraph out. It's not germane to the discussion. Thanks for the discussion.]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Mon, 08 Feb 2010 03:29:58 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html#comment-835</guid>
		</item>
	</channel>
</rss>

