LiveUpdate - Is it useful?

[Ron_Cohn]

The number of servers I am administering is about to go from 140 to 500. This changes the dynamics of how to apply NBU patches. I read about LiveUpdate. Based on your experiences, is this a worthwhile approach or is there another method which works better? Many thanks in advance.

[_38]

For 7.6.0.3 the LiveUpdate containers hold all the files needed for distribution, for a larger environment it is likely the best option as you can trigger the updates via Policy.  Once launched the local host that is targeted for the update determines what set of files is needed on it's own.

More detail is available per Tech Note 217819 - http://www.symantec.com/docs/TECH217819

[Nicolai]

Yes - go for it.

You will see a sertain amount of client failing update, but it is no larger than normal updates. Plus it put you in control.

[Ron_Cohn]

Nicolai,

Since ours is a Windows environment, there appears to be several caveats that concern me.  Is your environment Windows or Unix?  More specifically, which type of OS do you run your LU server on?

[RonCaplinger · Accepted solution]

Absolutely worth the trouble, once you get it set up correctly.  It took me a few weeks to figure out everything I needed to do, including the proper setup of IIS on another of our NBU servers.

The alternative, because you are using WIndows, is you would have to log into 500 clients, copy files over to a temporary directory (just mounting the directory from another server and running the install from there doesn't always work), then run the installer and answer the prompts.

If you installed the NBU client using the "silentclient" batch file, be aware that the LiveUpdate files were likely not installed.  I'm not sure with any versions above 7.5, but LiveUpdate client was not automatically installed with the NBU client when you use "silentclient" batch file in prior NetBackup versions.

[Fabrice_P_ · Accepted solution]

My only concern about LiveUpdate is the lack of poss-install cleaning process on the client. The setup files are downloaded to /ProgramData/Symantec/LiveUpdate/Downloads but there is no post-install job to cleanup afterward...

This, plus the fact NetBackup keep all previous binaries on /Veritas/Patch can really eat a large amount of disk space... !

And if you multiply all of that by few hundreds or thousands of clients... 

With a custom install script you can remove all that files.

[J_MCCOLL · Accepted solution]

Fabrice, there should only be 4-6 patches per Netbackup version moving forward.  Therefore the footprint should be minimal, especially if you have logging turned off (best practice) when not required.

Using LU is beneficial when you have a large number of client machines.  Another useful advantage of using LU is when you have performed a Custom install initially on your client machine, those settings will be picked up and maintained.  (i.e. when performing an Exchange backup the NBU services use a Org Mgmt enabled account, these will be maintained).

[Fabrice_P_]

Agree, but I've seen machines with more than 5 GB on that Patch folder. This x 1000 clients means 5 TB of useless data. I would prefer those 5 TB to be used for valuable content.

[J_MCCOLL]

Agree Fabrice, but the footprint should only be around the 350 Mb mark (+ / - 100Mb) therefore should be no more than 2 GB if you clean up after each major release upgrade.  I agree that this is tiresome task but a cleanup after each new major release by script would recover that space.  It is always good to keep the binaries for the current verison on the system for role back as they may be required in the event of a bug or other problem.

[Ron_Cohn]

This was exactly what I was looking for (The Pros and Cons). I want to thank everyone for their input!

[Jim-90]

I would test it thoroughly on system where the NBU client is installed on the same drive as the OS. 

I've seen liveupdate fill up the OS disk during a run.   The last thing you want are live production systems go down becasue of live update.  We abandoned its use becasue of that - too many OS volumes too full.