Target deduplication appliance performance comparison

The world of target dedupe has changed significantly since I wrote my first performance comparison of target deduplication vendors 18 months ago.  It wasn’t until I made the chart for this blog entry that I realized how much they had changed.

Caveat Emptor

As I said in the last post, please remember that I am publishing only what the vendor advertises.  Some vendors that didn’t like the numbers I published last time said that I’m validating the numbers by publishing them here and that’s nonsense; I am only collecting information from a variety of public sources and normalizing them so they can all be put into the same table.  If they say they support 4, 8, or 55 nodes in a global dedupe system, then that’s what I put here.  If they say they do 1000 MB/s, then that’s what I put here.  I have verified some of these numbers personally; however, since I haven’t verified them all, I do not believe it would be fair to speak publicly about the ones I have verified.  Not to mention that is actually how I make my living. 😉

Shameless Plug

Speaking of making a living… If you are an end user considering a purchase of one of these units, and you’d like to find out which of these claims are actually true, then a subscription to Truth in IT’s Backup Concierge Service is what you’re looking for.  $999 a year and you get to talk privately and anonymously to me, other backup experts, and other end users just like yourself that are using the product(s) you’re interested in.  $999 a year pays for itself with one purchase of or upgrade to any of the products we cover. Just imagine having Mr. Backup in your corner every time you have to talk to a backup vendor!  If you’re a vendor, sorry. is for end users only.

Global Dedupe Matters

Before discussing the numbers, I once again feel it is important to explain why I allow some products to add the throughput of multiple nodes together, and I require other products to use only the numbers for a single node.  It’s simple.  If a vendor’s nodes behave like one node from a dedupe standpoint (i.e. they have global, multi-node, dedupe), then they can put them together.  If they behave like multiple independent nodes (i.e. they don’t have global dedupe), then why should they be allowed to put them together and call them one node?

I’ll give you two examples from the target dedupe market leader, EMC/Data Domain, to illustrate my point. Let’s talk about their new GDA, or Global Dedupe Appliance and the DDX.   The GDA uses NetBackup’s OST and Data Domain’s Boost to load balance data across two DD880s and ensures that data is globally deduped across both nodes.  It is two nodes acting as one; therefore, it is perfectly valid to publish its throughput rate as one number.  The DDX, on the other hand, is a different story.  EMC continues to advertise the DDX as “a 16-controller DDX array [that] provides up to 86.4 TB per hour throughput.”  The problem is that it’s only an array in the general sense (e.g. an impressive array of flowers), not in the IT sense (e.g. a disk array).  The DDX Array is really just 16 Data Domain boxes in a rack.  They know nothing of each other; if you send the same exact data to each of the 16 arrays, that data will be stored 16 times.  Therefore, I do not use the numbers for the DDX in this table.

Vendors More Open

One of the things that has changed since I did this 18 months ago is that vendors now publish all their numbers.  Specifically, the post-process vendors put their dedupe rates on their website, rather than just publishing their ingest rates.  I don’t know if it was this blog post that coerced them to do that or not, but I’d like to think I helped a little.  The result is that this table was published using only numbers that are publicly available on their website, and in no cases did I find a vendor that didn’t have their numbers somewhere publicly on their site.  Bravo, vendors.

Backup Only

I am publishing only backup numbers for two reasons.  The first (and biggest) reason is that they tend not to publish their restore numbers, and I wanted this post to use only published numbers.  The second is that (with a few exceptions), the performance numbers for restore tend to be in line with their performance numbers for backup.

Having said that, backup is one thing, restore is everything.  Just because fast disk-based backup devices usually make fast disk-based restore appliances, do not assume this to be the case.  Test everything; believe nothing.

If I’ve told you once, I’ve told you 1024 times

I used 1000, not 1024, when dividing and multiplying these numbers. If that bothers you, go to and find some movies to submit goofs on and stop picking on me.  I was consistent, and that is what matters in a table like this, IMHO.

The Comparison

