still, i’ve at least gotten DD to cop to a single-stream transfer rate of about 150 MBps in the past. was hoping to have some kind of genuinely comparitive number like that w/r/t avamar. to at least have specific, numerical, competing *claims* would be a start…

EMC’ers always act shocked when i bring up that scalability thing about avamar, but they’ve got to know that persistent viewpoint is out there. i’ve tried to dig into it in the past, and haven’t yet personally spoken with any avamar users with 1000s of servers protecting hundreds of TB as was mentioned above. i’ve spoken with one who had an overall environment that could be described that way, but had a more limited amount of avamar in production.

tho really, at this point, all of the above might be moot in the face of the ‘rip and replace’ factor when it comes to EMC’s ability to use / sell Avamar’s software…

Any product can be set up to perform well in a lab setting that may or may not be indicitave of “Production” situations.

I always take such performance claims with a grain of salt. I’ve worked in R&D, specifically in Qualification and Test, and I remember times when the same test run back to back produced slightly skewed results. Not enough to invalidate the test, but definately enough to make you wonder what else is going on in the background of the software.

I’m not a big fan of compression (or de-duplication as their calling it now). I remember having a sales guy come in to pitch Avamar to me at one of my last jobs, and the fact that they wanted to sell me a product for tens of thousands of dollars to save a few bucks on my tape footprint was just staggering.

De-Duplication is essentially the same process used in zip/tar operations. You’re taking repetitive blocks of data within a stream and replacing it with a kind of count/pointer system. All of it takes cycles. If it is done on the host it takes CPU cycles, if it’s done in-line via an appliance it increases latency.

Just my $2.12 (adjusted for inflation)

HP’s aquisition of EDS is a last and desparate attempt to stay relevant in the enterprise market. They are losing Unix market-share right and left, (I can’t remember the last time I connected an HP server to a SAN), and they’re having to fight Dell for every x86 architecture server they can.

I think that this buyout is going to prove to be another Compaq for HP…. Expensive and difficult to maintain. (Although the fact that they are not trying to rebrand EDS as “HP Global Services” or something similar, leads me to believe they may have learned something in the process of the Compaq fiasco.

Jesse

However, the same statement can not be made for server virtualization environment. So even if backups complete faster, the CPU cost are “more than a traditional application would too”

What that says to me is that I have to schedule backups in VMware environments in such as way as to incur as minimal impact as possible on the physical host.

Dealing with 1200 VMs and 95 servers in my environment this has to be a backup scheduling nightmare although the dedup aspect is rather intriguing.

Stephan

Specific client speed is, as you can imagine, dependent on the speed and power of the client. The best way I can put it (and most accurate without a specific machine sizing to refer to) is that it is “somewhat” more intensive than a typical backup client. But, as I said, it is also usually 90%+ faster to complete the backup job.

Network latency plays a surprisingly small role. That was one of my first questions too. Having said that, the biggest area you might think latency enters is the checking of hashes between client and server to determine if the server already has a segment. But Avamar bundles many of these hashes into a single packet, to reduce latency. About the only other specific comment I can make is the annecdotal comment that I have run an Avamar client under a wide variety of network conditions (some hotel networks are really bad) and performance and backup time did not seem to degrade much at all irrespective of the network I was on. For a typical client, so little data is transmitted, and backups require so little time to complete, the whole issue is a non issue.

Finally, not that there are a whole bunch of options on how to deploy the Avamar server: from virtual editions under VMware to full blown multi node grids, to single nodes, all with and without replication as you choose. So there is significant flexibility.

We really are discussing apples and oranges when it comes to this and DD, more on my blog in the next little while… I don’t want to monopolize your space!

Is it any wonder the technical folks at companies want your ( as the vendor’s representative) throat?