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.drew AT AMERICAS.BNPPARIBAS DOT COM>
Date: Tue, June 23, 2009 11:32 am
To: ADSM-L AT VM.MARIST DOT 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
NRodolfich AT CMAONTHEWEB DOT COM
Sent by: ADSM-L AT VM.MARIST DOT EDU
06/23/2009 12:07 PM
Please respond to
ADSM-L AT VM.MARIST DOT 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.
|
