现场是这样的。跨机房千兆专线，备份脚本用 xargs -P8 并发跑 rsync，每条都带 –bwlimit=10m，iftop 里峰值冲到 80MB/s，白天业务访问明显变慢，运维以为是专线出了问题。
真正麻烦的地方在于，几个原因的现象几乎一样。–bwlimit 是单进程上限，八个 rsync 并行就是八倍，总带宽没人管；脚本从 crontab 起来，没有 cgroup 限制，和业务流量抢同一个出口；限速只作用在数据通道，文件列表和校验仍会占带宽。
动手时先看并发数和实际占用
ps -ef | grep -c '[r]sync'; iftop -n -P -t -s 5随后把并发降下来并分摊总额
xargs -P2 -I{} rsync -a --bwlimit=4m {} /backup/再往下换单进程多目录一次同步
rsync -a --bwlimit=10m --files-from=list.txt /data/ /backup/末了加 ionice 和 cgroup 给备份降权
systemd-run --scope -p IOWeight=50 -- rsync -a /data/ /backup/别只看报错消失，验证要多做一步。iftop 峰值稳定在 12MB/s 以下，备份耗时在接受范围内，业务侧接口 P99 回到备份前的水平。
这里还有个坑。限速要算总量不是算单条，脚本改并发时记得同步改数值；跨机房备份最好放在业务低峰，光靠限速挡不住瞬时突发。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。