备份 2 个外部 HDD 时 cygwin rsync 速度慢
我编写了一个 shell 脚本来通过我的笔记本电脑备份我的外部硬盘。我基本上已将外部 HDD 连接到笔记本电脑的 USB 端口，并在脚本中运行以下命令将 1 个 HDD 备份到另一个 HDD。
rsync -arvv "$flg" --log-file="$LOGFILE" "$srcdir" $BAKUP_DIR 2> "$ERRFILE"
$ rsync --version
rsync version 3.0.9 protocol version 30
flg 是 --delete 或空格，具体取决于我要如何备份目录。我相信由于某种我无法理解的原因这很慢。我认为备份时传输了不必要的文件。当通过资源管理器查看时，我可以看到文件部分正在发送（并且不断增长），并想知道为什么会这样。
和日志文件...
grep -C 15 delta 2011-12-23-37_bk.log
2011/12/23 14:28:34 [8712] total: matches=0 hash_hits=0 false_alarms=0 data=2133674141
2011/12/23 14:28:35 [8712] sent 2133939896 bytes received 772 bytes 1854794.15 bytes/sec
2011/12/23 14:28:35 [8712] total size is 3901493999 speedup is 1.83
2011/12/23 14:28:35 [5072] building file list
2011/12/23 14:28:39 [5072] delta-transmission disabled for local transfer or --whole-file
这是正常的还是我遗漏了什么？
I've written a shell script to backup my external HDDs through my laptop. I've basically connected my external HDDs to the USB ports of the laptop and run the following command in the script to back up 1 HDD to another HDD.
rsync -arvv "$flg" --log-file="$LOGFILE" "$srcdir" $BAKUP_DIR 2> "$ERRFILE"
$ rsync --version
rsync version 3.0.9 protocol version 30
The flg is either --delete or spaces depending on how I want to back up the dir. I believe this is slow for some reason I can't fathom. I think it is transferring files unnecessarily when backing up. I can see file parts being sent(and growing) when viewed through Explorer and wondering why it is so.
and the log file...
grep -C 15 delta 2011-12-23-37_bk.log
2011/12/23 14:28:34 [8712] total: matches=0 hash_hits=0 false_alarms=0 data=2133674141
2011/12/23 14:28:35 [8712] sent 2133939896 bytes received 772 bytes 1854794.15 bytes/sec
2011/12/23 14:28:35 [8712] total size is 3901493999 speedup is 1.83
2011/12/23 14:28:35 [5072] building file list
2011/12/23 14:28:39 [5072] delta-transmission disabled for local transfer or --whole-file
Is this normal or is there something I'm missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我在最近安装了 Cygwin 的系统上遇到了完全相同的问题：rsync 太慢。使用 --progress 选项，我可以看到 rsync 在外部 USB 3.0 磁盘和内部磁盘之间仅以大约 2/3 MB/秒的速度传输文件。
在类似的系统上，相同的操作按预期工作（60/70 MB/秒）。
在尝试了很多事情之后，我意识到“rsync --version”在我刚刚安装了 Cygwin 的系统上是 3.0.9，在系统上运行良好时是 3.0.8。所以看起来 3.0.9 破坏了一些东西。
我将一个系统中的 rsync.exe (v3.0.8) 文件复制到另一个系统的 rsync.exe (v3.0.9) 上，现在文件以预期速度（60/70 MBytes/sec）传输。
I was facing exactly the same issue on a system were I had recently installed Cygwin: rsync was too slow. Using the --progress option I could see that rsync was transferring files at only around 2/3 MBytes/sec between an external USB 3.0 disk and the internal disk.
On a similar system, the same operation was working as expected (60/70 MBytes/sec).
After trying many things, I realized that "rsync --version" was 3.0.9 on the system were I had just installed Cygwin and 3.0.8 on the system were it was working fine. So it looked like 3.0.9 had broken something.
I copied the rsync.exe (v3.0.8) file from one system over the rsync.exe (v3.0.9) of the other system and now the files are transferred at the expected speed (60/70 MBytes/sec).
我有完全相同的问题，我也通过安装 rsync 版本 3.0.8 解决了它。但如果复制 .exe，您只需重新执行 cygwin 的安装程序即可。在包管理器中搜索“rsync”，安装程序仍然包含安装 3.0.8 的选项，这意味着您可以轻松地从 3.0.9 降级到 3.0.8。从那时起，一切都恢复正常和最大。速度。
I had exactly the same problem and I also solved it by installing rsync version 3.0.8. But instead if copying the .exe you can just re-execute cygwin's setup. In the package manager search for "rsync" the setup still contains an option to install 3.0.8, which means that you can easily downgrade from 3.0.9 to 3.0.8. From there on everything is back to normal and max. speed.
我在 Cygwin64 上使用 rsync 3.0.9 时也遇到了这个问题（~3MB/s 传输）。
Cygwin64 上不支持“返回”3.0.8，因为它不在存储库中。
不过，我下载了 rsync 3.1.0 并自己手动构建了它（只需要安装 gcc 和 make），这改进了很多。
我自己构建的 3.1.0 管理〜35MB/s。 Windows 资源管理器复制速度更快（大约 50MB/s），但我会接受！
I too was having this problem with rsync 3.0.9 on Cygwin64 (~3MB/s transfer).
Going "back" to 3.0.8 is not on option on Cygwin64 as it's not in the repo.
However I downloaded rsync 3.1.0 and manually built it myself (just need gcc and make installed) and this improved a lot.
3.1.0 built myself manages ~35MB/s. Windows explorer copy was faster (about 50MB/s) but I'll take it!
我也有同样的问题，rsync 传输速率约为 4MB/s。此速度由资源监视器和 rsync 的 -P 报告。它的任务是将约 200GB 的备份文件从一个驱动器复制到另一个驱动器，多年来，它通常需要大约 1.5 小时才能复制这些文件。虽然不是很快，但对我来说已经足够了。最近一定有什么东西坏了，毫无疑问是由于 Windows 系统的一些更新，因为我已经好几年没有更新 Cygwin 了。这项工作开始需要大约 14 个小时，这让我更仔细地审视它。我将一直使用的 x32 Cygwin 更新到最新（rsync 版本 3.1.0 协议版本 31）并安装 x64 版本的 Cygwin，看看它是否有任何区别。没有。
我认为这可能是其中一个硬盘驱动器出现问题，因此我确保两个硬盘驱动器都已完全进行碎片整理并清除了所有垃圾。然后我用“cp -au”替换了一直使用的“rsync -a”命令并测量了吞吐量。使用 cp，它的读取和写入速度约为 100MB/s，这是硬件支持的速度，并且在大约 30 分钟内复制约 200GB。所以 rsync 中的某些东西不太正确。
我的解决方法是放弃使用 rsync，转而使用 cp。预删除目标上的整个目录树并让 cp 复制一个全新的目录树比让 rsync 保持两个目录同步要快得多。可能有更好的选择，但这对我有用。
I have the same problem with ~4MB/s rsync transfer rate. This speed is reported both by the Resource Monitor and with a -P to rsync. It had been tasked to copy backup files of ~200GB from one drive to another and for several years it used to work taking about 1.5 hours to copy them. Not real fast, but good enough for me. Something must have broken recently and no doubt due to some update to the Windows system since I hadn't updated Cygwin in a several years. The job started taking ~14 hours which is what made me look at it closer. I updated the x32 Cygwin I had been using to the latest (rsync version 3.1.0 protocol version 31) and installed the x64 version of Cygwin to see if it made any difference. Nope.
Thinking it might be one or the other of the hard drives that might be going bad, I made sure both were completely defragged and cleaned of any garbage. Then I replaced the "rsync -a" command I had been using with "cp -au" and measured the throughput. With cp it reads and writes at ~100MB/s which is what the hardware supports and it copies that ~200GB in about 30 minutes. So something in rsync isn't quite right.
My workaround is to abandon using rsync in favor of cp. It is way faster to just pre-delete the entire directory tree on the target and have cp copy a whole new one than to have rsync do its thing to keep the two directories in sync. There's probably an even better option, but this works for me.