The vendors are listed alphabetically, of course.  The product names are all links to the documents from which I derived the numbers.  If the product is an inline product, then I put a number in the Inline Backup Speed column.  If it is a post-process product, then I put numbers in the Ingest Speed and the Dedupe Speed columns.  The Daily Backup Capacity is my attempt to compare the two different types of products (inline & post-process) side-by-side.  Assuming you’re going to dedupe everything, then you can really only ingest as much data in a day as you can dedupe in a day.  I took the value in the Inline Backup Speed column for inline vendors and the Dedupe Speed column for post-process vendors and multiplied it by 86400 (the number of seconds in a day), then divided by 1,.000,000 to get the number of terabytes they could back up in a day. The usable capacity is the maximum amount of space that you have to store deduped data on that particular appliance.  (This would be minus RAID overhead and does not include any deduplication.  The amount of backup data you could store on each appliance would be a function of what your deduplication ratio was multiplied times the usable capacity.)

Update: My first version of this table had NEC coming in at something like 16K MB/s, but it’s been updated with a much bigger number.  This is because I was using some older numbers from their website that they didn’t know were still there. I am now using the most up-to-date numbers.



Inline Backup Speed (MB/s)

Post-process Ingest Speed (MB/s)

Dedupe Speed (MB/s)

Daily Backup Capacity

Usable capacity







307 TB

384 TB (raw)

2 nodes, NBU/OST only





129 TB

192 TB (raw)


DD880 w/Boost




211 TB

192 TB (raw)

NBU, NW only






172 TB

200 TB

10 nodes, NBU/OST only





172 TB

200 TB

10 nodes






172 TB

268 TB

8 VTL nodes
4 SIR nodes


GB 4000

950 MB/s



82 TB

108 TB







57 TB

36 TB







86 TB

1000 TB

2 nodes


HydraStor HS8-2000




2376 TB

1320 TB

55 accelerator nodes,
110 storage nodes


DXi 8500




153 TB

200 TB







200 TB

1600 TB

8 nodes


NetBackup 5000




619 TB

96 TB

6 nodes, requires NBU Media Server dedupe to get this throughput



The big winner here is NEC, coming in more than three times as fast as their closest competitor.  This is, of course, a function of the fact that they support global dedupe, and that they have the resources to certify a 55-node system.  (It helps to have an $86B company behind you.)  This is one of the reasons that I referred to them in a previous blog post as the best product you’ve never seen.  In addition to being fast, they also have a very interesting approach to availability and resiliency.  They actually got left out of the last comparison I did only due to an oversight on my part.

The big surprise to me personally is the NetBackup 5000, as it is the newest entry to this category.  It’s only for NetBackup, but it’s pretty impressive that they’re coming in second when they just entered the race.  This is also a function of global dedupe and them supporting six nodes in a grid.  I still don’t think this is a good move for Symantec, as it puts them right in competition with their hardware partners, but it is a respectable number.

Update (11/12): The NetBackup 5000 uses the NetBackup Media Server Deduplication option to get this performance number.  Like EMC’s Boost, the data is deduped before ever getting to the appliance.  They have not published what their dedupe throughput would be if you did not use this option.

Speaking of being a NetBackup customer, Data Domain is looking a lot better than they used to due to the advent of Boost, which supports NetBackup and NetWorker customers.  Boost works by running a plug-in on the NetBackup media server or NetWorker storage node, and doing some of the heavy lifting and deduping before it’s ever sent across the network.  This spreads the load out over more CPUs, and gives a significant effective increase in throughput to those boxes that support it.  Notice that Boost increases the effective throughput of the single-node DD880 to faster than the 8-node Sepaton, 4-node Falconstor, 2-node ProtecTier, or 10-node Exagrid system.  Having said that, I still think global dedupe is important, here and here are some old posts to explain why.  I’ve also got an article coming out next month on about this as well.

I was kind of surprised that FalconStor doesn’t support more than four nodes yet, and their numbers might look very strange if you don’t know the reasoning behind them.  They support an 8-node VTL cluster, but they only support 4 SIR (dedupe) nodes behind that cluster (for a total of 12 nodes).  This is why they can ingest 12000 MB/s, but they can only dedupe 2000 MB/s, which severely limits their daily backup capacity to only 172 TB.

Another surprise was that Quantum came in with a respectable daily backup capacity of 153 TB a day, even though they do not support global dedupe.  That’s right behind Sepaton, which uses 8 nodes to do the same job.

Three vendors told me they were about to do major refreshes by the end of this year, but I decided I’d waited long enough to publish this table.  When they do their refreshes, I’ll refresh the table with another post.

Happy hunting!

Continue reading

Scary Firefox Add-On is NOT a Firefox Vulnerability

