Shawn, I have found it very important when working with EMC (or any vendor, really) to very carefully verify everything they say, or ask to have it explained so you understand it thoroughly. I don't mean to imply that they lie about anything, but I have frequently seem them exaggerate their claims. Here are a couple examples:
- The first time we heard about Avamar was at an EMC event where the speakers whole thrust was that this was the best solution out there for backing up lots of VMs. But as I said in my earlier post, right now it is a terrible solution for VM if you want to use VCB. If you don't mind installing and running the Avamar client directly on each VM you can do that, but that is certainly labor intensive and VCB exists to get customers away from doing that. - There was a speaker at an EMC event that used a specific customer as an example. They told about what great efficiencies the customer had realized, and how great the deduplication was, and how much money the customer had saved, and so on. They were extremely specific and clear. Well, I asked our EMC rep if I could talk to this company so I could ask them some questions about the their implementation. This customer happens to be the same city as we are. After a couple days they came back and explained that the customer hadn't actually bought Avamar yet. They had evaluated it and liked what they saw, and were getting ready to install some Proof of Concept gear. But that is miles away from the impression they gave during this presentation. These are isolated incidences, and things are not alway like this with EMC. I am just saying, do your best to verify what you hear, or test it for yourself. Best Regards, John D. Schneider The Computer Coaching Community, LLC Office: (314) 635-5424 Toll Free: (866) 796-9226 Cell: (314) 750-8721 -------- Original Message -------- Subject: Re: [ADSM-L] TSM vs Avamar From: Shawn Drew <shawn.d...@americas.bnpparibas.com> Date: Wed, June 24, 2009 9:24 am To: ADSM-L@VM.MARIST.EDU Wow, great info everyone. The last note you put in there about there not having an archive solution. I can't remember the details now, but the sales guy said there was some kind of archive feature involving VMware. Something along the lines of creating a standard VM with the archive data or something like that. Do you know what they were talking about? I should probably get more details. Regards, Shawn ________________________________________________ Shawn Drew Internet john.schnei...@computercoachingcommunity.com Sent by: ADSM-L@VM.MARIST.EDU 06/23/2009 05:40 PM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject Re: [ADSM-L] TSM vs Avamar Hi! I am just finishing up a multi-month proof-of-concept for Avamar. It has many benefits, but you need to keep in mind these things: 1) It is a disk-only solution, it has no tape backend. You will have to scale your Avamar footprint to completely contain all your backups, for however many days retention you need, so it all fits on one (or more) Avamar grids. If you scale it too small, you are going to be making a disk purchase to keep up. If you let it fill up, you are in trouble! You can't just shove more inexpensive tapes into the library. On the other hand, since Avamar's consumption of disk will be a tiny fraction as much as disk storage pool, you won't have to buy as much disk to get where your job done. Your consumption of disk is space varies widely depending on or mix of filesystem, database, NAS data types, so get help from EMC sizing the solution. 2) Avamar is RAIN technology (Redundant Array of Independent Nodes). Each grid of nodes will require 1 node for administration (called a utility node), and 1 spare. The nodes in the grid can contain either 1TB or 2TB. Redundant copies of that data are distributed across the nodes in the grid. Although it will scale to bigger grids, best practice is to keep the grids to around 14 nodes in size. This is not a terrible thing, but can add significantly to the cost. 3) Avamar comes with replication built in. Replication can be one-one, one-many, many-one. But replication takes time, and you should not plan to do your backups during replication; the performance will be significantly impacted. 4) Avamar also requires regular scheduled garbage-collection. They tell me it typically needs to run 2-4 hours per day. During this time the grid operates in read-only mode; you cannot do backups to it. So if you have hourly Oracle archive log backups, or some such, you will have build them to live without Avamar for these periods of time, because garbage collection is a necessity. 5) Backing up VMs, because they are so similar to each other, sounds like an idea application for deduplication. However, the VMWare VCB proxy solution today is very bad. But in every Avamar presentation I have been to, they completely gloss over how it really works. The way it works today requires each separate VM to be in its own group and its own schedule. In our case, with 600VMs, that was going to be a nightmare. Sometime in the third quarter when VMWare comes out with its next version of VCB, it is supposed to be much better. 6) It is not an Archive solution, so if you have multi-year long-term archive requirements, you will be needing a separage solution for those. Best Regards, John D. Schneider The Computer Coaching Community, LLC Office: (314) 635-5424 Toll Free: (866) 796-9226 Cell: (314) 750-8721 -------- Original Message -------- Subject: Re: [ADSM-L] TSM vs Avamar From: Shawn Drew <shawn.d...@americas.bnpparibas.com> Date: Tue, June 23, 2009 11:32 am To: ADSM-L@VM.MARIST.EDU They do have hardware at the multiple sites for DR. This is a "hot" DR site as opposed to a cold site that you can do with tapes. This does fit our environment however. We have multiple data centers that are DR sites for each other. Currently we use TSM with VTLs at multiple sites and just replicate with backup stgpools over the WAN. In reality, we run into more bad tapes than we do with bad disks. I can't remember if I've ever had to run a "restore stg" on a VTL. We only use tape for long term stuff Regards, Shawn ________________________________________________ Shawn Drew Internet nrodolf...@cmaontheweb.com Sent by: ADSM-L@VM.MARIST.EDU 06/23/2009 12:07 PM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject Re: [ADSM-L] TSM vs Avamar What does Avemar offer for DR purposes? I don't know any customers that are ready to totally rely on electrically powered disk drives as a DR solution. ------------------------------------------------------------------------ The recent CommVault topic inspired this one. Our EMC reps are doing a good marketing job for Avemar. While I'm not necessarily looking for ammo to shoot them down, I am having trouble finding the negatives of Avamar versusTSM. The main marketing claims that interested me: - Dedupe at the client. They also claim that since they can do it at the client, the ratio they can achieve is much higher than Falconstor or DataDomain backend deduplication. - They have some kind of directory tree hash marking. The claim for this is that if you have directories with millions of files, it will have hashes for each directory level. If one file changes, it can detect which directory has changed through these hashes and will prevent complete file system scanning for every backup. Sounds like it's an alternative for the TSM journaling feature. - They have some kind of Vmware appliance generation thing which they use to create long term archives assuming they won't fit on the million:1 deduped storage! As far as the negatives go, number one seems to be no analog to the independant adsm-l community. Which also seems to prevent finding more negatives. Also, the pre-sales engineer is a former TSM guy, which was a craft EMC move! Anyway, does anyone know any other negatives for Avamar vs TSM? I'd like to be able to ask more intelligent questions. Regards, Shawn ________________________________________________ Shawn Drew Regards, Nicholas This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Please note that certain functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
