云备份经由 VPN 很慢：先找出真正卡住的阶段

一份经由 VPN 爬行的备份，很容易让人做那个显而易见的实验：断开隧道再测一次。可这个实验往往回答的是另一个问题，因为任务可能正在给文件算哈希，或者在等重试，而不是在搬字节。先把阶段分开，抱怨就会变成一个有明确预期结果的明确测试。只有当真正慢的是传输阶段时，路由才值得怀疑。

感觉慢的时候，任务处在哪个阶段

备份工具要经过若干阶段：发现文件、读取并计算哈希、压缩、加密、上传，最后校验。每个阶段都有自己的瓶颈，而真正碰到网络的只有其中一部分。一个还没报告任何阶段的工具，其实是在告诉你它还没扫完。

花二十分钟准备上百万个小文件的任务，不会因为隧道变快而变快。把上行链路打满的任务是容量问题，解法完全不同。延迟发生时去读进度输出，记下阶段和时间戳，因为抱怨那一刻所处的阶段才是唯一有意义的。小文件的表现也和大对象不同：逐文件的往返占主导，传输永远达不到稳定速率。在对隧道下结论之前，先拿同类和同类比。

公网端点和私有 NAS 的失败方式不同

公有备份服务自带经过认证的应用连接，隧道只是更长路径上的一跳。私有 NAS 通常要靠这条隧道才能进入你的网络。这个差别决定了断开隧道到底是有意义的基线，还是在测一个不存在的东西。

公有场景下，如果策略允许，同一任务走另一条路径可以是公平的比较。私有场景下，去掉隧道就根本没有通往服务器的路，于是结果描述的是你删掉的那条路，而不是你在用的那条。

卡住和传输慢是两种不同的故障

那张表的第三列决定了稳定性测试能不能做，因为去掉隧道的基线只在存在另一条路的地方才有意义。有了可用的基线，要看故障的形状而不是平均速率。低而平稳的上传指向容量，而停了又重启的任务指向中断、认证或某个难缠的文件。这两者产生的抱怨几乎一样，修法却完全不同。

重试会扭曲任何测量，因为线路上跑的字节可能比真正变化的量更多。再打断任务观察结果之前，先读懂续传行为，因为分块可续传的上传恢复起来很便宜，整文件重来则不然。每隔几分钟重连一次的隧道，看起来也像带宽问题，其实是稳定性问题。路径 MTU 会让情况更糟：隧道压低可用载荷后，大段会卡住，小段却能通过。

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

一次上传就能饿死其他所有流量

把上行链路占满的上传会让通话和浏览失去响应，而备份很少是唯一在抢它的东西。第二个同步客户端自己就能制造同样的症状。怪隧道之前，先看看还有什么在上传。

与其去争峰值吞吐，不如用工具文档里写明的计划任务或带宽上限；给交互式工作留出余量，通常比最后那几个百分点更有价值。然后要确认这个上限到底管什么，因为有些工具按文件限制，有些限制整次运行，还有些完全忽略小文件的额外开销。和负载不匹配的上限什么也改变不了。分流隧道在这里同样可疑，因为把启动器排除在隧道之外，并不等于排除了执行上传的辅助服务。以 Rclone 为例，它把传输限制和重试行为都写在文档里，正好可以作为“限制该管什么”的参照。

用恢复收尾，而不是测速

上传完成并不等于备份，除非能从里面恢复出东西。先确认期望的版本存在，再按工具文档里的流程恢复一个代表性文件。把恢复所需的信息放在你可能会丢的机器或配置之外，也不要为了实验整洁就扔掉一份能用的备份。

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

网络改动之后，传输和恢复都要重做，这样才能说明改进是在服务备份，而不只是把数据搬得更快。正是第二遍运行才能关掉工单。恢复没测过就只把传输变快，只是以更慢的方式继续没有保护。