Slow Netbackup 7.5 performance

Man of Honour
Joined
20 Sep 2006
Posts
35,563
Hi,

Apart from NUMBER_DATA_BUFFERS and SIZE_DATA_BUFFERS are they any quick wins for Netbackup 7.5?

Currently seeing transfer rates of around 30MB/s in an enterprise environment.

Master server - physical W2K3 R2, 16 cores, 16GB RAM
Media server - physical W2K3 R2, 16 cores, 16GB RAM
Clients - mainly VM guests running on ESXI 5.1 hosted on Gen8 Blades, some on older R900's. Storage is FC disk arrays.

I can't seem to spot where the contention is. I can get 250MB/s+ sequential read and write speeds using sqlio or other IO testing application. I can saturate the network connections when I test network throughput (1Gbit and 2Gbit). Yet when the backups are running, nothing of the following seems to show signs of bottlenecking:
Master server RAM, CPU, disk IO
Media server RAM, CPU, disk IO
Target backup VM RAM, CPU, disk IO
Any of the Cisco switches between boxes

AV has been turned off for the tests, doesn't seem to make much difference as I've spent hours defining exclusions.

Reason I'm testing the network is that the Netbackup servers have directly attached disk arrays and the Blades are on a FC 'SAN' type network.

I realise the storage is on the slow side, but I'd expect the best to be higher than the 30MB/s average I'm seeing. For info, on one physical client we see 80MB/s regularly, but another backup policy on this same box only gets 20MB/s. This leads me to believe that it's some form of a configuration issue, but I can't work out what. I've had limited success with adjusting NUMBER_DATA_BUFFERS and SIZE_DATA_BUFFERS to numbers widely circled on Netbackup forums but I still feel that there's room for improvement.
 
Last edited:
NetBackup is such a bear, even the support staff struggle to troubleshoot these kinds of problems.
 
I'm beginning to think the same. One of our sister sites tried Veeam and had huge increases in performance. Unfortunately we aren't able to do the same so need to persevere. I may see about logging a support call or registering on their forums.
 
Log a support call. Having been through this already, it can take weeks to get to the bottom of these sorts of issues.
 
Hi,

Apart from NUMBER_DATA_BUFFERS and SIZE_DATA_BUFFERS are they any quick wins for Netbackup 7.5?

Currently seeing transfer rates of around 30MB/s in an enterprise environment.

Master server - physical W2K3 R2, 16 cores, 16GB RAM
Media server - physical W2K3 R2, 16 cores, 16GB RAM
Clients - mainly VM guests running on ESXI 5.1 hosted on Gen8 Blades, some on older R900's. Storage is FC disk arrays.

I can't seem to spot where the contention is. I can get 250MB/s+ sequential read and write speeds using sqlio or other IO testing application. I can saturate the network connections when I test network throughput (1Gbit and 2Gbit). Yet when the backups are running, nothing of the following seems to show signs of bottlenecking:
Master server RAM, CPU, disk IO
Media server RAM, CPU, disk IO
Target backup VM RAM, CPU, disk IO
Any of the Cisco switches between boxes

AV has been turned off for the tests, doesn't seem to make much difference as I've spent hours defining exclusions.

Reason I'm testing the network is that the Netbackup servers have directly attached disk arrays and the Blades are on a FC 'SAN' type network.

I realise the storage is on the slow side, but I'd expect the best to be higher than the 30MB/s average I'm seeing. For info, on one physical client we see 80MB/s regularly, but another backup policy on this same box only gets 20MB/s. This leads me to believe that it's some form of a configuration issue, but I can't work out what. I've had limited success with adjusting NUMBER_DATA_BUFFERS and SIZE_DATA_BUFFERS to numbers widely circled on Netbackup forums but I still feel that there's room for improvement.
Hi, I work as a tech for Symantec. Yeah, you are on the right track... Have you seen this document ?http://www.symantec.com/docs/TECH18422 If you haven't, it might have some helpful tips.
Also, if you have opened a support case post your case # and I will reach out to the technician. If you haven't I very much recommend it.
 
Back
Top Bottom