Proxmox Backup Server backups over high-latency links are significantly slower than the available bandwidth would suggest. This is not a configuration issue. Two independent bottlenecks in the network stack cap throughput far below what the link can carry. This page explains both problems and how our edge locations resolve them.
Key Takeaways
- PBS serializes chunk uploads behind round trips — each chunk waits for an ACK before the next is sent
- A single TCP stream cannot fill a fast link at high latency due to congestion window limits
- Edge locations solve the protocol bottleneck with a write accelerator that ACKs chunks instantly
- A TCP multiplexer splits traffic across parallel streams to overcome single-connection throughput limits
- Drop-in replacement: change the remote hostname, keep everything else
Problem 1: PBS Protocol Overhead
Proxmox Backup Server uses HTTP/2 over TLS for backup transport. During a backup, the client splits data into chunks (typically 4 MB for fixed-size, variable for dynamic) and uploads them individually. The protocol flow for each chunk looks like this:
- Client sends
POST /dynamic_chunk(or/fixed_chunk) with the chunk data - Server receives the chunk, writes it to the datastore, and responds
- Client receives the response, then sends the next chunk
This is a serial request-response pattern. The client does not send the next chunk until the current one is acknowledged. On a local network with sub-millisecond round-trip times, this is invisible. Over a WAN link, each chunk upload is gated by the full round-trip time.
With a 150 ms RTT (e.g. Canada to Frankfurt) and 4 MB chunks, the theoretical maximum is:
4 MB / 0.150 s = 26.7 MB/s ≈ 213 Mbit/s
In practice, PBS achieves less than this because the protocol involves additional round trips beyond the raw chunk upload — index appends, negotiation, and HTTP/2 framing overhead. We measured 44–67 Mbit/s on a link that iperf3 shows can carry over 1 Gbit/s.
This is not an HTTP/2 multiplexing issue
HTTP/2 supports concurrent streams, but the PBS backup protocol processes requests sequentially on the server side. Sending multiple chunks concurrently would create race conditions between chunk registration and index operations. The serial behavior is by design, not a limitation of the transport layer.
Problem 2: TCP Congestion Window
Even if the protocol were fully parallel, a single TCP connection cannot saturate a fast, high-latency link.
TCP uses a congestion window (cwnd) to control how much data can be in flight at any time. The maximum throughput of a single TCP connection is:
throughput = cwnd / RTT
The congestion window grows over time (slow start, then congestion avoidance), but it is bounded by the receive window, kernel buffer sizes, and packet loss. On a 150 ms path, a single TCP stream with typical Linux kernel defaults achieves around 200–250 Mbit/s even under ideal conditions. With any packet loss, the window collapses and recovers slowly.
This is why iperf3 with a single stream measures 216 Mbit/s, but iperf3 -P 8 (8 parallel streams) reaches 1,040 Mbit/s. Each stream maintains its own independent congestion window, so the aggregate throughput scales roughly linearly with the number of connections.
PBS uses a single TCP connection for the entire backup session. Even if you remove the protocol serialization from Problem 1, this single-connection limit caps throughput well below the link capacity.
Measured Impact
We measured all combinations on a link between OVH BHS (Beauharnois, Quebec) and our Frankfurt datacenter:
Throughput Comparison
| Method | Throughput |
|---|---|
| iperf3 single stream | 216 Mbit/s |
| iperf3 -P 8 | 1,040 Mbit/s |
| PBS direct | 44–67 Mbit/s |
| TCP multiplexer only (no write accelerator) | 80 Mbit/s |
| Write accelerator + TCP multiplexer | 573 Mbit/s |
The TCP multiplexer alone improves things modestly (80 Mbit/s) because the PBS protocol serialization is the dominant bottleneck. The write accelerator alone would be limited by the single TCP stream. Both together eliminate both bottlenecks: 573 Mbit/s, an 8–13x improvement over direct PBS.
Resolution: Edge Locations
An edge location is a point of presence deployed close to your server. It runs two components that address each bottleneck independently.
Write Accelerator (solves Problem 1)
The write accelerator is a protocol-aware PBS proxy that sits on the edge node. It speaks the full PBS backup protocol (HTTP/1.1 upgrade to HTTP/2, chunk uploads, index operations, finish) and acts as the backup target from the client's perspective.
When your client uploads a chunk, the accelerator:
- Writes the chunk to a local NVMe spool
- Immediately returns success to the client
- Forwards the chunk to the real PBS server asynchronously, with up to 64 uploads in parallel
Your client never waits for a Frankfurt round trip. It runs at the speed of the local link to the edge node.
Not all operations can be ACKed instantly. Index closes, finishes, and appends act as barriers — they block until all pending chunk forwards have completed. This preserves protocol correctness: a backup only reports success when every chunk is confirmed stored in the datacenter.
TCP Multiplexer (solves Problem 2)
The TCP multiplexer splits the single connection between edge and datacenter into N parallel TCP streams (default: 8). Each stream maintains its own kernel congestion window. Traffic is distributed across streams using round-robin with a framed protocol (16-byte header: sequence number, length, flags).
The aggregate throughput scales with the number of streams:
8 streams × ~125 Mbit/s per stream ≈ 1,000 Mbit/s theoretical
In practice, we see around 800 Mbit/s through the multiplexer (measured with a built-in benchmark mode), which is close to the iperf3 -P 8 result of 1,040 Mbit/s.
Why Both Are Needed
| Component | Write Accelerator | TCP Multiplexer | Both together |
|---|---|---|---|
Solves | Protocol serialization (Problem 1) | Congestion window limit (Problem 2) | Both bottlenecks |
Without it | Client waits for each chunk round trip, throughput capped at ~60 Mbit/s regardless of TCP parallelism | Single TCP stream caps at ~216 Mbit/s even with instant local ACKs | 573 Mbit/s measured |
Available Edge Locations
| Location | Beauharnois, Quebec |
|---|---|
Region | North America |
Hostname | bhs1-1.edge.pbs-host.de |
Use when your servers are in | Canada, US East, US Central |
Edge locations are included at no extra cost. If you need a point of presence in a region not listed here, contact us and we'll evaluate adding one.
Setup
Connecting through an edge location requires a single change: replace the remote hostname in your Proxmox Backup Server configuration with the edge location hostname. Credentials, encryption keys, datastore names, and all other settings remain unchanged.
Connect Through an Edge Location
Check your latency
Run ping fra1-ingress.pbs-host.de from your server. If your RTT is above 50 ms, an edge location will improve throughput.
Pick the nearest edge location
Find the closest location in the table above.
Update your remote hostname
In the Proxmox Backup Server UI (Datastore → Remotes), change the Host field to the edge hostname, e.g. bhs1-1.edge.pbs-host.de. Keep the same port, user, password, and fingerprint.
Verify
Run a backup or sync job and check the task log. You should see significantly higher transfer rates compared to the direct connection.
Fingerprint verification
The edge location terminates TLS with its own certificate. You may need to update the fingerprint in your remote configuration. The fingerprint is shown when you first connect, or you can retrieve it by running proxmox-backup-client info --repository against the edge hostname.
When It Helps
Edge locations improve throughput when the bottleneck is latency, not bandwidth. This typically applies when:
- Your round-trip time to Frankfurt is above 50 ms
- You have 100 Mbit/s or more of available upload bandwidth
- Your backups transfer meaningful amounts of data (large VMs, frequent changes)
If you are in central Europe with sub-20 ms latency, the PBS protocol overhead is negligible and your link bandwidth is the actual constraint. An edge location will not help in that case.
Failure Behavior
If the edge location loses connectivity to the datacenter during a backup, chunks already spooled locally will not be confirmed. The next barrier operation (index close or backup finish) will fail, and the client will report the error. No partial or corrupt backup will be recorded. Retrying the backup will work normally once connectivity is restored.
If the edge location itself is unreachable, point your remote back at the direct hostname. Your backups continue at the lower direct speed. Edge locations are an optimization, not a dependency.
Wrapping Up
PBS backups over high-latency links hit two independent bottlenecks: protocol-level serialization that gates each chunk behind a round trip, and TCP congestion window limits that cap single-connection throughput. Edge locations address both with a write accelerator (instant local ACKs with async forwarding) and a TCP multiplexer (parallel streams with independent congestion windows). The result is an 8–13x throughput improvement on our Canada-to-Frankfurt path, with no changes required beyond swapping a hostname.
Backups slower than your connection allows?
Connect through an edge location and back up at near-LAN speeds. No extra cost, one hostname change.
View Plans