Skip to main content

TCP Optimization for a Hyper-V Backup from Houston to Paris:

  • May 15, 2026
  • 3 comments
  • 22 views

morgan.munck

Our company (based in Paris) was tasked with implementing a backup solution for a client located in Houston (United States), with the following objectives:
- Backing up the client’s Hyper-V to a Dell EMC DataDomain storage array located in our Paris data center.
- Local backup to a USB drive connected directly to the client’s Hyper-V.
- The Veeam proxy is the client’s Hyper-V

During the first full backup, we observed extremely long transfer times, far exceeding expectations. 

 


Technical Solution: TCP Window Optimization

Method for Calculating the Optimal TCP Window
To maximize throughput, we applied the following formula:
Optimal TCP window (in bytes) = Bandwidth (bytes/s) × Latency (seconds)

 

Link data:
Bandwidth: 1 Gbps = 131,072,000 bytes/s
Measured latency: 123 ms (0.123 s)

 

Calculation:
Optimal window = 131,072,000 × 0.123 ≈ **16,121,856 bytes**
We rounded this to 16,776,960 bytes (or 16 MB) to allow for a safety margin.

 

Note:
The default TCP window size in Windows is 65,536 bytes (64 KB).

 

The TCP window (or TCP Window Size) is a critical parameter that determines how much data can be sent before waiting for an acknowledgment (ACK). 
On a high-latency link (such as Houston → Paris), a window that is too small (such as the default one) becomes a major bottleneck, as it prevents the network from operating at full capacity.  

 

Modifying the TCP window via the registry:
To apply this change, we followed these steps:
Create a registry key on the Hyper-V server (proxy):Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowsSize
Value: TcpWindowSize
Type: REG_DWORD
Value: 16776960 (decimal)
Restart the server to apply the changes.

 

Increasing the TCP Windows Size can impact the network and affect other services by increasing latency or causing packet loss (VoIP, business applications, etc.). To prevent this, we have implemented throttling to limit bandwidth during business hours and avoid any impact during the day.

 


These changes have allowed us to reduce the time of the first full backup by 65%.

If you have encountered similar issues with Veeam or long-distance backup solutions, please feel free to share your feedback in the comments!

3 comments

coolsport00
Forum|alt.badge.img+22
  • Veeam Legend
  • May 15, 2026

I don’t really have to worry about long-range backups as I’m a customer, so it’s really neat to hear these kinds of solutions ​@morgan.munck . Geat post. Thanks for sharing!


AndrePulia
Forum|alt.badge.img+9
  • Veeam Vanguard
  • May 15, 2026

@morgan.munck Very well thought out. Many times, people forget to optimize things for those who are actually doing the hard work. :-) Well done.


Chris.Childerhose
Forum|alt.badge.img+21

Very interesting, as I would never have thought about looking at this piece of the puzzle. 😋

Thanks for sharing this one as I wonder if it would be similar with other Hypervisors like VMware, etc. 🤔