Hi @saszhuqing  and welcome to the community. Do you have multiple IP addresses on the machine that you use as your repository? 

When the plugin communicates to the repo it will ask for all available IPs and tries them in the order returned. So let’s say you have two IPs on the repo: 192.168.100.100/24 and 10.10.100.100/24 and the traffic should flow over the 10. network.

If the returned IP list is 192.168.100.100, 10.10.100.100 ] the HANA plugin tries the first IP first. That traffic might flow via the default GW, blocked by some FW and the system does not get any response back, so it will wait for a timeout to happen - that takes a long time.

Only when these timeouts happened the plugin will try 10.10.100.100 and will connect to the repo and transfer the files.

It looks like your job is exactly this (because theres a long time nothing happening). 

If this describes your environment, please try to configure preferred networks in Veeam Backup & Replication. 

So for above example, you prefer 10.10.100.0/24 as a network and the returned IP list for the repository will be ordered d 10.10.100.100, 192.168.100.100 ]. That way the plugin will directly connect to the repo and the job duration will be smaller.

Hello,

Could you specify the % of your bottleneck? Source? Is it a same time to do the backint on local machine?

The processing rate is an average of your jobs, you should more consider “the speed” . We’re not using this plugins in my company for the moment but if it’s the same as RMAN, there is a lot checks did by RMAN before sending data. Maybe check logs of your running jobs in “%programdata%/veeam/backup”?

Hi, @StefanZi thank you very much, I set up a test environment, where there is only one IP, everything works well.

Back to my production environment, VBR have two IPs, one for the management network e 192.168.100.100] , and the other for the storage network a10.10.100.100] which don’t have GW . My storage device uses NFS protocol to provide datastore to ESXi hosts, so I used ‘Direct NFS Access’ mode and specifying preferred networks to the storage network.

However, I can’t modify the preferred networks, because there are a lot of VMs need to backup. Now, I think there are two ways to try:

1.Set up a new environment to backup SAP HANA, which have no problem;

2.Add an interface to HANA server, and configure an IP address in storage network, need to test.

Do you have any suggestion?

Preferred network will only come into play when Veeam components talk to each other. So even without this setting on the storage network your Direct NFS access will be fine. Basically we ask vCenter for the NFS datastores and we get back something like: 10.10.100.101:/vsphere and we will try to reach this from the proxies, so with the direct connected network that will still work perfectly.

So you can configure the preferred network to be the 192.168.100.100 which is reachable from your SAP system and you’ll be fine.

If you don’t want to touch the preferred networks, just make sure that if the SAP system tries to reach the 10.10.100.100 it get’s a proper not accessible message as fast as possible, e.g. by blocking access on a firewall (not dropping the package, but really blocking it) - can be the host firewall or the network firewall.

That’s great! Thanks very much for your help to solve my problem.

After I configure the preferred network to be the 192.168.100.100 which is reachable from SAP HANA server, VMs backup still use NFS ( I confirm this in veeam statistics and taskmgr-performance-Ethernet), and HANA databases backup works well too.

Have a nice weekend!