A VERBOSE bptm log would be helpful.

Let's think about what's different between ufsdump and NBU to see if
we can find a bottleneck.  Judging from the horrible 200KB/s, I doubt
altering the NBU buffer size is going to help at this point.  NBU has
to catalog what it backs up.  This data is sent from the client to the
media server to the master, and then written to disk.  This gives us a
couple places to look (network and disk).  With 200-300KB/s, I usually
find network errors, so I'd start there.

Another thing NBU has to do is process exclude_list.  Got one?  A
poorly chosen set of rules can add a lot of processing.

Just to help isolate things, you may want to run this on the same path
you're doing ufsdump:

# timex bpbkar -dt 0 -r 8888 -nocont <path> > /dev/null

Lawrence Billson writes:
> Hi guys,
>       I'm getting some pretty poor performance from my Netbackup setup. My 
> current system is:
> 
...
> 
> Everything appears to _work_, it's just going unacceptably slowly. We can 
> achieve approx. 10Mb/sec to the tape units using ufsdump, when we run stuff 
> over netbackup, we get 200kb/sec. It takes a couple of hours to back up a 
> 2gb file system:-x
> 
> 
> I'm 100% sure all data is running over the SAN, I am sure of this as only 
> the server I'm backing up has any tape IO activity. I've also run a sniffer 
> over the ethernets and there is not a huge amount of traffic between them. 
> I've also checked the lights on the SAN switch - only the server running the 
> backup and the fibre/scsi gateway's interfaces are active.
> 
...
> 
> Anyone got any ideas - defiantly a few beers for information leading to 
> resolution of this one.
> 

-- 
Larry Kingery 
"It's only work if somebody else makes you do it."  -- Calvin, to Hobbes