Yes, smaller servers are perfect vcb candidates - No, we do not image any
servers >40gb , as it will take extra san space (Double the space of the
existing vm you wish to backup - that's how much you will need free, so it's
not practical for large servers obviously as you need snapshot space, as well
as space on the proxy). We still use the "All" fs saveset in these types of
vm's, or we use NW modules where appropriate.
I agree, so many choices indeed, but that is a good thing! :))
>> -----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 4: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
|
