Networker

Re: [Networker] Query in Staging from adv_file

2008-08-20 14:05:02
Subject: Re: [Networker] Query in Staging from adv_file
From: Curtis Preston <cpreston AT GLASSHOUSE DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 20 Aug 2008 14:01:08 -0400
Fazil Saiyed said:

>In my opinion, AFTD  may be easier to manage and have cost advantage
over 
>VTL's, ... since, there is little if any configuration to manage in 
>AFTD environment

I agree that AFTDs are easier to manage in smaller environments.  In a
large environment, I believe the opposite.  A _GOOD_ VTL makes it much
easier to supply a large amount of disk as a target for backups, without
having to create volumes, filesystems, mount points, etc.  The VTL can
just get bigger and bigger and have more and more tapes and more and
more drives, without having to change any configuration on NW's side.
This is especially true right now due to the difference in functionality
between tape (or virtual tape) and AFTDs in NetWorker, but it's also
true that the difference in management of many LUNs vs the management of
a large VTL is significant.  (I would want LUNs, as opposed to NAS
mounts, in a large enterprise environment, because I typically am doing
a lot of LAN-free backup there.  How am I supposed to do LAN-free backup
if my target is on the LAN?)  It's hard to summarize all that in one
paragraph, but suffice it to say that I think AFTDs (and NAS appliances)
are easier to manage in smaller environments, and VTLs are easier to
manage in larger environments.

>AFTD  will result in higher storage capacity utilized as there is no  
>space  left unused , unlike Tapes which can be underutilized, 
>if not sized and managed properly. 

This is one of the biggest misconceptions about how VTLs work (often put
forth by those selling competing solutions).  In a _GOOD_ VTL, a 10 GB
tape with only 5 GB on it only takes up 5 GB of your capacity, not 10
GB.  There is therefore no wasted space issue with VTLs, unless your VTL
was designed poorly.

>especially, if Data Domain type of disk's are used for AFTD,

I took this out of context and out of order, so I apologize, but I
wanted to address it as a separate issue.  I will also generalize and
say that I'm talking about all dedupe appliances.  Since dedupe is
offered as much by VTL vendors as it is by NAS vendors, dedupe isn't a
non-factor in this decision.  Other than to say two seemingly
contradictory statements:

1. If you're buying disk (AFTD or VTL) today as a target and it doesn't
have dedupe, I think you're wasting your money.
2. If you're only doing disk staging (i.e. holding only last night's
backups on disk), then dedupe is a waste of money.  Only if you're
holding several weeks of backups on disk does dedupe make sense.

>At this time, i am leaning towards AFTD behind Dedupe Appliance, as 
>replication technology becomes more prevalent, which in my opinion has 
>higher value in Dedupe appliance, sizing and capacity uplift should 
>considered  to be significant factor in any VTL or AFTD environment.

Replication after dedupe is awesome.  But, again, this is not offered
ONLY by Data Domain or other NAS-based dedupe systems.  There are
several vendors that offer dedupe and replication.  Some are VTL; some
are NAS; some are both.


Curtis Preston <cpreston AT GLASSHOUSE DOT COM> 
Sent by: EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
08/19/2008 06:21 PM
Please respond to
EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>; Please respond

to
Curtis Preston <cpreston AT GLASSHOUSE DOT COM>


To
NETWORKER AT LISTSERV.TEMPLE DOT EDU
cc

Subject
Re: Query in Staging from adv_file






So an AFTD can service multiple concurrent restore requests, but can't 
service multiple destaging/cloning requests?

I still say the VTL is easier.  The difference is that a backup
associated 
with a given AFTD can only be cloned/destaged by the AFTD that stored
it, 
where a VTL allows any-to-any relationship of virtual drives.

If I have 20 virtual tapes and 20 virtual drives, I can clone/destage
them 
all at once, regardless of how many drives were used to create them.  If

an AFTD can only clone/destage one backup at once, and I want to be able

to destage 20 AFTD backups, I have to make sure that each of them is on
a 
separate AFTD.  I don't think that's even possible, let alone practical.

Am I missing something?

Curtis Preston  |  VP Data Protection  
GlassHouse Technologies, Inc.
 
T: +1 760 710 2004 |  C: +1 760 419 5838 |  F: F: +1 760 710 2009  
cpreston AT glasshouse DOT com |  www.glasshouse.com
Infrastructure :: Optimized

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On

Behalf Of Preston de Guise
Sent: Tuesday, August 19, 2008 3:48 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Query in Staging from adv_file

On 20/08/2008, at 8:35 AM, Stan Horwitz wrote:

> On Aug 19, 2008, at 6:16 PM, Curtis Preston wrote:
>
>> Well, that significantly decreases the value of AFTDs over VTLs in
>> NetWorker, now doesn't it?
>
> I have no experience with a VTL, but my impression is that you get 
> the same functionality as physical tape drives, but on disk. If so, 
> doesn't that limit the amount of streams that can be read from a 
> virtual tape to just one session at a time, or does it parlay the 
> fact that multiple local tapes can be serviced concurrently in a VTL?


In theory it doesn't make AFTDs any worse than VTLs, since neither 
scenario supports more than one staging operating reading from the 
same volume at the same time.

However, in practice VTLs will normally be configured such that there 
are a high number of virtual tape drives and a high number of smaller 
sized virtual volumes, making it possible to execute more concurrent 
reads than either a conventional PTL or a AFTD.

I wouldn't however say that it significantly decreases the value of 
AFTDs over VTLs in NetWorker - it entirely depends on what your needs 
are. In an environment that requires high levels of recovery 
activities, AFTDs may still win out over VTLs - e.g., a previous 
customer of mine had a configuration that required 400-600+ recoveries 
per working day (i.e., an 8 hour period each day); in this sort of 
scenario AFTDs with their ability to allow as many concurrent recovery 
sessions as requested are of course King.

Cheers,

Preston.

--
Preston de Guise


"Enterprise Systems Backup and Recovery: A Corporate Insurance 
Policy", due out September 17 2008:

http://www.crcpress.com/shopping_cart/products/product_detail.asp?sku=AU
6396&isbn=9781420076394&parent_id=&pc=


http://www.enterprisesystemsbackup.com

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



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