>This is an excellent point, and is exactly the reason that EMC offers
an
>embedded NetWorker storage node as an option in their EMC Disk Library
>(EDL).  By using this feature, in concert with NetWorker's standard
>cloning functionality, you have the VTL server make the clones directly
>from the virtual tapes.  

Sorry, Terry, but this doesn't solve my core issue, and, IMHO, creates
another one.

My core issue is the difficulty of creating clones in the first place.
Moving the SN inside the VTL doesn't change that.  As I stated before,
cloning is a CPU intensive process that sometimes takes a lot longer
than just bulk copying from one tape to another.  AND, it's not like
it's easy to automate cloning in NW -- in environments that can't use
group-level cloning, anyway.

In addition, I tend to run my SNs and my VTLs so that there's no CPU
left in either one.  It would seem that moving the SN inside the VTL
would decrease the throughput capacity of both.  It's true that an SN
inside a VTL would cost less than an SN and a VTL, but I believe you get
what you pay for.

>and you don't need to pull the data across the SAN
>to the production storage node, and then write it out to the target
>device.

This is another red herring, IMHO.  You're still moving the same amount
of data across the same pathways.  The data's leaving the virtual tape
on a disk, travelling up one FC port, into the CPU, back down another FC
port into a real tape drive.  You're still "pulling it across the SAN."
It's just that the SAN is all inside the EDL chassis.  It's not like
"pulling it across the SAN" has ever been the problem, either.


>Standard cloning functionality also allows you to
>change the media tape during the clone operation, so you don't have to
>have the same physical tape drives as the virtual tape drives used to
>create the original backup.  

That is the biggest advantage, as I'm often advising people to have
smaller virtual tapes, especially if they're going to dedupe.

>And so on and so on.

I would add that the advantages include not having to worry about a
third party cloning process.  (If the copy from virtual to physical
fails, NW will not know.  You have to manage it via the VTL interface.)
They also include not having to worry about what happens when real
LT00001, the real tape that's supposed to carry the backups of virtual
LTO0001 BREAKS beyond repair.  It shouldn't happen much, but what you
have to do when that happens is a bit of a pain.

>Finally, EMC has made several enhancements to make the EDL and
NetWorker
>work well together.  

When are they going to fix the core problem of the non-existence of an
automated cloning facility?  This is something that VTLs, PTLs, and
AFTDs have.





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