Video Screencast Help
Give us your opinion and win with Symantec! Please help us by taking this survey to tell us about your experience with Symantec Connect, so that we can continue to grow and improve.  Take the survey.

NetBackup 7.0.1 SAP backups slowness running two differente jobs

Created: 15 Feb 2013 • Updated: 15 Feb 2013 | 2 comments

Hi all,

  thanks in advance for any help you give me.
I'm running a NetBackup 7.0.1 solution based on a master/media server (with 10T) on RHEL 5.4 and two other media with same storage again on RHEL.
Clients are all windows (2k8,2k8R2 and 2k3).

Policies i've set are for OS (inc/full)  and SAP (full/arch logs).
Target MEDIA are configured as load balance for specific policies, but this is not the major issue.

Well, for all the SAP policies, that use brbackup (started by a script .bat on the client) i found something strange.

The case is for two different servers , called SVR1 and SVR2.

SVR1 into the same network of the media, SVR2 into another network, always reachable, but with low bandwidth (trough FW to be precise).

The strangeness is regarding the throughput when the backup starts, because even if the speed of SVR2 is clear to be not so high due the FW in the middle, also the SVR1 lowered the speed for the time they are running in parallel !

Then, after SVR2 finish the backup, because it is not so big, the SVR1 start to raise speed until the up limit of the network.
I've tested it several times, with several servers, SAP backups are always so, it seems to be a real "behaviour", but not clear for me.

The only workaround i found it is to run SVR2 before and let finish it alone, then start SVR1 alone again after any other.
That is the strategy i've adopted also for other backup for SAP where same server are on different network, or for any other reasons different bandwidth exists.

In other words, SAP backups need to be runned alone, one server by one, first start, then finish, second start, then finish, third...and so on.
Of course this create a lot policies and overlap of BU window is easy to hit, definitively more complexity to manage.

Does anyone know if it is a real issues that can be solved or addressed differently?

Is it possible within a policy to start a server before another and not overlap them?

"Limit job per policy rule" is not what i'm asking for, because since there 4 streams for single server, it appears that sometime , randomly, one server start 2 streams, the other too,and the remaining streams are into the queue.

Not a real solution.

Thank you.


Comments 2 CommentsJump to latest comment

RamNagalla's picture

Then, after SVR2 finish the backup, because it is not so big, the SVR1 start to raise speed until the up limit of the network

this is normal, when multiple jobs are running all jobs shares the avaliable resources(along with network resources), once  jobs are getting compleated, the resources starts realasing and get assing to the active jobs.

that is what happening in your case as per the your above statement.

which is perfectly Normal.

Michele Nicosia's picture


  thanks for the answer.

Maybe i was not able to explain, i retry:

SVR1 and SVR2 are sharing 1Gbps backplane to MEDIA1 and MEDIA2.

SVR1 is on the same subnet 192.168.1.x to MEDIA1 and MEDIA2, then SVR2 into another subnet 192.168.2.x.

Right, i can imagine a troughput of 100Mb/s , to be conservative, and it is true because when SVR1 is running its jobs it is always near that speed (22Mb/s * 4 streams).

Ok, when SVR2 is  running WITH SVR1  i see 8 streams, 4 each, that runs around 3Mb/s!

3*8 = 24Mb/s for a load balanced storage configuration that with one client it run faster.

This is the problem, yes they share the same resources (along with network resources) but they are not using them as its best. Servers lower down speed until the lower one finish, and then SVR1 start to grow speed untilt the theorical up limit.

I hope i was more precise now.

Here what i would like to do is to fine tune to avoid low speed and use the maxium for every BU window, then if it possibile to start one server after another inside the same policy.

Thank you.