AFAIR the backup network just transports the data, not the metadata (CFI).

Consequently, if you have a lot of small files, ther could be no (big) difference.

Hello.

Could you provide more information about the environment?. You have a client connected via cross-cable to another server. This "another server" is the backup server?. If so, is the backup server the storage node for the client?. If so, where is the backup stored? What kind of device?.

You have to identify where the bottleneck is. Check CPU, memory, ethernet settings in client. Performance in backup device. Performance in backup server...

Q: Why the backup speed is not improving?

A: Insufficient information to answer question

Since you are using a cross over cable, there should only be the backup traffic on this cable.  However, NetWorker still communicates using the public network to transmit meta data information.

What are:

  1) access time for the data being backed up?

  2) What is the elapsed time for backups of this data set?

  2) network speed

  3) how many parallel streams are generated during backups

  4) what type of NetWorker devices are used to store the backup data

Access time refers to the time it takes for NetWorker to read the data through the file system.  This does not include network time to transmit the data.  To test this, you can use the following, which will essentially walk through the file system and tell you how long it takes.  No data will be send through the network.  For testing, just specify one partition of significant size

date; time save -s (server's ip of backup LAN) -n (path of data set) ;  date

Next test is to send a controlled set of data across the network to be written to the backup device. To test this, please refer to the NetWorker Perfomanace Tuning Guide, and test this using bigasm directive.  This will generated raw data and send this to the backup server to be saved.  For testing, specify a bigasm size to be the same as the previous test.  This elapsed time would represent the time needed to transmit the data *and* write the data to the backup device.  In addition, while backup is in progress, monitor the backup device for the write speed.  

These two tests should help you to better localize where the bottleneck is.

Please take a look at the NetWorker Perfomanace Tuning Guide for addition information.