Networker

Re: [Networker] Networker VCB vs filelevel

2010-04-07 09:07:37
Subject: Re: [Networker] Networker VCB vs filelevel
From: Chester Martin <cmartin AT SPP DOT ORG>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 7 Apr 2010 08:03:37 -0500
When we were running 7.5.1 I was using allvmfs for a few of the vms.  Allvmfs 
doesn't capture system state data, not sure if it does this in 7.6.  I just use 
the *FULL* saveset.

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On 
Behalf Of kel AT STERIA DOT DK
Sent: Wednesday, April 07, 2010 3:33 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Networker VCB vs filelevel

Ok, got it, VCB good for smaller servers, :) 

But what about the big file servers ? You run full image backup of them 
every day ? 

The offload is ok, but still takes time, it offloads the whole machine 
whenever you do a incremental or full backup... 

Gonna dig back into this, and have a look see, cause right now, while not 
100% convinced yet, I do some very good points :D 

The actualy load of the vm's is fairly low during off hours... But still 
wanna get a setup thats manageable, easy to recover in, for others too ;) 
And ALLVMFS file level recover to the storage node, does not look like the 
way to go, at least for now.

Damn so many chioces, so little time :D 

**************************************************
Med venlig hilsen / Regards
Kenneth Larsen
System Konsulent

Steria A/S
Tonsbakken 16-18
2740 Skovlunde
Mobile: +45 2630 6261
email: kel AT steria DOT dk
www.steria.dk
**************************************************



From:   James Pratt <jpratt AT NORWICH DOT EDU>
To:     NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date:   06-04-2010 15:48
Subject:        Re: [Networker] Networker VCB vs filelevel
Sent by:        EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>



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






------------------------------------------------------------------------------------
Med en omsætning på DKK 14 mia. og 19.000 ansatte er Steria blandt de ti 
førende it-serviceleverandører i Europa. Gruppen, som er repræsenteret i 16 
lande, herunder i Danmark med ca. 170 medarbejdere, leverer komplette løsninger 
inden for følgende fokusområder: Rådgivning, systemintegration og it-drift. Det 
betyder, at Steria bistår med alt fra forretnings- og it-rådgivning til 
projektledelse, systemudvikling og infrastrukturleverancer til drift, hosting 
og vedligehold. Yderligere oplysninger kan læses på www.steria.dk og 
www.steria.com.

This email originates from Steria A/S, Tonsbakken 16-18, DK-2740 Skovlunde - 
www.steria.dk. 
This email and any attachments may contain confidential/intellectual 
property/copyright information and is only for the use of the addressee(s). You 
are prohibited from copying, forwarding, disclosing, saving or otherwise using 
it in any way if you are not the addressee(s) or responsible for delivery. If 
you receive this email by mistake, please advise the sender and cancel it 
immediately. Steria may monitor the content of emails within its network to 
ensure compliance with its policies and procedures. Any email is susceptible to 
alteration and its integrity cannot be assured. Steria shall not be liable if 
the message is altered, modified, falsified, or even edited.

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