Oooh. This is fun. Let's not change the thread, as I'd like to keep
the discussion going all in one thread.
Wilbur Aymond said:
>VTL: Why?
It gives you the benefits of tape without the drawbacks.
Most of my arguments have to do with large environments. In smaller
environments, I'd go either way. But as soon as you get to multiple
storage nodes, my arguments come into play.
* It's easier to share a VTL among multiple storage nodes
* It's even easy to share one between multiple backup apps!
* Provisioning is a lot easier than with disk.
(Typically, no LUNS or filesystems to manage or grow)
* Your backups would actually work (that's also true of AFTD)
>Best reason for *not* using a VTL: Cost.
Not anymore.
> Unless things have changed drastically in the past few years,
They have.
>VTLs are and always will be much more expensive than a tape library
Most of them (if using dedupe) are now as cheap, if not cheaper than an
equivalent tape library. It's what is finally causing a massive surge
in purchasing them.
>but one of the most expensive components remains the same for far
longer
>than you will *ever* see a VTL last. Depending on the type of disk,
>I believe these are rated to 3-5 years, for 24 hour operation of
>non fibre disks.
Are you seriously comparing the long term viability of a tape library
over a VTL? Yes, disk fails, but so do tape drives. And they get
replaced, just like with tape drives. And, while tape libraries may
last longer than 3-5 years, very few people keep them that long.
>Assuming you sized things correctly, in a few years time, your VTL will
be >outgrown by either capacity or bandwidth. Will you be able to
upgrade it?
Yes you will if you bought the right one.
>No. Like any disk system, eventually forklift replacement is your only
>option.
The ones I look at are actually more scalable than most tape libraries I
know. Some of them have infinite ability to expand both capacity and
throughput.
>This doesn't even begin to address the costs of training,
documentation, >etc. involved.
No more or less than a tape library. In fact, I'd say it's less.
>This also doesn't even consider the fact that in most cases, you won't
be >getting rid of your tape library entirely, you'll just be adding
another >component to your infrastructure.
Most people are doing one of the following:
1. Buying disk instead of another tape library or growing the one they
have
2. If they're going to throw away their current tape library, then they
Replace it with one that's significantly smaller.
> -Which as we all know more components can mean more potential problems
and > more expense
Yes, but by making disk your primary target, a significant number of
your problems go away, and it's much easier to keep the tape drives
happy if they're being streamed by copying data from a VTL.
>as you cannot do long term backup storage on a VTL without
>breaking your wallet. (yes DataDomain and others have some good dedup
>products, but this is still not an offline, long term (1+ year)
solution)
>for most cases.
Yes you can. I'm not sure I'd do 5+ years on a VTL, but 1-3, sure.
And, believe it or not, the longer you store stuff in a dedupe VTL the
cheaper it gets per MB. That isn't true for tape.
As to dedupe, you mention it almost as an aside. Dude, it's the mutt's
nuts. There's a reason it's the most hyped technology since VMware. It
works and really does give you the benefits of disk without the cost
element you seem to be so worried about.
>why use a VTL for this? There's a much better solution.. Disk.
I will agree with you for small shops, not for big shops. Another
reason is that if you want dedupe (and you want dedupe), then your
choice is VTL or NAS (not LUN/filesystem access, but NFS/CIFS). If
you're a big shop, you want to send your stuff over Fibre Channel, not
IP. If you want to do that today and get dedupe, then you go VTL.
>And I'm not talking AFTD (which based on the discussions I've been
reading >through here "advanced" file type device is a bad joke to say
the least). >I'm talking *snapshots* and *replication* to disk. There
are plenty of >different brands of this, host based, network based,
filer based, etc. So >what do you get here? The same things you get with
a VTL, only better, and >cheaper.
Why didn't you say so in the first place? NO argument there, but that's
a much bigger discussion. I actually prefer snapshot and replication
(which I call near-CDP) to any of this stuff, but the whole world's not
ready for it yet.
Most changes in backup environments are made in small steps, and what
you're describing is just too big of a step for most people -- although
I'd be happy to help someone make that conversion.
Also, I have priced your idea vs a dedupe VTL in customer environments.
Without giving away the vendors, I will say that in the last customer,
the cost actually came out the same. (Snapshots/replication vs backup
to a deduped VTL.)
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]On
Behalf Of Curtis Preston
Sent: Thursday, August 21, 2008 2:04 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Query in Staging from adv_file
>I don't think device count is relevant in a NetWorker environment
>because EMC doesn't license anything based on device count.
That's not entirely true. First, there are versions of NetWorker where
you're only allowed to have a certain number of devices (e.g. 4 tape
drives). Second, there is Network Edition and Power Edition, where the
number of concurrently used devices is regulated.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the system manager. This
message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
