Backup Copy job slow to smb share

[leonelferreyra]

I have one backup job incremental forever, that includes 22 vm, Veeam 11 running on a VM with local storage REFS disk (Vsphere on cluster 3 HPServer and a msa2050HPE as datastore), this backup runs nice 1 TB total used space run first full in 2 hours.
Attempting to have a secondary copy on a lan network share on a phisical server (1GB net) added as smb repository, get a super slow performance, the copy job takes 4 vms at the same time for processing, full processing rate 2 MB/s, Bottleneck Target.
Y know veeam doesnt just copy the files from my local repo to destination repo and proceses other stuff, but its insane that delay, its even slower than offloading to S3. If I copy paste the bvk from local to target repo the speed goes to 100MB/s.
Is this normal, and if this is the case, what type of secondary repository do you recommend me to have a 2d copy.

Thanks

[soncscy]

Heya Leonel,

While it's good you're testing, remember file copies are never good tests, even for a 'rough baseline'. The OS cheats a lot with caching and you will never get an accurate read unless you're pumping a huge amount of data.

Diskspd might help to establish a more accurate baseline, but I would check the topology:

1. What is the gateway set for the SMB share?
2. If it's automatic, double-check that a "good" gateway is being used, or manually set up up as close to the smb share as you can.

Basically remember it's not your Veeam server to SMB share directly, there has to be an intermediary that writes to the SMB share (it __can__ be the Veeam server, but afaik any added windows machine can be a candidate if automatic is used)

Having a dedicated gateway as close as possible to the SMB share is likely the answer here.

[leonelferreyra]

Thanks for the reply, I was just reading about dedicated Gateway when you answer, let me tell you that just tried to add the Windows Server with the repo share as gateway and mount for its repository, tested the copy job again and is going really nice, about 100/200 MB/s.
I guess that now I'll have to make tests and limit that traffic in case it gets too much bandwith and affects my network, really new to veeam, I guess I can limit this from de repo cfg
Thanks again for the reply, Sunday is the best day for testing.

[leonelferreyra]

Sorry other question, now my network is out of control, netwok upload on my veeam is on top 1GPS, where should I limit this traffic?
- Should it be at smb repository limiting concurrent task and bandwith?
-Should I create a network conection with especific veeam and smb repo ip from to ?
Thanks

[soncscy]

Heya, glad it worked out. I work with a lot of clients and the ones that do use SMB typically hit this; the short version of why this matters is that without the gateway close to the source of the SMB share, you're basically doing an inefficient connection as the target data mover agent potentially runs from a suboptimal location (the agent can't run on the share directly, it needs a gateway).

You have a few options:

Veeam has built in throttling between its data mover agents, but this is at the application level; it works, but if you can do it at the network level, I prefer it there. Else go to the Traffic Rules in the UI and you can set throttling between IP ranges even with time windows iirc.

Concurrent tasks aren't directly about bandwidth, they're more about resource usage on the given server. Things like transform operations, read operations, compression and dedup are what you can restrict with tasks and r/w operations.

[leonelferreyra]

Thanks for the quick update, Ill be playing with those settings to limit the use of the network, besides setting really close the schedule.