Networker VMs backups takes long time

Start with understanding if the backup is configured as hotadd or NBD, ensure that CBD is enabled on VMWare.
Is it for backup of VM's that belong to a particular cluster or common over all ?

Usually, I'll take some fixed action to check it out. I can share them to make it easier for you to determine the problem.

1. Check your Networker Configuration: Ensure that your Networker server is configured correctly and that it has sufficient resources (CPU, memory, and network bandwidth) to handle the backup tasks.

2. Review Backup Window and Schedules: A congested backup window or conflicting schedules can cause backups to take longer than expected. Ensure that your backup schedules are staggered and that there's enough time allocated for each backup.

3. Verify VADP Configuration: Networker uses VMware's vStorage APIs for Data Protection (VADP) for backups. Ensure that VADP is configured correctly and that there are no issues with the proxies.

4. Check Networker's Parallelism Settings: The parallelism settings in Networker determine how many backup streams can run simultaneously. If this is set too low, backups can take longer.

5. Review the size and change rate of your VMs: Large VMs or VMs with a high rate of change can take longer to back up.

6. Check Storage Unit Performance: Even though you've already checked this, it may be worth checking again. Look for any signs of high latency or low throughput.

7. Look for Bottlenecks: Check for any bottlenecks in your network or storage that could be slowing down backups. This could be anything from a slow network link to a disk that's running at capacity.

8. Networker and vProxy Logs: Even though you've already checked the logs, it might be useful to have a second look for any errors or warnings that could indicate a problem.

9. VMware Performance: Check the performance of your VMware environment. Look for any signs of resource contention, such as high CPU usage, memory usage, or disk latency.

Hope it helps, good luck!

any result yet what might have been the matter? Assuming you backup towards a DD(VE), what kinda tests were performed to rule out the network for example, writing to the involved DD? Did you use the ddpconchck tool to perform write/read tests for example?

Also using Hotadd or NBD? Is the NW vproxy located on the same esxi cluster as the vm that needs to be backed up or is it using NDB between different clusters? Do all nodes have access to all datastores on the cluster they belong to, so to be able to leverage Hotadd?

Just saying it is slow, is not too helpful. The fact you are still running nw18.2, which is not supported anymore, also beckons the question how the infr looks like? Older vSphere enironment? And what kinda storage? VMFS or NFS? And if the latter what version NFS, as NFS v.3 can cause performance issues with vmware? Which can be seen when deleting the snapshot, taking way longer causing stunning of the involved vm.