我刚刚设置了一个 Debian 服务器来备份 Windows PC。我目前正在测试各种方法，包括：同步（在 Windows 上使用 Deltacopy），中小企业通过 Samba 和SCP。目前，rsync（不使用 SSH 且不压缩）和 scp 在千兆 LAN 上传输 9 GB 的文件大约需要 16 分钟。但是 SMB 只需要几分钟。为什么 rsync 特别慢？我觉得我可能误解了 rsync 的真正好处，即只传输更改的位。但是我仍然觉得它不能解释最初传输速度慢的原因，我一定是做错了什么。
我在所有实例中都转移到我的 Linux 机器上的 Samba 共享。
答案1
问题在于 rsync 使用文件的修改时间和大小作为快速参考来判断文件是否已更改。有一种更详细、更精确的方法来检查文件是否已更改，rsync 也支持这种方法，但是，如果文件的修改时间和大小首先推迟，则这些“更详细”的检查将被跳过，然后 rsync 假定文件已更改，因此尝试复制整个文件。
具体来说，当处于异构环境（Windows+Linux，...）中并且不在本地文件系统上工作时（即当使用 SMB 挂载/共享或其他协议时），存在修改时间无法在 rsync 源和其目标之间正确传递的可能性。
很可能修改时间被四舍五入或者被所使用的操作系统和/或网络协议以其他方式改变，因此看起来有所不同（即使只是稍微不同，即使本地文件系统具有“正确的”修改时间）。
请检查是否可能存在这种情况，并通过命令行（如果可能）和“stat”（Linux）等实用程序或绝对必要的 perl/python 小程序进行测试，输出精确的修改时间通过操作系统和本地文件系统属性传播（最终绕过任何网络协议，如 Samba）。
unix 下“stat”实用程序的示例输出：
$ stat somefile.txt
File: `somefile.txt'
Size: 1014 Blocks: 8 IO Block: 4096 regular file
Device: 805h/2053d Inode: 1448800 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2012-07-21 17:20:33.548997182 +0530
Modify: 2011-08-16 23:27:19.648480473 +0530
Change: 2011-08-16 23:27:19.648480473 +0530
您的 rsync 命令不可能一直需要“16 分钟”左右。这没有任何意义。通常，每次运行前后的差异越小，rsync 就越快。只有 scp将要每次运行它都会花费一个常数时间，具体取决于复制量。因此，这个事实，加上您已经排除了压缩和加密（ssh）可能是性能瓶颈的事实，确实让我假设修改时间比较可能存在问题。
我自己在 Synology NAS 上安装 Samba 时就遇到过这种情况。不过，无论你是否也遇到这种情况，我希望你能尽快找到问题的真正原因。
玩得开心。