Networker

Re: [Networker] Networker VCB vs filelevel

2010-04-06 08:30:55
Subject: Re: [Networker] Networker VCB vs filelevel
From: James Pratt <jpratt AT NORWICH DOT EDU>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Tue, 6 Apr 2010 08:28:21 -0400
>> -----Original Message-----
>> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
>> On Behalf Of kel AT STERIA DOT DK
>> Sent: Tuesday, April 06, 2010 4:14 AM
>> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>> Subject: [Networker] Networker VCB vs filelevel
>> 
>> Hi there
>> 
>> Being alone with backups, I could use some sparring on the subject of
>> image backups with networker or just normal filelevels.
>> 
>> Seems to me the VCB is redundant, save for the offload part, if you
do a
>> normal file backup includning VSS, you could just deploy a new
virtual
>> machine and restore everything back into that, instead of doing the
image
>> backup and then do the file restore.
>> Applications like SQL exchange notes etc, will still be restored with
the
>> networker user module..
>> 
>> But am I missing something here ?
>> We have done serveral full restores, with the normal networker user
>> interface and it works fine, we rolled back a service pack install,
so as
>> far as I can see its a proven way to do it.
>> The VCB method, the new one in 7.6 is not stable yet, and while doing
a
>> restore of a full machine it crashed. So is VCB really worth the
extra
>> setup complexity ?
>> 
>> I realise the offload aspect is worth considering too, but is it
really
>> that bad ?
>> 
>> Any thoughts or experiences on this ? Am I missing something that
makes
>> VCBs worth the effort ?

Well here are my two cents, having done this for a few years now ....

VCB is by no means perfect (Zoning a windows box into your VMFS storage
group/luns is really pretty scary - and risky, so I've never liked that
aspect!), and is currently on the way out the door, to be replaced with
vsphere "Vstorage APIs" in Networker and other BUR products after
7/2010, but that's another topic... 

It really depends on your site/environment - for example, we have many
vms that are not "Standard", meaning the C:\ drives may not all be the
same size , and of course many other things that make the large majority
of our systems "unique".

In our case, it behooves us to utilize VCB for the following reasons:

Faster recovery in the case we do not have VM templates ready to spin up
for "BMR" / ALL recovery like you speak of - for example, our print
server bit the dust (Spooler wouldn't start, bad drives) in the middle
of the day last week - users and then the help desk freak out of course
- boom, I crash old server, export-vcb files out of nw, re-import using
VMware converter or the native (Yeah, not so hot yet in 7.6 or 7.5
built-in legato VCB restore function) back into vcenter - power it up -
BOOM - the old print server is back online, literally within a half hour
and no one even knows the difference ... So, in our case, it would have
taken literally a few hours to get a new vm built out - (We  also store
no templates for each vm due to storage constraints) before the "BMR"
recovery (Yes like you say it does work fine, but there is definitely
more involved, most importantly to us - the time to get it prepped prior
to restore is not worth it to us).

Another thing I like about VCB is that I don't even need to care or
worry about what version of windows it was I need to recover - R2, 2003
R2, 2003 SP2, etc) - as I said, boom, our print server was back online
in a half hour from the prior nights backup, and I still don't know or
care what specific version of windows it is/was...  

In our case, we run 99% virtual. We *really* don't want to pay for NW
client licenses per vm, so we purchased the Virtual ESX CAL's for every
ESX host in our cluster. Boom, instant savings on licensing going
further, and no worries on future growth, outside of normal storage
considerations/time-windows and the usual suspects affecting the whole
BUR environment in general.

I could probably come up with other reasons , as well as more
disadvantages too - And yes, you will want to use "All" and the modules
for your "important servers", such as Exch, SQL, AD, etc etc...  

Cheers,
Jamie

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