Cloud Backups Are Slow Over the VPN: Find the Real Phase

A backup that crawls across a VPN invites the obvious experiment of disconnecting the tunnel and measuring again. That experiment frequently answers a different question, because the job may have been hashing files or waiting out a retry rather than moving bytes. Separate the phases first and the complaint turns into a specific test with a specific expected result. The route only becomes a candidate once the transfer phase is the one that is actually slow.

Which phase is the job in when it feels slow

Backup tools run through phases: discovering files, reading and hashing them, compressing, encrypting, uploading, then verifying. Each phase has its own bottleneck, and only some of them touch the network at all. A tool that reports no phase yet is telling you it has not finished scanning.

A job that spends twenty minutes preparing a million small files will not speed up when the tunnel gets faster. A job that saturates the uplink is a capacity problem with a different fix. Read the progress output while the delay happens, note the phase, and write the timestamp down, because the phase at the time of the complaint is the only one that matters. Small files also behave differently from one large object, since per-file round trips dominate and the transfer never reaches a steady rate. Compare like with like before drawing conclusions about the tunnel.

A public endpoint and a private NAS fail differently

A public backup service carries its own authenticated application connection, and the tunnel is one hop on a longer path. A private NAS usually depends on that tunnel for basic reachability into your network. That difference decides whether disconnecting is a valid baseline or a test of nothing.

For the public case, the same job over another route can be a fair comparison when policy allows it. For the private case, removing the tunnel leaves no route to the server at all, so the result describes the path you deleted rather than the one you use.

A stall is a different failure from a slow transfer

The third column of that table decides whether a stability test can run at all, because a baseline that removes the tunnel only means something where another path exists. With a usable baseline, watch the shape of the failure rather than its average rate. A low but steady upload points at capacity, while a job that stalls and restarts points at interruption, authentication or one troublesome file. Those two produce nearly identical complaints and completely different repairs.

Retries distort any measurement, since the bytes on the wire can be larger than the amount that actually changed. Read the resume behaviour before interrupting the job again to watch what happens, because chunked resumable uploads recover cheaply and whole-file restarts do not. A tunnel that reconnects every few minutes also looks like a bandwidth problem when it is really a stability problem. The path MTU compounds this, since a tunnel that reduces the usable payload stalls large segments while small ones pass.

journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com

One upload can starve every other flow

An upload that fills the upstream link makes calls and browsing unresponsive, and the backup is rarely the only thing competing for it. A second sync client produces the same symptom on its own. Before blaming the tunnel, look at what else is uploading.

Use the schedule or bandwidth cap the tool documents rather than fighting for peak throughput, and leaving headroom for interactive work is usually worth more than the last few percent. Then check what the cap actually applies to, because some tools limit per file, some limit the whole run, and some ignore small-file overhead entirely. A cap that does not match the workload changes nothing. Split tunnelling deserves suspicion here too, since excluding the launcher from the tunnel does not exclude the helper service that performs the upload. Rclone, for one, publishes both transfer limits and retry behaviour in its documentation, which makes it a useful reference for what a cap should control.

Finish with a restore, not a speed test

A completed upload is not a backup until something restores from it. Confirm that the expected version exists, then restore a representative file using the procedure the tool documents. Keep the recovery information somewhere other than the machine or profile you might lose, and never throw away a backup that works just to keep an experiment tidy.

restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts

Repeat both the transfer and the restore after the network change, so the improvement is shown to serve the backup rather than merely to move data faster. That second run is what closes the ticket. A faster transfer with an untested restore is a slower way to stay unprotected.