If the technology is real (the founder, Robert Petrocelli has deep experience in digital imaging technology; http://www.getgreenbytes.com/leadership/robert-petrocelli ) and could be offered in a disk-less head unit, we could be looking at a 1PB unit in a 4u rack space using a Dell EqualLogic PS6500 (assuming a very generous, yet advertised by the “big guys”, 20:1 dedup ratio).

Lots of ifs, I know, but disruption is bound to happen in the dedup market and I don’t think the established players are up for it.

Dale

Great points. Let me respond to each in turn:

“Dedup appliance product line” – I’ll grant that QTM’s product line doesn’t have the range of DDUPs – having more of an enterprise focus – but that can be fixed. Dedupe isn’t rocket science. Despite the holes EMC has somehow been selling a lot of it to enterprises.

“Dedupe patent portfolio” – the importance of QTM’s portfolio is not that EMC is protected from lawsuits – it is that QTM’s licensees have a defense again EMC lawsuits. That helps keep innovation rolling.

“Buy the technology that EMC has licensed from us” – But it isn’t a lie: DDUP DID license QTM’s IP as part of their settlement. DDUP argues, correctly, that they developed their technology independently, but the fact is that there was significant, though unintentional, infringement on QTM’s IP. Parallel development – happens all the time – and it takes nothing away from what they’ve achieved. QTM’s timing for their suit was just standard operating procedure, Art of War and all that. But they had the goods.

“Way lower cost” – These deals usually get done around the seller’s 52-week high, which is currently $1.95, but will slip to ~$1.35 in early October. So they can buy an $800M revenue company today for an out-of-pocket $400M vs EMC’s $2.4B. Or wait a couple of months and maybe get it for less. I stand by the “way lower cost” comment.

Where you lose me is the “unless they find another EMC” comment. That’s the whole point: NetApp will be QTM’s customer and distributor. And EMC won’t suddenly slam the door: they’ve been selling QTM for a while – QTM’s disk-based product sales have been growing at 50%+ a year – and enterprise customers won’t suddenly switch to DDUP’s more mid-range oriented boxes – especially if they can get them from NetApp.

NetApp bid for DDUP with the idea that they could grow their business faster than DDUP could by itself. The same holds for QTM.

But QTM isn’t the only option for NetApp – who is reportedly meeting with its investment bankers this week. Exagrid and Commvault are two other options. But QTM is a Valley company, Rick Belluzzo, the CEO, is a sharp guy and they’ve got the IP that EMC licensed. . . .

Robin

“Dedup appliance product line – ripe for the cost improvement that NetApp’s buying power would give them.”

A product line that multiple inside sources confirm has significant problems. There are REASONs that EMC made the move they did. The emperor wasn’t naked, but he sure wasn’t fully clothed.

“Dedup patent portfolio – to help keep EMC honest.”

No honesty required. EMC’s acquisition of DDUP absolves them of any future patent lawsuits from QTM. That was the whole point of the DDUP/QTM settlement, and IMHO a small part of the reason EMC wanted DDUP.

“Good market positioning: “Buy the technology that EMC has licensed from us!””

Except that would be a lie. See my previous comment. It was a patent-infringement lawsuit settlement that took the form of a “license.” DDUP might have been able to fight it had QTM not timed the lawsuit so well (right after DDUP’s S-1 filing).

“Way lower cost. Anti-trust concerns would keep EMC from bidding on Quantum, so unless another spoiler comes along – IBM, HP, Dell, HDS – a deal could be much closer to QTM’s 52 week high.”

PLUS $300M of debt. So they pay $800M+ for a company who only had $88M of disk revenue last year, most of which came from EMC? Unless they find another EMC (and let’s face it; there is no one like EMC) that $88M is going down quickly and sharply.

“A happy Silicon Valley home for ex-Data Domain staffers. No non-competes in California and most of the tech is already cross-licensed, which is about as clean as these things get.”

This one I agree with. Except that they can do that right now with their own technology.

You asked about how long would it take to move a PB between non-interoperable target dedupe systems. How long do you think it would take to do that with source dedupe systems? They’re incompatible as well. The answer is NEVER, because there is NO way to move data between two source dedupe systems. Now, as to your question, here’s an answer (or four answers, actually):

If I assume at least a 15:1 dedupe ratio (which you shouldn’t but math for this discussion gets difficult if I don’t). So I’m not cheating, I’m quoting numbers where the dedupe engine can keep up with the ingest. For example, the DXi can ingest faster than 500 MB/s, but not if it’s going to be deduping concurrently (what it calls adaptive mode). It can only do that at 500 MB/s. The SEPATON box can ingest at 600 MB/s per node, but can only dedupe at 300 MB/s per node, so I’m using that. Same with Falconstor. It can do 1500 MB/s per node ingest, but only 500 MB/s per node dedupe. So those are the numbers I’m using. I then divide a PB by their ingest speed in MB/s, then by 3600 seconds, then by 24 hours to arrive at the number of days it would take. And, as is my usual practice, I’m using multi-node numbers for vendors that have global dedupe (SEP, FALC, IBM) and single node numbers for those that don’t (QTM, EMC/DD).

QTM (DXi 7500 running in adaptive mode).
1 PB/ 500 MB/s 3600 / 24 = 23 days
EMC/Dd (DD 880 using NFS inline):
1 PB / 900 MB/s / 3600 / 24 = 13 days
IBM w/2 nodes (TS7650 in inline mode):
1 PB / 450 MB/s / 2 nodes / 3600 / 24 = 13 days
SEPATON w/ 6 nodes (DS2100 in concurrent mode):
1 PB / 300 MB/s / 6 nodes / 3600 / 24 = 7 days
FALC w/6nodes (4 node system in concurrent mode):
1 PB / 500 MB/s / 4 nodes / 3600 / 24 = 6 days

None of those numbers sound bad to me. Some of them sound pretty awesome.

@Platnum Player:

50 hour backup with target dedupe vs 1.1. hours with source. Remember that backups are one thing; restores are everything. Except for remote offices and relatively small datacenters, the restore speeds offered by today’s source dedupe systems pale in comparison to the restore speeds offered by the fastest target dedupe systems. (I’m talking like 100 times faster or more.)

That is currently what the target guys have over the source guys: seriously fast restore speed. And restore speed matters.

So, it is not obvious why EMC and NetApp should be in a bidding war for Data Domain. Indeed, since SUN, EMC, IBM and Spectra Logic to name just a few all OEM FalconStor technology, EMC could deliver another hay-maker punch to its competitors just by buying FalconStor. FalconStor is smaller than Data Domain with $80M in revenues for 2008 versus $274M for DDUP, but FalconStor has many more products, technologies and a much longer track record.

Just ran across this – thought it would be interesting to those who are watching this closely. – Thom

@Platnum – if you believe there’s one support team behind the one EMC number, you’ve obviously never called it as a customer. Unless EMC support has dramatically improved in the last year or so, you might as well buy products from different vendors. There’s no co-operation between different teams, and from their plans for DD, there won’t be as EMC have already said they will be run as a separate division. And “free assessments”??? Please!

The OEM QTM VTL code is completely different? LOL. That should be laughed at as much as HP trying to sell you on their “millions of lines of code changes” to the USP when they OEM it as the XP.

Avamar, or NetWorker with dedupe will always be the “best” option depending on data type and size, where other companies have one product, brainwashing customers to think it will solve all problems. Target won’t solve MosT issues in the data center around backup and DR, just add another console to manage with your backup app.

The EMC quantum oem vtl uses completly different code than the Dxi product line, EMC has also found major performance issues with the product and fixed them its latest edl code, 1.2.

My .02.

I can keep going on and on… Backups take 50 hours with target based and 1.1 with source based dedupe.
I’m not a math scholar, but I’d say source is better

The problem I see is the fact that many VTLs and depup installations do not have tape at all because they believed their dedup or VTL vendors and some analyst who clams tape is dead. These guys are in trouble now with PB on the floor.

I also partially agree on your appliance like. One storage vendors tried that several years ago with backup and archive and it didn’t work well. The problem is we have geeks that think they can do better and cheaper. So their bosses believe them…wrong!… You can’t beat years of R&D in this area. So I agree this is a challenge for large enterprise who want supported environment. But if the SMB are not jumping into appliances like, vendors R&D dollar will not be spent on the few enterprise one. It is all about revenue, margins etc. Not technology. Believe me I have 20+ years into this market alone and SMB are the worst evil you can deal with. They kill R&D and jobs because all vendors would like to have their iPod or iPhone moment with millions of units sold in this market. SMB works much different than enterprise with open source and the cheapest gears they can find on eBay.

Strangely the biggest backup and archive vendors (Sun/STK and IBM) have the weakest strategy on dedup. They probably know more about backup and recovery technologies than any other vendors combined. This is probably why they have very limited dedup and VTL offering. They might consider tape the best avenue until future and better technology comes in to replace tape. I don’t think it will be soon too.

Oracle might not have the strongest strategy in these area. Unless they give “carte blanche” and millions $ for R&D to Sun/STK once acquired. That is the weakest point for them now. I can’t wait to see what will happen in few months.