Netbackup 7.x Bandwidth Trottling

[MOHAMED_PATEL]

Netbackup bandwidth trottling is limited to 10000KB, i.e 10MB/s - this is by design.

Can this limit not be increased to compensate for newer technology, or does changing changing the registry/bp.conf setting do the trick-

My scenario is backing up exchange 2010 DAG (passive node), where the client sends data so fast maxing it's interface and causing backup to fail with socket write errors. Hence, I have used bandwidth trottling to limit...

Limiting the bandwidth to 50/70Mb/s for now should work - LTO3 drives used.

There is nothing in the admin guides detailing the max usage but just an example.

[Nicolai · Accepted solution]

This is a fairly old tech note, but I think it' still valid:

http://www.symantec.com/docs/TECH30467

The last value is the amount of KB/sec you want the bandwidth throttled to. I do not see a 10MB/sec as restriction so changing the registry on the client should do the job.

[RiaanBadenhorst]

Well who would have thought going fast would ever be bad :p

Please try setting it to higher value in the registry and let us know if it works.

[Nicolai]

Have you checked if flow control is enabled on nic and switche?. Normal tcp flow control ensure data isn't send faster than the peer can receive them.

http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm

[UFO]

Agree. It is always botlleneck on the slowest part of the NBU chain but anyway - there is will be no overload when the channel is thin. Data will just go slower.

[UFO]

Mohamed, could you please clarify why you want "this limit not be increased"?

[RiaanBadenhorst]

Volo,

He asked why it cannot, or has not been increased, since the earlier release of the product when 10 or 100mbps was the standard in the indutry.

He requires a higher value for the limit

R

[MOHAMED_PATEL]

 Nicolai - nice link to TCP fundamental (simple) -

The client does not have a bandwidth setting - this change is only affected on the Master server.

Will check Flow Control setting - Currently Defaults are used.

Riaan - in the test lab (standalone and not clustered master) the setting (registry) can be changed to a higher value, which reflects correctly on the master - however when attempting to change the IP address range, it requires not more than 10000KB.

Services were happily restarted....no errors noted..yet

I will be testing the backup shortly and post progress.

[MOHAMED_PATEL]

Just on Limits -

Netbackup Version 6.5.6 allows a max of 32767KB - 32MB/s.

Netbackup 7.x has limit to 10000KB - 10MB/s

[UFO]

Oh, now I see :)

[MOHAMED_PATEL]

Have now changed the registry setting to 50000KB on a production system - clustered master - no problems with this so far...phew

limit registers as 50000KB in gui.

Now for the backup test.....

[MOHAMED_PATEL]

Backup runs at the desired speed......

Changing the registry setting for LIMIT_BANDWIDTH_USAGE for a client does go into effect when running backups.

i.e although the gui only allows upto 10000KB (10MB/s)(NB7.x) - the setting can be manually changed in the registry to whatever other value is required.

I guess with a bit of work, you will inevitably reach a solution.

Thanks ALL for the input.

Should this now be reported as a TWEAK or BUG..?

[RiaanBadenhorst]

Well done, you defeated the GUI :)

[CRZ]

Since you can set it outside the GUI and not with the GUI, I'd report it as a defect in the GUI and see if we'll build you an EEB to fix the GUI.

(DISCLAIMER: I'm assuming all this is supported - I can't imagine why it wouldn't be!)

[Marianne]

Seems that Nicolai's post called "old tecnote" deserves to be marked as solution?

Thanks for a very interesting topic, Mo!  I still learn something new everyday on this forum!

[MOHAMED_PATEL]

Agreed, Nicolai's research deserves the Solution -

There is no MAX limit that can be set when changing the registry for the value of LIMIT_BANDWIDTH. Tested, bearing in mind server NIC limit on both ends.

Will report as 'possible' bug/defect.

[UFO]

+1
Encourage everyone vote for this comment by Mo!

[Nicolai]

Very interesting finding you have. Thank for sharing this with us.