I'm using Veeam Backup & Replication Community Edition 13.1.1.18 in a home lab with Veeam Agent for Microsoft Windows 13.1.1.700.
I'm seeing extremely poor performance with physical Windows Agent jobs configured as:
Server -> Managed by backup server -> Veeam backup repository
The problem reproduces on multiple physical Windows PCs.
The same machines perform normally when configured as:
Server -> Managed by agent -> Shared folder
The difference is enormous.
Example managed-by-backup-server test:
- Destination was a LOCAL NVMe repository on the VBR server
- Approximately 49 GB read
- Approximately 30 GB transferred
- Duration: approximately 4 hours 16 minutes
- Average processing rate: approximately 3 MB/s
- Veeam reported Network as approximately 99% of the bottleneck
The transfer frequently drops into the hundreds of KB/s or even tens of KB/s, with occasional short bursts of normal/high throughput.
I specifically tested a local NVMe repository to eliminate the NAS/SMB repository path. The same slow behavior remained.
For comparison:
- Raw SMB transfer from the affected endpoint to the VBR server reaches approximately 113 MB/s, essentially saturating the endpoint's 1 GbE connection.
- The VBR server can write to the normal NAS repository at over 400 MB/s.
- A Managed by agent backup from an affected endpoint directly to an SMB shared folder completed in approximately 9 minutes.
- During that fast Agent-managed backup, the main Windows volume was read at approximately 176 MB/s.
Troubleshooting already performed:
- Repository read/write rate limiting is disabled.
- Global Veeam network throttling is disabled.
- "Use multiple upload streams per job" is disabled.
- Protection Group -> Backup I/O control was changed to "Do not throttle agent".
- Explicit preferred backup network was configured for the normal LAN.
- None of those changes improved the Managed by backup server job.
- On one affected endpoint, Veeam Agent, CBT driver, Backup Transport and Installer components were completely removed and freshly redeployed.
- The problem remained.
- A second physical endpoint reproduced the problem.
- Writing to a local NVMe repository on the VBR server reproduced the problem, so the NAS and SMB repository are not required for the issue to occur.
I also captured the Managed by backup server traffic on TCP 6162.
During the slow periods, the endpoint repeatedly falls into a pattern approximately like:
1. Endpoint sends one TCP data segment.
2. Receiver ACKs it roughly 45-47 ms later.
3. Endpoint sends the next segment.
4. This repeats for extended periods.
That results in throughput in the tens of KB/s range.
The same TCP connection will occasionally break out of this condition and transfer at high speed for several seconds, then fall back into the one-segment/ACK pattern.
I did not observe:
- a sustained retransmission/packet-loss storm
- TCP zero-window conditions
- a consistently small receiver-advertised window
The receiver can clearly accept data rapidly during the high-speed bursts.
Target-side Veeam Data Mover logs also show it spending nearly all of its time waiting to receive data rather than processing or writing it.
The Agent-side logs contain:
Global network policy: LEDBAT enabled
and references to:
EndPoint.ForceBackgroundMode
EndPoint.StartPriorityUpdater
I'm not assuming LEDBAT/background throttling is necessarily the root cause, but it seems potentially relevant given the behavior on the wire.
Windows reports the active TCP 6162 connections as using the normal Internet TCP template with CUBIC. There are no custom Windows transport filters applied to the Veeam traffic.
At this point the issue appears isolated to the Managed by backup server / Veeam Data Mover transport path between the Agent and VBR server.
Has anyone seen this with VBR 13.1.1.18 / Veeam Agent 13.1.1.700?
In particular:
1. Is there a known issue or regression affecting Managed by backup server Agent transport performance in 13.1.1?
2. Is the "Global network policy: LEDBAT enabled" behavior expected for this job type?
3. Is there a supported way to temporarily disable Veeam's background/LEDBAT behavior for an A/B test?
4. Are there any known private fixes, registry values, or hotfixes for this behavior?
I have complete Agent logs, VBR job/Data Mover logs, and both a header-only TCP capture and the original packet capture available if a Veeam employee wants them. I have not attached them publicly because they contain local hostnames/usernames/environment information.