If you haven’t heard of Firesheep yet, read this blog article. It talks about a Firefox add-on that allows that use it to “sniff” the login credentials from other users logging into vulnerable websites.  Once you see a user, you simply click the user in the list and Voila!  You’re logged in as that user on that website.

Holy crap, right?  I’d say so.

The reason I’m writing this article, though, is that some (you know who you are, @johnobeto) are using this add-on to say that Firefox is insecure. That is completely incorrect. @Johnobeto also likened this to ActiveX vulnerabilities in Internet Explorer, and he said that MS was held liable for them, so what’s good for the goose is good for the gander.

This is not a Firefox vulnerability.  This add-on does not make someone who uses Firefox vulnerable.  It makes others who are on the same network as that user vulnerable to that user.  That is completely different than someone who unknowingly went to a website that exploited vulnerabilities in ActiveX.  The user using IE is the one vulnerable.  (Not to mention that Firesheep is installed on purpose and plainly visible to the user that is running it, as opposed to ActiveX exploits that were invisible.)

You may argue that it’s uncool that the add-on capabilities of Firefox are being used to do something very uncool, but that’s still not the same as ActiveX which was the vulnerability that was exploited by others.

The real news here is how easy it is for someone to hack into your Facebook, Flickr, or Twitter, Amazon, Dropbox, Google, Foursquare, and Windows Live account by simply sniffing your packets.  (This is not a complete list, it’s just the ones I thought might give the reader some pause.)

Some of these are websites you might actually be paying for services.  If that is the case, you should demand that they fix their website so it no longer has this vulnerability.

Meanwhile, read this article (especially the end) that includes a section on how to protect yourself.

Continue reading

How much cheaper is tape than deduped disk?

I’ve often stated that tape is still cheaper than disk, even after dedupe.  I know that many dedupe salespeople try to tell customers that they’re going to save money by moving from tape to their wonderful deduped disk system; I just don’t see how that is possible.  I’m absolutely convinced that tape is still cheaper, for a lot of reasons.  The only question is how much cheaper?

The big reason this is true is that almost no one is getting rid of their tape drives.  While some companies absolutely have, some customers that have tried have stopped trying.  They find it impossible to meet the long term storage requirements of backups and archives, and — much worse — legal hold requirements, without being able to make a pile of tapes and set them on a shelf somewhere.  This means that almost everyone is still keeping at least some of their tape drives.

So if you’re not getting rid of your tape, and instead buying one (or more) additional appliance(s), each of which is going to cost far more in power and cooling than the tape system you’re not getting rid of of, and neither of which is completely self-managing, how is it that you’re saving money again?  You’re tripling the size of your infrastructure, and 2/3 of that tripling is going to be disk that is more expensive than what you already had.  And if you’re going to be replicating your backups, you may need bandwidth you never needed before.  That bandwidth isn’t free.

But that actually wasn’t what I was going to be writing here.  Deduped disk has gotten so hot that some companies are charging way too much for it.  I recently saw a price comparison between a tape unit and a deduped unit where the tape unit was about $6,000 and the equivalent disk unit was $200,000. WOW.

Is the deduped disk unit easier to use?  Absolutely.  Does it enable onsite and offsite backups without touching tape?  You bethcha.  Would I rather have my backups on disk rather than tape if I had to do a lot of restores?  Definitely.

But is it cheaper?  I don’t think so.  And that’s all I wanted to say.

Continue reading

The Great VTL Debate

“My operations people want me to move off of VTLs as quickly as possible.”  This was something someone said at a recent Dedupe School that I was speaking at in Seattle last week.  The person who said this — I’ll call him Greg — happens to work for a very large company that uses well over 100 VTLs and well over 100 NAS-based target dedupe systems.  I’ve had the opportunity to chat with Greg several times. He is what my Boston friends would call “wicked smart;” he knows his stuff.

Why are his ops people so down on VTLs?  What does this say about FalconStor, SEPATON, or IBM that produce products that are VTL only?  Do they have a future?

I have defended the VTL industry more than most pundits I know, so I thought it only appropriate to revisit the topic in light of this feedback from a  real VTL customer.  The good news is that the reason that I push certain people to VTLs still exists; the bad news is that the bad things about VTLs haven’t gone away either — or at least with this guy’s particular VTL.

