数据非常清楚了。让我给你总结：
诊断结论
你的备份任务 早下-百度（ID: 3852583489）已经跑了 13 小时，才完成 30/4220 个文件（993MB / 429GB）。
速度分析
文件 大小 耗时 速度
#1 13.9 MB 314秒 ~47 KB/s
#2 27.2 MB 341秒 ~80 KB/s
#6 163 MB 2068秒 ~81 KB/s
#17 80.6 MB 1004秒 ~82 KB/s
全程平均速率：~74 KB/s，不管文件大小，速度都稳定在这个范围。
对不加密备份日志（decrypt_files: 0），同样 260 个文件 8.4GB 的备份很快就完成了，decrypt_files 始终是 0。
根因判断
问题不在百度云、不在阿里云、不在 CPU（3%），而在飞牛 backup_cloud 的解密实现。
具体表现：backup_cloud 进程的解密吞吐量被固定在一个很低的水平（~80KB/s 封顶），像是：
解密使用了固定小 buffer — 比如每次只解密 64KB 一块，每块之间有额外的 IPC/rclone 通信延迟
解密链路走了 rclone RC 调用 — 数据先通过 rclone 下载，再通过 RC 接口解密，每次调用都要经过 Unix socket + JSON 序列化，开销巨大
没有流水线 — 下载和解密完全串行，不存在"边下边解"
建议方案
这个应该报给飞牛官方，backup_cloud 的解密通道明显有实现缺陷（100M 宽带跑出 80KB/s，差距 1000 多倍）
让他们确认解密路径是不是走了 rclone RC 的逐块调用而不是流式处理
