> I am running NetBackup FP 4.5 on HP-UX 11.i, master server is on an
> HP L2000, and this media server is on an HP N4000 with a SureStore
> 20/700 library using LTO-1 drives.  I created a policy that is doing
> a full backup, with cross mount points checked and limit jobs per

Hopefully you're not using cross mnt points with ALL_LOCAL_DRIVES.

> policy to 4.  Each mount point has about 175gb of data to be backed
> up. The policy kicks off 4 jobs as it should, but is taking 10 to 12
> hours to complete.  I looked in my bptm logs and am seeing the
> following:
>
> 05:00:51.795 [26600] <2> write_data: waited for full buffer 114308 times,
> delayed 131449 times 
> 
> 05:06:11.186 [26608] <2> write_data: waited for full buffer 117920 times,
> delayed 138141 times 
> 

These messages tell us that the tape drive had to stop writing a
number of times and wait for the input to catch up.  You can't really
quantify the amount of time based only on the above, except to say it
was at least an hour in total.  This gives us a clue as to where to
start looking to improve performance.

You don't mention whether this is a media server or client, network
speed, use of mpx, etc.  I suppose the place to start then would be to
measure how quickly the data can be read from disk.

# time ./bpbkar -dt 0 -r 8888 -nocont DISK-PATH > /dev/null

You'll probably want to try running this in various combinations
(e.g. one for each filesystem, concurrently and separately) to find
the best performance combination.  Also you might compare this to
using dd to read raw disk to analyze filesystem overhead.

>From there, assuming you can get better than 10-12 hours, move on to
analyze network, etc.

Avoid the common mistake of trying to "tune the buffers".  For
example, you COULD decrease the buffer size and probably make these
numbers go down.  However, all that would be doing is slowing the tape
drives down to the level of input.  This would make no performance
difference, which is really what you're after.

-- 
Larry Kingery 
            Enter any 11-digit prime number to continue...