VTLs have one major advantage over their NAS counterparts — Fibre Channel.  Even with advancements like 10 GbE Ethernet, TCP Offload Engines (TOEs), iSCSI & FCoE, Fibre Channel is still a more efficient way to move large chunks of data than any of the alternatives.  Greg told me that they have tested all of these newer technologies and agreed with the above statement.  10 GbE Ethernet may sound faster than 8 Gb Fibre Channel, but when it comes to backups it just isn’t.  You can argue that Fibre Channel is more expensive, or that it’s the protocol of the previous decade and not the next, but it’s still the best thing going for bulk transfers of data like backups.

For the last 10 years, backup experts have recommended moving larger servers to LAN-free backups, where backups are sent over Fibre Channel.  We’ve also been recommending using disk as the initial target for backups, even if you ultimately copy your backups to tape.  (It solves the shoe-shining issue by using the disk as a cache.)  For the past few years, we’ve also been recommending using deduplicated disk, but we’ll set that aside for the moment.

Assume that you want to follow the first two of these recommendations: LAN-free backups and disk as your initial backup target. You need a disk device that you can share with multiple servers over Fibre Channel, and there are two ways to do that: a global SAN-based file system and a VTL.  Greg and I agree that the VTL is by far the best choice.  The concept of a SAN-based, globally-writeable filesystem may seem nice but it has not gained market acceptance.  Even a guy whose company doesn’t like VTLs thinks they’re better than a SAN file system.  That’s something if you ask me.

When you add deduplication into the mix, it’s the final nail in the coffin of the discussion.  If you want disk as a target, Fibre Channel as a transport, and deduplication features, your only choice is a VTL.  (There are no globally-writeable SAN filesystems with dedupe yet.)

The statement above is referring to the options available to a person whose backup software does not have a built-in deduplication option, or to a person who who believes that their backup software’s dedupe option isn’t ready for their needs.  Products like TSM, ARCServe, NetBackup, and CommVault do offer built-in dedupe that allow customers to use both Fibre Channel and disk and have dedupe as well. 

FalconStor might claim that they are the only exception to this rule, since they offer OST (NetBackup/Backup Exec Open STorage) over Fibre Channel.  (Everyone else does OST over IP.)  However, since they ultimately store that OST data on virtual tapes in their VTL, they should continue to have the same challenges that other VTLs have.

So what’s wrong with a VTL? 

When VTLs first came out, it was thought that the similarity to real tape libraries would make them easier for customers to integrate into existing backup systems.  It’s just like what you’re already using — just better!  The problem is that pretending to be tape also comes with some of its disadvantages:

  • Tape drive operations sometimes hang, requiring SCSI resets
  • Even virtual tapes get stuck in virtual tape drives (this is a variation of the previous issue)
  • 50 virtual drives do indeed take more work to manage than 10
  • You cannot read and write to a single tape at the same time

Greg told me that the first two issues caused enough hassles for his operations team that they wished they could get rid of VTLs altogether.  He said they don’t have any of those challenges with their NAS-based dedupe appliances. Because of this, he feels very strongly that he wants to limit the number of virtual tape drives that he needs to manage. But since the NAS-based systems can’t meet the performance requirements of his larger systems, he’s forced to deploy the VTLs.

I did push back a little, asking him which brands of VTLs he had seen this on.  (His experience was with one VTL that is no longer on the market, and one other mainstream product that is a VTL-only product.)  I suggested that had he tested and deployed a different model of VTL that things might have been different.  He disagreed, feeling that the problem is primarily a SCSI/tape drive thing, not something any particular VTL vendor could fix.  I still can’t help but wonder if his opinion about VTLs would be different if he had over 100 VTLs of somebody else’s brand.  They aren’t all created equal, after all.  If any VTL customers want to reach out to me privately to confirm or deny that you’re experiencing the same problems as Greg, I’d really like to hear it.

The final disadvantage (not being able to read/write at the same time) is one that causes many people grief, because it causes conflicts for various processes.  Perhaps you want to copy last night’s backups to real tape, or perhaps your virtual tape needs to be read by a post-process deduplication process.  Either way, it is a pain that you can’t write and read to/from the same tape at the same time.

I actually have a bet with Marc Staimer about the future of VTLs.  He said they will be on the decline in five years and I said they would be on the rise.  The weird thing is that we made it on Valentine’s day and the bet was for dinner. 😉 We’re almost 3/5 of the way through the five years and VTL-only products continue to flourish.  They may not be perfect, but I still think they’re the best thing going if you want dedupe and Fibre Channel in a single appliance.  (They’re actually the only thing going.)  Ultimately the market will decide.

Continue reading