inc*_*to2 10 rsync file-transfer
我正在尝试传输大约 10 万个文件，总共 90GB。现在我正在使用 rsync 守护进程，但它的速度很慢，只有 3.4mb/s，我需要多次这样做。我想知道我有哪些选项可以最大程度地通过互联网实现 100 兆位的连接并且非常可靠。
cee*_*yoz 11
你考虑过Sneakernet吗？对于大型数据集，隔夜运输通常比通过 Internet 传输更快、更便宜。
bah*_*mat 11
我发现最快的方法是组合tar,mbuffer和ssh。
例如：
tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"
使用它，我在 1Gb 链接上实现了超过 950 Mb/s 的持续本地网络传输。替换每个 tar 命令中的路径以适合您要传输的内容。
到目前为止，通过网络传输大文件的最大瓶颈是磁盘 I/O。答案是mbuffer或buffer。它们在很大程度上相似，但mbuffer具有一些优点。默认缓冲区大小为 2MBmbuffer和 1MB buffer。较大的缓冲区更有可能永远不会为空。选择目标文件系统和目标文件系统上本地块大小的最小公倍数的块大小将提供最佳性能。
缓冲是让一切变得不同的东西！有的话就用吧！如果你没有它，得到它！使用(m}?bufferplus 任何东西都比任何东西本身都好。它几乎是解决慢速网络文件传输的灵丹妙药。
如果您要传输多个文件，请使用tar将它们“合并”到一个数据流中。如果它是单个文件，您可以使用cat或 I/O 重定向。tarvs.的开销在cat统计上是微不足道的，所以我总是使用tar（或zfs -send在我可以的地方），除非它已经是一个tarball。这些都不能保证为您提供元数据（特别是cat不会）。如果您需要元数据，我会将其留给您作为练习。
最后，ssh用于传输机制既安全又带来很少的开销。同样，sshvs nc.的开销在统计上是微不足道的。
您提到了“rsync”，所以我假设您使用的是 Linux：
为什么不创建 tar 或 tar.gz 文件？一个大文件的网络传输时间比许多小文件快。如果你愿意，你甚至可以压缩它......
没有压缩的焦油：
在源服务器上：
tar -cf file.tar /path/to/files/
然后在接收端：
cd /path/to/files/
tar -xf /path/to/file.tar
带压缩的焦油：
在源服务器上：
tar -czf file.tar.gz /path/to/files/
然后在接收端：
cd /path/to/files/
tar -xzf /path/to/file.tar.gz
您只需使用 rsync 进行 (tar|tar.gz) 文件的实际传输。
你可以尝试tar和ssh描述的伎俩在这里：
tar cvzf - /wwwdata | ssh root@192.168.1.201 "dd of=/backup/wwwdata.tar.gz"
这应该可以重写为以下内容：
tar cvzf - /wwwdata | ssh root@192.168.1.201 "tar xvf -"
但是，您会在此过程中失去 的--partial功能rsync。如果文件不是很频繁地更改，那么使用缓慢的初始值rsync可能是非常值得的，因为它将来会变得更快。
Til*_*n32 -5
我是 SFTP 的忠实粉丝。我使用 SFTP 将媒体从我的主计算机传输到我的服务器。我通过 LAN 获得了良好的速度。
SFTP 很可靠，我会尝试一下，因为它很容易设置，而且在某些情况下可能会更快。