Bruno.Bossier AT comparex DOT be wrote, in part:
> We have a LAN client which is located at another site several kilometers
> from the site where the master server and the tape library are located.
> There is only a 2Mbit line between the 2 sites, so the backup takes a very
> long time. Actually, until now, it never ran completely because of network
> timeouts or because it was out of the time window or because it was
> cancelled by the owners.
> 
> What can I do to improve at least a little the performance ? I already
> thought of disabling OTM, setting the communications buffer size to 256
> (now 32). ANother thought would be to enable compression at the policy
> level. I know what the advantages and disavantages are of using software
> compression. What I would like to know is what happens if you use software
> compression and hardware compression at the same time ?

I'm new to NBU, but I'll offer ...

1. Don't send as much. Perhaps there are large static files that can be 
backed up less frequently?  Consider daily backup for only most 
important files and every other day (or week) for rest, breaking up 
remaining between the two days. If backups are frequently failing with 
time going unused, consider multiple policies so that you've got a bunch 
of small restartable backups instead of one or a few large backups.

2. Send it faster. Sometimes us software folks get caught up with 
software issues when it's a hardware problem.  First, have a networking 
guru study the line (under load); there may be adjustments s/he can make 
to get more out of your 2Mb connection.  Second, consider the need for a 
faster connection and possible solutions.  The guru just mentioned may 
be able to provide all the info you need, or at least get you started.

While it may be worth having NBU compress your data, I've yet to find a 
real life case where it helps.  If you have enough (remote) computing 
power and NBU is good enough at overlapping disk reading, compressing 
and transmission (it isn't, in my short experience), it might help. 
That your tape "hardware" also does compression just doesn't matter to 
this problem at all; it's not a problem in any sense.

If you change NBU settings (NET_BUFFER_SZ, NUMBER_DATA_BUFFERS, 
SIZE_DATA_BUFFERS, NUMBER_DATA_BUFFERS_RESTORE, TCP/IP stack) and see a 
difference (or don't!), please report here.  IMHO, Veritas and we need 
to discuss this area (and make improvements) more (Yes, I've read 
everything in sight!).  Some areas that I find incredible: (1) Veritas 
suggests "testing" since changing some of these values may cause 
restores to fail. (2) Veritas suggests some settings must be made at 
server and all clients; if a setting requires this, NBU should reflect 
the setting to the clients and use it automatically. (3) transmission 
buffers, NBU buffers, and tape I/O buffers aren't distinct and 
independent. (4) NBU apparently is unable to tune itself, simply using 
"one size fits all".

Has anyone written scripts to analyze NBU logs wrt performance issues? 
Are there any add-on products for this (or other) area(s)?

    (Must stop now ... have worn out parenthesis keys).
cheers, wayne
-- 

Wayne T. Smith -- WTS AT Maine DOT edu
University of Maine System -- UNET -- Systems Software Analyst