networker one session speed

1. Network bandwidth: The speed of the network connection between the Networker client and server can affect the speed of a session. Make sure that the network connection is stable and that there is enough bandwidth available.

2. Networker Server configuration: The performance of the Networker server can affect the speed of a session. Make sure that the server has enough resources such as CPU, memory and storage to handle the backup load.

3. Backup data size: The amount of data being backed up can also affect the speed of a session. Larger backups will take longer to complete than smaller backups.

4. Networker client configuration: The performance of the Networker client can also affect the speed of a session. Make sure that the client has enough resources such as CPU and memory to handle the backup load.

5. Backup method: Networker uses incremental backups by default, but full backups can be faster. You can try to configure the client to use full backups.

6. Compression and encryption: Compression and encryption can also affect the speed of a session. If the data is already compressed or encrypted, the additional compression or encryption process can slow down the backup.

7. Tape drive speed: The speed of the tape drive can affect the speed of a session. If the tape drive is old or has a slow transfer rate, it can slow down the backup.

It is recommended to check all these points and make sure that all the configuration and resources are optimized to get the best performance. It is also recommended to contact Dell EMC Networker support for further assistance.

If you really want to know how fast your backups could deliver, may I suggest that you run an appropriate "bigasm" test to check the max. backup speed.

You should be able to find the info how to run such test in the "Performance Tuning Guide".

Later you can still change the other parameters.

This.

https://www.dell.com/support/manuals/en-us/networker/nw_p_performance_opt_plan/the-bigasm-directive?guid=guid-e7c3f0f5-799d-445f-bdb9-4b21bcb83fff&lang=en-us :

"The bigasm directive creates a stream of bytes in memory and saves them to the target device that eliminates disk access. This helps to test the speed of NetWorker clients, network, and the tape devices ignoring disk access."

See also https://youtu.be/ZPtBZoZqyx0 "NetWorker: How to Use the NetWorker Bigasm Directive"

As counter test, one can use uasm:

"The uasm directive tests disk read speeds, and by writing data to a null device can identify disk-based bottlenecks."

If and when using datadomain and the ddboost protocol, there is also the ddpconchk too, that can be used to perform write and read tests towards a DD system. Test data is generated in memory and hence that test rules out any disk contention as it doesn't have to read anything from disk at all. It is very good to be able to test network bandwidth, while ruling out disk to be a limiting factor.

If OP actually tells what we are even dealing with, like OS, amount of data, sort and amount of data and number of files (*), the backup medium.

(*) Whenever going into millions of files ranges, completely different speeds apply. For high density filesystems BBB, block based backups - only supported for Windows and Linux - would be very beneficiary, even much more so than PSS, parallel save streams).

For example when using ddboost towards a DD system, if client direct is supposed to be used, then NW will use the fallback mechanism to send data via the NW storage node that is configured to be used. That can also have a negative impact on speed achieved as data will be full-blown send to the NW SN and only deduplicated on the NW SN before being send to the DD.