<?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>How to REALLY analyze dedupe ratios and their impact on cost savings</title>
		<description>Discuss How to REALLY analyze dedupe ratios and their impact on cost savings</description>
		<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html</link>
		<lastBuildDate>Fri, 10 Feb 2012 21:02:17 +0000</lastBuildDate>
		<generator>JComments</generator>
		<atom:link href="http://www.backupcentral.com/component/jcomments/feed/com_content/305/10.html" rel="self" type="application/rss+xml" />
		<item>
			<title>Please understand your backup product and deduplic</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-874</link>
			<description><![CDATA[I have read many items about deduplication ratios and arguments back and forth. What people need to really look at is how it fits how your backup software works and your downtimes. Some technologies needs downtime for cleanup and deduplication process but if you are in a TSM environment you don't have those. Also with more companies going global there are no downtimes so you need to also take that into affect if you use Netbackup and Commvault. Most people I talk to are using a combination of 2/3 products for their needs. I know this give you some extra management but in dealing with the issues a 1 solution would give you it is actually a time saving. Before purchasing a product make sure you understands how they dedup and how you are managing your data or you will be burned.]]></description>
			<dc:creator>ed perez</dc:creator>
			<pubDate>Wed, 07 Apr 2010 11:07:25 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-874</guid>
		</item>
		<item>
			<title>Having cake and eating it too</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-873</link>
			<description><![CDATA[We recently (past 6 months) bought and implemented Avamar with a clean sweep removal of NetBackup and TSM replaced by Networker. Implementing Networker was a BEAR and even after EMC having Avamar in their portfolio for 3 years the integration was kind of shaky. We also are just now purchasing Data Domain boxes to add/complete our backup model. I expect that implementation to be much easier now that Networker is mostly stabilized. In hindsight, I don't necessarily believe that any of the components that we bought are the "best in class" for their particular niche. However, our number one objective was to have the flexibility of source and target dedupe under a single pain of glass. As Mr. Preston mentioned, the type of data you're trying to dedupe is arguably the biggest success factor. We also appended the location of the data as another success factor and we wanted the flexibility to dedupe enterprise wide with the ability to choose where that deduplication occurred. The biggest tip I could share for anyone evaluating or looking to purchase is to not let the sales team set your pain points. If you let them, they will throw out a self-proclaimed "flaw" in a competitors product and launch an entire campaign to educate you on the evils and afflictions that flaw will cause. I think all the laid off Y2K marketing staff found homes at the dedupe vendors. For us, it came down to the simple fact that we were replacing a traditional backup solution to tape, backing up a secondary copy of production data, and we have very minimal retention requirements. Based on that, the differences between "spill and fill", "global dedupe", "Moore's law" and all the other marketing buzzwords were of minimal importance because every product we looked at was faster than tape and used a smaller footprint than D2D. Finally, just like buying a car, the longer you're willing to keep driving your trade in the better the pricing will be especially at the end of a month/quarter.]]></description>
			<dc:creator>Todd Ryan</dc:creator>
			<pubDate>Wed, 07 Apr 2010 09:46:29 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-873</guid>
		</item>
		<item>
			<title>Dedup and backup Benchmark</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-872</link>
			<description><![CDATA[We have all kinds of disk benchmarks. What about dedup benchmark? Not the ones provided by dedup vendors them self but real objective one like Storage Performance. Even if I do not like Storage Performance benchmark because they test SAN storage with one server...should it be at least 20 to 50 servers to replicate real life IT? Also with various apps workload like Exchange, file server, Database. Not canned benchmark with one test pattern at the time. I found good and objectives benchmarks disappearing from IT industry. The ones I see are funded by vendors in 99% of cases. Reading fine print reveal that. It is maybe time to start a new Gartner, IDC, Forrester type firm who is NOT vendors bias and funding...possible...maybe not.]]></description>
			<dc:creator>Jean</dc:creator>
			<pubDate>Wed, 07 Apr 2010 08:29:49 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-872</guid>
		</item>
		<item>
			<title>And a good dedupe ratio..</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-871</link>
			<description><![CDATA[A good dedupe ratio will reduce the amount of data that has to be deduped. Remember I'm not arguing that dedupe ratio is everything; I'm simply arguing that it's something, and an important something. Since I've seen that some products are also better at replicating than others, I'll say that it's also an important something. But nobody's arguing it's not. ;-)]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Tue, 06 Apr 2010 14:34:17 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-871</guid>
		</item>
		<item>
			<title>Does dedup ratio matter? It depends</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-870</link>
			<description><![CDATA[When I first started looking into dedup solutions 3 yrs ago, the initial feature that I was hit with from the vendors was dedup ratio. &#34;Ours is better than theirs&#34;, &#34;No, ours is better&#34;. Once I started learning more and more IMO the single best feature of some dedup solutions is replication. A good replication scheme will trump or enhance the best dedup ratio. I agree that the better the dedup ratio will result in less disk overhead, but if you're a large site (or any size site for that matter) with DR considerations if you can eliminate making tapes and start sending dedup data to remote sites, we'll you've saved more than the difference between 90 and 95% dedup. The bottom line is the calculation of dedup's benefits are endless.]]></description>
			<dc:creator>Allan Hurlock</dc:creator>
			<pubDate>Tue, 06 Apr 2010 13:56:47 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-870</guid>
		</item>
		<item>
			<title>The first part makes no sense</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-869</link>
			<description><![CDATA[What matters in the end is how much disk you have to buy, power, and cool. And the difference between 10:1 and 20:1 is a 2X decrease (or increase) in that amount. Who cares how much you have saved so far; what matters is that if you buy the 10:1 system you will need to buy twice as disk -- and replicated twice as many backup bytes -- than if you bought the 20:1 system. It doesn't matter that you already saved 90%; what matters is what happens NEXT. Your incremental savings are 50%, not 5%. And anyone who says to buy a product simply due to its dedupe ratio is an idiot, so you won't hear me saying that. But what I am saying is that the main point of the second half of Dipesh's argument is wrong. Dedupe ratio totally matters.]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Fri, 02 Apr 2010 14:54:24 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-869</guid>
		</item>
		<item>
			<title>Glass half empty?</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-868</link>
			<description><![CDATA[Curtis, while your math is accurate, I think you take a glass-half-empty approach to the subject. Take your example: If you have 100 TB of backups and you dedupe it at 10:1, you need 10 TB of disk. If you dedupe it at 20:1, you need 5 TB of disk. True enough. But the point is that even at 10:1, I'm saving 90 TB of disk. Sure, 10 TB is twice as much as 5 TB, but it's still 90 TB saved vs 95 TB saved. The difference in the savings is much smaller than the difference in the resulting disk footprint. A 90% savings is still huge any way you slice it. That being the case, I don't thinking a product decision should be made on a 10:1 vs 20:1 basis only. You can easily lose that extra "value" if the product doesn't work for you operationally.]]></description>
			<dc:creator>Peter Eicher</dc:creator>
			<pubDate>Fri, 02 Apr 2010 13:41:11 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-868</guid>
		</item>
		<item>
			<title>FWIW</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-867</link>
			<description><![CDATA[VCB is a pain everywhere, IMHO. It's already been EOL'd by VMware, so I wouldn't change backup software products just to fix that problem. Also, NetWorker can dedupe just fine to a Data Domain box (or any target dedupe box). I don't want to sound like I'm anti-CommVault here, cause I'm not. (I am anti-changing-backup-solutions unless there's no alternative.) But CommVault is basically target dedupe. I wrote a post about that, too. (I'm sure it'll be source dedupe soon, but right now the data is deduped at the media agent level.) There's nothing wrong with taking it for a test drive, though. I'm never against that.]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Fri, 02 Apr 2010 02:41:23 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-867</guid>
		</item>
		<item>
			<title>Net admin</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-866</link>
			<description><![CDATA[Thanks for the post! Timely for me. Shailen Patel from Commvault, (any relation to Dipesh Patel?) has been out to see me a couple of times lately because I am thinking about testing Simpana along side Networker 7.5. Networker can't dedupe without Avamar and we'd rather use our own disk than an appliance right now. Networker VCB is a pain. From what I've seen about it's non-deduped backup to disk, you can clone a back up which doesn't purge the disk afterwards, or you can stage it to tape and purge it but the tapes it stages to are not browseable. Only what is on disk is browseable for the retention period set for the client. It seems unable to handle knowing that the save sets were moved off to tape and that you would want your retension policy to transfer to the tapes it staged to. Because of this, staged tapes have to be cataloged for any and all recovers. Since we can't dedupe without Avamar, it seems worthwhile to take the Simpana for a test drive. You are so right about changing backup solutions. It took forever to get Networker to be running stable and smooth. It better be fantastic to make me change after all that trouble.]]></description>
			<dc:creator>Patrick Page</dc:creator>
			<pubDate>Thu, 01 Apr 2010 20:03:01 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/305-dedupe-ratios.html#comment-866</guid>
		</item>
	</channel>
</rss>

