Yes, all excellent points as well! - I admit I am not much of a
"networking or a windows guy" so I tend not to take a lot of that stuff
into account, so thanks for explaining it all so well.
Also, thanks for that last "OCD" tip - I'm like that as well, but I
hadn't run into that one yet, even with lots of testing VCB restores in
test, but will be sure to do that moving forward! ;)
Regards,
james
>> -----Original Message-----
>> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
>> On Behalf Of Chester Martin
>> Sent: Tuesday, April 06, 2010 9:24 AM
>> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>> Subject: Re: [Networker] Networker VCB vs filelevel
>>
>> To add to that if you use filelevel, I'm guessing you're referring to
>> file level backups without using vcb, you backup each individual vm
on
>> the esx server. All the backup traffic goes through the one or more
>> network cards in the server. This can cause a bottleneck at the
network
>> level on the server with users accessing the vm's through the nic and
>> the backup going through the nic.
>>
>> If you use vcb, even if you use filelevel through vcb using "ALLVMFS"
in
>> the saveset it should go through the fiber connections. That's if
your
>> proxy server is also a storage node that's fiber connected to your
tape
>> drive device. Plus with 7.6 you can do an image level backup and do
>> either an image level restore or a file level restore from it
(windows
>> only). Plus it's faster in most cases to backup through fiber than
it
>> is to backup over lan.
>>
>> I agree with James that zoning your vcb server to be able to see all
of
>> your esx luns is scary, but in the long run it's worth it. Just make
>> sure you create your drive that the vm data will be held on before
you
>> zone the proxy server to be able to see all of the esx luns.
>>
>> Here's my ocd kicking in here ---> We also install the networker
client
>> on each vm, just in case the worst possible scenario happens and we
have
>> to backup each individual client. There have been times where we've
had
>> an issue with a particular vcb backup and it's taken a while to fix
(a
>> while being weeks). During that time we still get a backup of the
>> client because we use a file level non-vcb backup for it.
>>
>> -----Original Message-----
>> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
>> On
>> Behalf Of James Pratt
>> Sent: Tuesday, April 06, 2010 7:28 AM
>> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>> Subject: Re: [Networker] Networker VCB vs filelevel
>>
>> >> -----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
>>
>> 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
|
