我已经搜索过此选项，但只找到了涉及以下方面的解决方案自定义补丁。它没有显示在--help中并且找不到更多信息可能表明答案是“否”，但我希望得到证实。
是否可以展示文件传输总进度使用 rsync 吗？
答案1
现在有一种官方方法可以在 rsync 中执行此操作（版本 3.1.0 协议版本 31，已使用 Ubuntu Trusty 14.04 测试）。
#> ./rsync -a --info=progress2 /usr .
305,002,533 80% 65.69MB/s 0:00:01 xfr#1653, ir-chk=1593/3594)
我尝试使用我的/usr文件夹，因为我想要这个功能来传输整个文件系统，而且它/usr似乎是一个很好的代表性样本。
--info=progress2即使只是部分值，它也能给出一个不错的总体百分比。事实上，我的/usr文件夹超过 6 GB：
#> du -sh /usr
6,6G /usr/
并rsync花了很多时间扫描所有内容。因此，几乎所有时候我看到的百分比都是 90% 左右，但尽管如此，看到有些内容被复制还是令人欣慰的 :)
参考：
答案2
以下内容适用于 rsync 版本 3.0.0 及以上版本。下面描述的选项是在 2008 年 3 月 1 日发布的版本中引入的。
随着--info=进度2你也可以使用递归调用选项（或其更短的--无别名）来禁用增量递归。
这将在开始时构建整个文件列表，而不是在传输过程中逐步发现更多文件。由于它在开始之前就知道所有文件，因此它将提供更好的总体进度报告。这适用于文件数量 - 它不会根据文件大小报告任何进度。
这需要权衡。提前构建整个文件列表会占用更多内存，并且会显著延迟实际传输的开始时间。正如您所预料的，文件越多，延迟时间就越长，所需的内存也越多。
以下内容摘自 rsync 手册（来源 -http://rsync.samba.org/ftp/rsync/rsync.html)：
-r，——递归
这告诉 rsync 以递归方式复制目录。另请参阅 --dirs (-d)。从 rsync 3.0.0 开始，使用的递归算法现在是一种增量扫描，它使用的内存比以前少得多，并且在完成前几个目录的扫描后开始传输。此增量扫描仅影响我们的递归算法，不会更改非递归传输。而且，只有当传输的两端至少为 3.0.0 版本时才有可能。
某些选项需要 rsync 知道完整的文件列表，因此这些选项会禁用增量递归模式。这些选项包括：--delete-before、--delete-after、--prune-empty-dirs 和 --delay-updates。因此，当连接两端的版本至少为 3.0.0 时，指定 --delete 时的默认删除模式现在是 --delete-during（使用 --del 或 --delete-during 明确请求此改进的删除模式）。另请参阅 --delete-delay 选项，它是比使用 --delete-after 更好的选择。
可以使用以下方法禁用增量递归递归调用选项或其较短的--无别名。
也可以看看https://rsync.samba.org了解具体版本的差异（向下滚动并查看发布新闻链接）。
答案3
您可以使用“pv”（apt-get install pv使用 Debian 和 ubuntu）。我建议监控传输的文件数量，因为传输的数据量与文件大小无关，而是与源和目标之间的增量有关。并且计数文件将计算一个大增量和另一个小增量的相同进度。这意味着在任何情况下，ETA 估计都可能相差甚远。基于大小的 ETA 仅在您的目标为空时才有效，在这种情况下增量 == 源的大小。
一般的想法是从 rsync 为每个“传输”的文件发出一行，并使用“pv”计算这些行：
rsync -ai /source remote:/dest | pv -les [文件数] >/dev/null
我倾向于备份整个文件系统（出于多种原因），在这种情况下，您可以使用更便宜的方法df获取文件数量（而不是du在findrsync 完成后再次遍历源层次结构）。-x 选项似乎确保 rsync 停留在相同的源文件系统上（并且不会跟随其他内部挂载）：
rsync -aix /source remote:/dest | pv -les $(df -i /source | perl -ane'如果 $F[5] =~ m:^/:，则打印 $F[2]') >/dev/null
如果您想以一般方式计算 /source 中的文件数量，请使用find /source|wc -l（再次警告：可能会很慢并且 I/O 负担很重）。
答案4
对于长距离转会，我很乐意du -s在两边跑动。watch -n1 du -s即使我感到非常焦虑。
watch定期（此处为每 1 秒）执行命令（du -s此处）并全屏显示输出。