Slower performance with netbackup

The buffer settings are help on each media server.

<install path>\veritas\netbackup\db\config\SIZE_DATA_BUFFERS

and NUMBER_DATA_BUFFERS

Try a setting in SIZE_DATA_BUFFERS of 262144, see if that helps.  If it does, try setting of 64 in NUMBER_DATA_BUFFERS if the speed inreases, try 128 (NUMBER_DATA_BUFFERS) and see how it goes.

You will need to create the files, no need to restart servives, but these settings are picked up when a backup starts.

Regards,

 

Martin

NetBackup is an enterprise server with enterprise functionality.  I love BackupExec, but it's a closed system to tweaking and tuning.

NBU on the other hand can be infinitely quicker, when setup correctly.  This means buffer tuning, multi-streaming, and multi-plexing backups.  

An out of the box NBU install is junk.  Take the time to tune it and you'll be happier.

OK thanks, I'll give this a go. 

Here is an example. Buffers are like buckets, data is water. The client sends data (water) to the buffer (bucket) . The client starts send data to an empty buffer, the media server (bptm) then sends the data from the buffer,but only when it is full, to the tapedrive. If the buffers are small or there is a low number of them, the tape drive can empty them, quicker than they can be refilled by the client - hence low performance. The drive has to stop whilst waiting for the buffers to fill, called shoeshining, very damaging to both tapes and drives. If for this example we looked in the bptm log when the backup has finished we would see a line saying bptm waited xxx times for full buffer, delayed yyy times. When we have an issue say with the network between client and media server or speed the client can send data from its disks, we will see a large number of delays , each delay is 15 milliseconds . For a setup with poor performance, for a large backup it is not uncommon that all these tiny delays can add up to several hours in total, that is, several hours in which the backup was writing nothing to tape, it was waiting for data to be sent. I would estimate that the majority of systems I see are not able to send data to the drives quick enough (known as streaming) due usually to network performance. In many cases, lto drives are the wrong choice, as they are not designed to stop/ start, then are designed to stream. Problem is, the drives that can stop/ start without issues are much more expensive. The are ways around this, fix the performance issues is one, the second is to write the backups to a disk storage unit on the mediqvserver, then write it to tape afterwards. This ,above, is only a few examples, its a bit more involved when you consider all the possibilities. Also, as someone will probably point out, the county log, bpbkar also contains the line... Bpbkar waited xxx times for EMPTY buffer, delayed yyy times You really need to compare this line with the similar line as mentioned from hotly, if we see higher gales in the bpbkar line, it shows that bpbkar was waiting for bptm to write the data to tape, showing a problem on the media server side. This is rare I think, with correct tuning in place, poor performance is much more likely to be down to the client side. Martin Sorry for any typos, sent from phone

Not sure, I don't do backupexec, , but some of the code is similar, so the bpbkar process in nbu could potentially be similar to bexec It's not recommended to let nbu do the compression, due to overhead on performance, leave compression to the tapedrives, it will be much quicker. By the way, in case you ask, nbu has no control over how much data fits on a tape. It loads a new tape when the operating system tells nbu the tape is full. This info comes from the tapedrive firmware, via the tapedriver. In fact, netbackup has very little to do with tapedrives, tape operations eg, reading, writing, are carried out on behalf of nbu by the operating system. Martin

 

 

Thanks for taking the time to respond Martin.

I will enable BPTM log on the media server and the BPBKAR log on the client.

After reading through some of the performance and planning guide my understanding here is that: 

If the BPTM process is waiting for an empty buffer by a significantly large amount, then this indicates that data from the client is arriving to the media server quite quickly but it's not being written by the media server to the tape fast enough.  Therefore, in this case, increasing the size and number of data buffers should improve things.

Is my example correct?

Almost, bptm waits for a full buffer, bpbkar waits for the empty buffer, so a tapedrive issue would be seen on the bpbkar log. when the tuning is correct, this is rare and when I have seen this it has been a hardware issue. Martin

 

I'm a little confused :(  

So in the example where the client is reading data from the disk quickly and sending the data over the network to the media server, also very quickly, but the the backup write speed is still quite low, most likely the buffer settings are set too low.  In which case what would the bptm log say to indicate this?

Thanks again for all you help,

JB