通过smb加速rsync

我认为你对rsyncalgorithm有误解，应该如何应用这个工具。

Rsync的性能优势来自于delta传输 – 也就是只移动文件中的改变位。 为了确定改变的位，文件必须由源主机和目标主机读取，并且比较块校验和以确定哪些位被改变。 这是rsync的“神奇”部分 – rsyncalgorithm本身。

当你使用SMB安装目标卷并使用rsync从Linux“看到”的文件中复制文件作为本地源和本地目标（都安装在该机器上）时，大多数现代rsync版本切换到“整个文件”复制模式，并closures增量复制algorithm。 这是一个“胜利”，因为在增量复制algorithm的基础上，rsync会读取整个目标文件（通过NAS的连线），以确定文件的哪些位已经改变。

使用rsync的“正确方法”是在一台机器上运行rsync服务器，在另一台机器上运行rsync客户机。 每台机器都会从自己的本地存储器中读取文件（这应该是非常快的），同意文件的哪些位已经改变，并且只传送这些位。 他们的方式，你使用rsync额外的'cp'。 你可以用'cp'完成同样的事情，这可能会更快。

如果您的NAS设备支持运行rsync服务器（或客户端），那么您就可以开始工作了。 如果你只是想通过SMB将它安装在源机器上，那么你可以使用'cp'来复制这些文件。

以为我会把我的2p扔在这里。

我的兄弟刚刚在他的办公室networking上安装了Buffalo NAS。 他现在正在考虑异地备份，所以如果办公室烧毁了，至less他还有其他地方的商业文件（数百英里远）。

我的第一个障碍是让他拥有的VPS（一个小的Linux虚拟专用服务器，没什么太大的优势）作为VPN用户拨入他的宽带路由器（他使用的是DrayTek），这样它本身可以成为他的VPN，这样就可以直接以安全的方式访问NAS。 得到了sorting和工作出色。

接下来的问题是将文件从NAS传输到VPS服务器。 我开始做一个Samba安装，并遇到与您所描述的完全相同（甚至更糟糕）的问题。 我做了一个干运行的rsync，花了1个多小时30分钟来研究它将要传输的文件，因为正如Evan所说，在这种方法下，另一端不是rsync，所以它需要做很多备份系统调用/读取Samba安装（通过PPTP /隧道连接，往返时间约为40ms）。 完全不可行。

我并不知道Buffalo实际上运行了一个rsync守护进程，所以使用它，整个干运行对于总计50Gb的87k文件只需要1分30秒。 显然，要传输50Gb的文件（来自宽带链路上的NAS只有100k /秒的出站带宽）完全是另一回事（这将需要几天的时间），但是一旦初始的rsync完成，任何增量备份应该是减轻油脂（他的数据每天不会有太大的变化）。

我的build议是使用一个体面的NAS，支持rsync，由于埃文上面所说的原因。 它会解决你所有的问题。

是的，你可以加快速度。 您需要使源或目标看起来像一个远程计算机，例如通过将其定位为“ localhost: ”。

您声明您正在本地安装SMB共享。 这使得源或目标看起来像rsync的本地path。 rsync手册页指出，源和目标是本地path的副本将复制整个文件。 这在手册页中的“–whole-file”选项的段落中说明。 因此，deltaalgorithm不被使用。 使用“ localhost: ”解决方法将恢复增量algorithmfunction并加速传输。

这听起来像时间戳是你的问题，因为这个网页有关：

http://www.goodjobsucking.com/?p=16

build议的解决scheme是添加

 --modify-window=1 

到rsync参数。

闻起来就像你有一个更便宜的NAS。 它也可能来自您的networking带宽…

“标准”消费类networking存储服务器在IO方面的实力很弱，这就是你在这里要做的。 它也可能是一个廉价的交换机连接你的电脑和你的NAS，不够强大的处理所有的数据包正确。

试试这个吧，aleast给你10％的速度，你得到什么速度http://www.thegeekstuff.com/2009/09/linux-remote-backup-using-rsnapshot-rsync-utility/

有两个潜在的问题来源 – 要么使用不正确的comman线路选项，要么您的NAS有时间戳的问题（或两者:-)。 请检查此线程“rsync到NAS复制一切每一次”的更多信息。