<?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>The real deal on the EMC 3D 4000 (Part 2)</title>
		<description>Discuss The real deal on the EMC 3D 4000 (Part 2)</description>
		<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html</link>
		<lastBuildDate>Fri, 10 Feb 2012 10:56:17 +0000</lastBuildDate>
		<generator>JComments</generator>
		<atom:link href="http://www.backupcentral.com/component/jcomments/feed/com_content/232/10.html" rel="self" type="application/rss+xml" />
		<item>
			<title>Lots to correct</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-586</link>
			<description><![CDATA[Can we at least agree that Mr. Preston is very well versed on this subject? In this thread I see Mark admitting a lot of &#34;correct&#34; and &#34;yes&#34; and even an &#34;I defer to the manual on that one and was incorrect.&#34; Since credibility is how Curtis makes his living, can we agree that Curtis has that in spades and you were way off the mark in your previous post where you stated &#34;I'd appreciate it if you made all the relevant corrections and I realise how difficult it can be to pick out facts when you're not building these things from the screws up.&#34; Curtis seems to have his facts well in order to the point where you needed to issue your own list of agreements and corrections. Maybe it was a poor attempt at humor but if you want to be demeaning in your post, that's your choice. I'd suggest a robust debate is better when both sides hold the facts and the people in high regard. As an aside, can we also agree that we should by default disable diagnostic services that can cause data loss? I can field test that question but I guarantee the overwhelming response from Administrators will be, &#34;What?! No, turn it off. I'll enable it if it gets to that point.&#34;]]></description>
			<dc:creator>Mike Riley</dc:creator>
			<pubDate>Tue, 21 Apr 2009 12:20:32 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-586</guid>
		</item>
		<item>
			<title>CognitevelyChallenged says:</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-577</link>
			<description><![CDATA[You can be the SME in Ireland until I return to my island. I personllay 'love' EMC storage products and have installed many (20+) C/EDLs into TSM environments. The only problem I ever had with EMC was the 'people' that worked for them. While I dont' believe Curtis is always correct, he provides insights and give potential pitfalls that 'may' be encountered in the black art of data protection. But for (Skid)Mark, you really need to get out more. I can see why you've lasted so long at the Evil Machine Company, becasue you drank their cool-aid long ago. I also seriously doubt that you thnk in Exabites. The largest shops I've been to can't even begin to go to that level, and the are all primarily fortune 50. Have a nice day!]]></description>
			<dc:creator>CognitevelyChallenged</dc:creator>
			<pubDate>Tue, 14 Apr 2009 11:44:47 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-577</guid>
		</item>
		<item>
			<title>BTW, I\'m not an analyst ;)</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-563</link>
			<description><![CDATA[Analysts make their money from vendors. I make my money by independent writing (i.e. articles -- NOT vendor whitepapers) and by direct work with end users.]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Wed, 01 Apr 2009 02:46:03 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-563</guid>
		</item>
		<item>
			<title>Not sure we\'re on the same page</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-558</link>
			<description><![CDATA[Marc, I had no idea you were Storagezilla. That's why I never read your About page. I did google you when you put your comment in. Although the first entry is Storagezilla, I didn't see your name in the following text, so I thought that an anomaly. Now I figured out who you are, so I corrected my post. (I do make corrections when they're warranted.) I never said I don't like the Quantum immediate model. I merely needed to point out that it is closer in I/O pattern to the post-process model than the inline model, so that I could THEN add the additional 200% of I/O that the 4000 creates. That was the point of that whole exercise. If you ever hear me speak or write about post-process vs inline, I give a good number of advantages and disadvantages to both, so I still say it doesn't matter. What matters is what you get for what you pay. Two definitions of cache? I don't think so. Every technical definition of cache I could find can be summarized as "a copy of recent data stored to increase data transfer rates." You said repeatedly in your previous comments that "there is no cached copy," and that I should correct that. Both the EMC and the Quantum documentation backup that there is indeed a cached copy, so I don't see anything to correct. The 256 MB to which you refer is the element of work in the Quantum dedupe engine, not a single 256 MB area. Once 256 MB comes into the box, they create what I'll call a chunk of data and write it to disk. While this is happening, the dedupe engine is trying to dedupe data. It prefers to read the data it will dedupe from RAM, but it will get it from disk if it is no longer in RAM. But ALL data in its original format (that was written in these 256 MB chunks) is left on disk until it is truncated. That data is uses to increase restore speeds of deduped data, and I suggest that any reasonable techy would call that a cache. Whether you count on this cache being there or not is not the point. The point is that the cache that you said didn't exist exists. (I'm sorry to put such a blunt point on it, but the whole point of your initial comment to my first post was that I didn't understand the architecture and was describing it wrong. I am maintaining that I understand it just fine.) As to the whole discussion about trusting the admins, etc.... I suggest that it has nothing to do with trust and that if you put an interface out there that someone can access, they might eventually use it. Staff continually changes and not everyone reads the manual (shocking, I know), and the fact that you have an interface available that can cause data loss bothers me. It reminds me of the "vmquery -deassignbyid" command that Veritas always told people not to use. They found it useful anyway and kept using it -- to their detriment. Eventually Veritas "fixed" the command so it no longer did the thing that caused data loss. I am not convinced that the ESN is more advanced. I'd discussed that on other posts, but suffice it to say that I'm not sold on it. I'm not saying that I know it's not better; I'm just saying I'm not convinced it's better. You then go on to say (my summary) that the best use case for the 3D 4000 is to dedupe an existing 4000. I said in my original post that I was OK with that use case, although I do think it's prudent to compare the cost of adding a 3000 to an existing EDL with the cost of buying a "regular" dedupe VTL and throwing away the 4000. If your product is as price competitive as EMC claims, then this recommendation should not bother you. As to the costing issue, I've asking for pricing from all the main vendors for a separate post on that topic. So far EMC is the only vendor who hasn't replied to any of my emails on the subject. It'll be difficult to prove EMC's point that the 3D4000 is cost competitive if they won't tell me how much it costs.]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Mon, 30 Mar 2009 16:15:32 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-558</guid>
		</item>
		<item>
			<title>En Garde!</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-555</link>
			<description><![CDATA[SME Curtis. Not sure who you spoke to at EMC (Oh that's a lie, I know exactly who you started speaking to at EMC and when because I checked), but they got my title wrong. Or you could have check the About page on my blog. No one checks About pages anymore and I don't know why. Would have been back to you sooner but end of quarter and had real customers to deal with, not analysts to be playing with. And you shouldn't take any comments as "rather personal" this is nothing more than robust debate. You'll never mistake rather personal from me for anything else should I ever get rather personal. But that's not the case here. Down to it but it's late so this could occur in multiple comments. Okay, so to begin with you're not a big fan of the Quantum immediate de-dup process due to the fact it writes and reads from disk. That's the process for immediate de-dup with the 1500, 3000 and DL3D 4000 de-dup option as well as all of Quantum's native offerings. Fair enough. You don't have to like it, just accept it as an architectural choice and move on. "So, the DL3D 4000 is storing a non-deduped (native) copy of the data for the purposes of increasing restore performance. If that's not a cache, I don't know what is." We have two different definitions of cache, in your case it's another copy. That's not my definition of cache in this cache as I see cache as that 256MB immediate de-dup cache area. This other copy is transient so I personally don't factor it in when it comes to restore performance as you can't count on it being there. It's dependent on the free space in the system. If you have unused space it'll be there. If you don't it'll be truncated and won't. But there is a case here for free space being wasted space. If you have it, there is no reason *not* to use it. And again with all these moves you point to that's true of the 1500/3000 as it's an internal operation to the unit. It's clear you don't like it, but it doesn't matter that you don't like. "There appears to be more than "one copy of data in the system" and the possibility of having data in both places "always" (if you choose the option to never delete the copy on the EDL) is a whole lot more than "never both at the same time." I defer to the manual on that one and was incorrect in assuming you couldn't disable the grooming process. This was an error on my part and I accept that. "3D 4000 appliance does not support Path to Tape feature." Correct because it supports the more advanced Embedded Storage Node (ESN) or Embedded Media Server.(EMS) Lets make no bones about it ESN/ESM do more when it comes to moving/stacking/replicating data sets in a catalogue consistent fashion. "3D 4000 does not support either support [sic] NAS backup or NAS sharing." Yes because all resources are dedicated to immediate de-dup and we're clear about that. It's not written anywhere that the 3D 4000 supports NAS. It's not a supported configuration and should not be used as such. I'm not even going to say at your own risk. Don't do it. "Seriously? You couldn't at least turn off the service that advertises the remote management pages in the 3D box when you plug into the back of an EDL? They're still available, but the customer isn't supposed to use them? And if they use them it causes data loss? Seriously? How hard would it be to deactivate this service so that the customer doesn't have the possibility of causing data loss via a tool provided by your product?" Seriously? How about you just not use it as it's a support only thing? Seriously? When is someone an Admin and when are they an amateur who'll login and muck around with something when they've been told not to? Is your Admin 8 years old? Seriously? If you're capable of not logging into your backup application and relabeling all the tapes or deleting the backup catalogue you're capable of leaving well alone. It's there for support, not for anyone else. If we were to take it to what you're looking for we'd weld the arrays shut so no one could pull out all the disk drives just because they can remove the front panels. Lets elevate the discussion above that fact we treat the Admin as a grown up and a professional shall we? "The first cost issue is that the different "pools" are forever dedicated to the front end or back end and cannot expand or contract to meet current needs. Suppose you bought a 100 TB front end EDL and a 100 TB back-end 3DL. If you decided to dedupe everything, you cannot move any of the 100 TB of front end disk to the block pool. If you decide to not dedupe more than 100 TB of data, you cannot move any of the disk from the 3DL to the EDL for this purpose." The thing being that most 3D 4000 buyers are existing 4000 series owners who are adding De-Dup. They're not looking to rebalance storage they're looking to either keep more data on spinning disk and ditch tape entirely or replicate de-duplicated data off site so they can take the bandwidth reduction it gives them. The use cases for this are specific. I know you just love hammering on this. how many words and how much time have you devoted to this? It probably dwarfs all the coverage of any other VTL product from anyone else, but it fits where it fits and where it doesn't fit the portfolio is broad enough so that something else does. The EDL offers VTL *and* De-Dup with software from Quantum. VTL with software from FalconStor *with* optional De-Dup from Quantum and Mainframe VTL with software from BusTech. There's something for every use case. As for CPU and RAM resources that reminds me, as we're talking about costs what's the CPU to Disk ratio of the solutions you mention in this post? At what number of spindles or amount of capacity do I end up buying another node/engine/head and what does that do to the cost? There's a lot of cost we can take out because we own hardware manufacturing end to end and operate at huge volumes in comparison to competitors. That is a competitive advantage. I'll probably have more later. Take your time with any responses as I'm not going anywhere.]]></description>
			<dc:creator>Mark Twomey</dc:creator>
			<pubDate>Sat, 28 Mar 2009 00:33:17 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-555</guid>
		</item>
		<item>
			<title>DMAPI</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-527</link>
			<description><![CDATA[Sounds like old school unix filesystem DMAPI extensions or stubs to me. Cache would imply there was a portion of the data retained for seek and access time benefit. Also - This would also suggest that the data being retained in place and in "Prime" form suggested a fragmentation potential unless idle VTL cycles are built into the design.? If you needed to read the data the user would be left waiting reconstituted file to be "located, read and streamed to the storage" Maybe for Deep archive but not a good choice for "useful" information. IMHO - Solutionsarchitect.com TAJ]]></description>
			<dc:creator>Todd A Johnston</dc:creator>
			<pubDate>Tue, 24 Mar 2009 12:27:25 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-527</guid>
		</item>
		<item>
			<title>What, there is no cache?</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-546</link>
			<description><![CDATA[Here is what the Quantum DXi manual says about cache. Although they never use the word cache, that is exactly what it is. The language in this manual is almost word for word identical to the 3D4000 stuff you posted about cache. Another way the DXi system reduces the amount of file system capacity used is to truncate the de-duplicated data. Once the de-duplicated data is truncated, only the metadata is available on the file system. This reduces the amount of capacity required in the file system. Once truncated, the file must be reconstituted using it's tag before you are able to access the file. So in not so many words, your backup data will be preserved in its native form for such a period of time until it becomes necessary to remove it due to storage requirements. After that, if you need the data restored, copied to tape, or read for the purposes of syntheitc fulls it needs to be re-duped. Sounds like cache to me.]]></description>
			<dc:creator>Aaron E. Kristoff</dc:creator>
			<pubDate>Mon, 23 Mar 2009 21:35:03 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-546</guid>
		</item>
		<item>
			<title>Hmmm..</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-545</link>
			<description><![CDATA[That's a really good point. Unfortunately, it weighs even further against the EMC and Quantum solutions. Unlike some other solutions that use hardware compression, the Quantum box turns it off for native data that will be deduped. That's why you see the native ingest rate double if the data isn't going to be deduped. This would decrease the I/O needed by those who DO perform hardware compression of the native data. Also, I don't want these posts about I/O to suggest that I'm saying that post-processing systems and the 3D 4000 are necessarily bad because they have extra I/O. I'm just saying that this I/O comes at a cost that must be factored into the system. For a fuller comparison of the differences between inline and post-processing systems, check this article out: http://www.backupcentral.com/content/view/134/47/]]></description>
			<dc:creator>W. Curtis Preston</dc:creator>
			<pubDate>Mon, 23 Mar 2009 13:31:15 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-545</guid>
		</item>
		<item>
			<title>Hardware compression</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-544</link>
			<description><![CDATA[I've enjoyed reading the last few blogs and it has given me more things to think about with regards to dedupe solutions available in the market. Reading the above however I did notice that the I/O estimates don't mention that some VTLs are equiped with hardware compression which should reduce the amount of data read and written from disk. It's true the use of a hardware compression adapter isn't "free" either, but it is one more wrinkle you could include in your comparisions.]]></description>
			<dc:creator>Chris</dc:creator>
			<pubDate>Sat, 21 Mar 2009 06:39:05 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-544</guid>
		</item>
		<item>
			<title>Sound convincing</title>
			<link>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-543</link>
			<description><![CDATA[Curtis, I am on very long terms with backup deduplication buzz, and I rarely guess that EDL stands for something Electronic Data Library, but I want to tell you I like to read your posts to learn new info. What is more you do sound very convincing.]]></description>
			<dc:creator>Konstantin</dc:creator>
			<pubDate>Sat, 21 Mar 2009 01:08:12 +0000</pubDate>
			<guid>http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/232-3d-4000-part-2.html#comment-543</guid>
		</item>
	</channel>
</rss>

