在两台计算机之间发送大量数据的最快方法是什么？[关闭]

我经常遇到这种情况：

• 我有一个内部服务器，其中有一个320GB的硬盘驱动器，以及16GB的ram（可在此处找到确切的规格，但是由于这也是我在其他计算机上经常遇到的一个问题，因此我希望答案适用于任何计算机“合理的” Linux计算机）
• 我有一个备份服务器，其中有几个TB的硬盘空间（具体规格在此处，请参见上面的免责声明）

我想将320GB的数据从源服务器传输到目标服务器（特别是来自的数据/dev/sda）。

1. 两台计算机实际上彼此相邻，因此我可以在它们之间进行电缆连接。
2. 我在局域网上，并且正在使用新型路由器，这意味着我的网络速度应该“理想地”为1000Mbit，对吗？
3. 安全性不是问题。我在本地网络上，我信任网络上的所有计算机，包括路由器。
4. （可选）我不一定需要数据的签名校验和，但是应该检测基本的错误检查（例如丢包或驱动器变得不可读），而不仅仅是消失在输出中。

我在线搜索了这个问题，并测试了几个命令。最常出现的一个是：

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

事实证明，此命令太慢（运行了一个小时，仅通过数据获得了约80GB）。1GB的测试数据包花费了大约1分22秒的时间，最终没有压缩时的速度提高了两倍。由于传输的文件小于源系统上的RAM数量，因此结果可能也有偏差。

而且（这已经在1GB的测试件上进行了测试），如果我使用gzip命令and dd，则会遇到问题。与直接管道传输相比，在目标上提取时，结果文件具有不同的校验和。我仍在尝试找出原因。

由于服务器在物理上彼此相邻，并且您在注释中提到可以物理访问它们，因此最快的方法是将硬盘驱动器从第一台计算机中取出，放入第二台计算机，然后传输文件通过SATA连接。

netcat 对于像这样安全性不成问题的情况非常有用：

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

注意，如果您使用的dd是GNU coreutils，则可以发送SIGUSR1到进程，它将进程发送到stderr。对于BSD dd，请使用SIGINFO。

pv在报告复制过程中的进度方面更加有用：

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

1. 请使用快速压缩。

   • 无论使用哪种传输介质（尤其是用于网络或USB的传输介质），您都将使用数据突发进行读取，缓存和写入，而这些突发不会完全同步。
   • 除了磁盘固件，磁盘缓存和内核/内存缓存之外，如果您还可以通过某种方式使用系统的CPU来集中每个突发所交换的数据量，那么您应该这样做。
   • 任何压缩算法都将自动尽可能快地自动处理稀疏的输入，但是很少有压缩算法可以处理网络吞吐量的其余部分。
   • lz4 是您最好的选择：

     LZ4是一种非常快速的无损压缩算法，其压缩速度为每核400 MB / s，可与多核CPU一起扩展。它还具有极快的解码器，每个内核的速度为数GB / s，通常在多内核系统上达到RAM速度限制。

2. 最好不要没有不必要的寻求。

   • 这可能很难衡量。

   • 如果要从中进行复制的设备上有很多可用空间，并且该设备最近没有被清零，但是应该复制所有源文件系统，那么可能值得您花些时间来做就像是：

     </dev/zero tee >empty empty1 empty2; sync; rm empty*

   • 但这取决于您应该阅读源代码的级别。通常希望从/dev/some_disk设备文件的头到尾读取设备，因为在文件系统级别进行读取通常会涉及到来回搜索以及不连续地在磁盘周围进行搜索。因此，您的读取命令应类似于：

     </dev/source_device lz4 | ...

   • 但是，如果您的源文件系统不应该整体传输，那么在文件系统级别进行读取是不可避免的，因此您应该将输入内容汇总到流中。pax通常是那种情况下最好和最简单的解决方案，但您也可能会考虑mksquashfs。

     pax -r /source/tree[12] | lz4 | ...
     mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
     

3. 不要不与加密ssh。

   • 将加密开销添加到受信任的介质是不必要的，并且可能对持续传输的速度造成严重损害，因为读取的数据需要读取两次。
   • 所述PRNG需要读出的数据，或者至少它的一些，以维持随机性。
   • 当然，您还需要传输数据。
   • 您还需要传输加密开销本身-这意味着需要进行更多工作，每次突发传输的数据更少。

   • 因此，您应该使用netcat（或者，我更喜欢该nmap项目的功能更强大的ncat）进行简单的网络复制，就像其他地方建议的那样：

     ###  on tgt machine...
     nc -l 9999 > out.lz4
     ###  then on src machine...
     ... lz4 | nc tgt.local 9999
     

有几个限制可能会限制传输速度。

1. 1Gbps管道存在固有的网络开销。通常，这会将ACTUAL吞吐量降低到900Mbps或更小。然后，您必须记住，这是双向流量，因此您应该期望的速度大大低于900Mbps。

2. 即使您使用的是“新型路由器”，您是否确定该路由器支持1Gbps？并非所有新路由器都支持1Gbps。另外，除非它是企业级路由器，否则您可能会失去效率低下的路由器的额外传输带宽。虽然基于我在下面找到的内容，但看来您已经达到了100Mbps以上。

3. 共享您的网络的其他设备可能会造成网络拥塞。您是否尝试过使用直接连接的电缆，如您所说的那样？

4. 您正在使用多少磁盘IO？您可能会受到限制，而不是受到网络的限制，而是受到磁盘驱动器的限制。大多数7200rpm硬盘仅能达到40MB / s的速度。您是否正在使用突袭？您正在使用SSD吗？您在远端使用什么？

我建议使用rsync（如果希望重新运行该备份）。您也可以在另一端使用filezilla之类的下载程序来scp，ftp或http，因为它将并行化ssh / http / https / ftp连接。当其他解决方案都在单个管道上时，这可以增加带宽。单管道/线程仍然受到单线程事实的限制，这意味着它甚至可能受CPU约束。

使用rsync，您可以消除解决方案的大量复杂性，并可以压缩，保留权限并允许部分传输。还有其他一些原因，但这通常是大型企业的首选备份方法（或运行备份系统）。Commvault实际上将其软件下方的rsync用作备份的传递机制。

根据给定的80GB / h的示例，您获得的速度约为177Mbps（22.2MB / s）。我觉得您可以通过在两个盒子之间的专用以太网线路上使用rsync轻松将其加倍，因为我已经在自己的测试中通过千兆位的rsync设法做到了这一点。

我们会定期处理。

我们倾向于使用的两种主要方法是：

1. SATA / eSATA / sneakernet
2. 直接NFS挂载，然后本地cp或rsync

首先取决于驱动器是否可以物理重定位。这并非总是如此。

第二个效果出奇的好。通常，通过直接NFS挂载，我们可以很容易地最大化1gbps的连接。使用scp，dd而不是ssh或类似的东西，您将无法获得与之接近的任何东西（可疑的最大速率通常会接近100mpbs）。即使在速度非常快的多核处理器上，您也将遇到两台机器中最慢的一个内核最大加密吞吐量的瓶颈，与未加密网络安装中的全口径cp或rsync相比，它的速度令人沮丧。有时候，你会打的IOPS墙了一小会儿，并在周围被卡住〜53MB / s，而不是更典型的〜110MB / s的，但通常是短暂的，除非源或目标是实际一个驱动器，那么您可能最终会受到驱动器自身持续速率的限制（由于实际原因，这种差异会因随机原因而变化，直到您实际尝试时才会知道）。

如果在不熟悉的发行版上安装NFS可能会有些烦人，但通常来说，这是尽可能充分地填充管道的最快方法。我上一次以超过10gbps的速度进行连接时，我实际上并没有发现连接是否达到极限，因为传输是在我从喝咖啡回来之前结束的，所以您可能会遇到一些自然限制。如果源和目标之间有少量网络设备，则可能会由于网络的滞后效应而受到一些轻微的延迟或打,，但是通常这可以在整个办公室（不使其他流量瘫痪）或从数据中心的一端到另一端正常工作。另一个（除非您内部进行某种过滤/检查，在这种情况下所有下注都为off）。

编辑

我注意到有关压缩的一些讨论…… 不压缩连接。它将以与加密层相同的方式使您变慢。如果您压缩连接，则瓶颈将始终是单个核心（并且您甚至不会获得该核心总线的特别好利用）。在这种情况下，最慢的事情是在两台以1gbps或更高的速度彼此相邻的计算机之间使用加密的压缩通道。

未来发展

该建议截至2015年中期。几乎可以肯定，这种情况不会持续太多年了。因此，每样东西都要花一分钱，如果您定期面对这项任务，请在实际负载上尝试各种方法，而不是想像您会得到接近理论最佳值的结果，甚至观察到类似Web之类的典型压缩/加密吞吐率流量，其中大部分是文本流量（提示：批量传输通常主要由已压缩的图像，音频，视频，数据库文件，二进制代码，办公文件格式等组成）以自己的方式运行，并从另一个压缩例程中受益匪浅，压缩例程的大小几乎可以保证与已压缩的二进制数据不对齐...）。

我想在将来，像SCTP这样的概念将被带到一个更有趣的地方，在这里，通常会使用绑定连接（或内部按频谱绑定的光纤通道连接），并且每个通道可以接收独立于其他通道的流。流可以并行压缩/加密，等等。那太好了！但是2015年的今天情况并非如此，尽管幻想和理论化还不错，但我们大多数人都没有运行在冷冻室中的自定义存储集群，直接将数据馈送到Blue Gene / Q的内部，从而为Watson生成了答案。那不是现实。我们也没有时间详尽地分析数据有效负载来确定压缩是否是一个好主意-传输本身将在我们完成分析之前结束，

但...

时代在变，我对压缩和加密的建议将一去不复返。我真的很希望此建议在典型情况下能尽快被推翻。这会让我的生活更轻松。

我过去使用的一个漂亮工具是bbcp。如此处所示：https : //www.slac.stanford.edu/~abh/bbcp/。

另请参阅http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

我使用此工具的传输速度非常快。

如果您以某种方式（通过有线/ sneakernet /任何方式）获得了第一通，则可以研究rsync某些选项，这些选项可以大大加快后续传输的速度。一个很好的方法是：

rsync -varzP sourceFiles destination

选项包括：详细，存档模式，递归，压缩，部分进度

添加对原始海报坚持zackse答案的评论的补充，尽管我不确定这在典型情况下最快。

bash具有特殊的重定向语法：
对于输出：      > /dev/tcp/ IP  / 端口
对于输入：       < /dev/tcp/ IP  / 端口
IP禁止为点分十进制IP或主机名； port ban可以是十进制数字，也可以是来自的端口名称/etc/services。

没有实际/dev/tcp/目录。这是一个特殊的语法错误，命令bash创建一个TCP套接字，将其连接到指定的目标，然后执行与通常的文件重定向相同的操作（即，使用dup2（2）将相应的标准流替换为套接字）。

因此，人们可以直接通过TCP 从源机器dd或tar在源机器上流数据。或者相反，tar直接通过TCP 将数据流传输到类似内容。无论如何，都消除了一个多余的网猫。

关于netcat的注意事项

有经典的netcat和GNU的netcat之间的语法不一致。我将使用我惯用的经典语法。更换-lp用-l的GNU的netcat。

另外，我不确定GNU netcat是否接受-q切换。

传输磁盘映像

（沿着zackse的答案。）
在目的地：

nc -lp 9999 >disk_image

来源：

dd if=/dev/sda >/dev/tcp/destination/9999
 

使用以下命令创建tar.gz归档文件 tar

在目的地：

nc -lp 9999 >backup.tgz

来源：

tar cz files or directories to be transferred >/dev/tcp/destination/9999

更换.tgz用.tbz并cz用cj获得bzip2-compressed存档。

立即扩展到文件系统传输

也可以tar。
在目的地：

cd backups
tar x </dev/tcp/destination/9999

来源：

tar c files or directories to be transferred |nc -q 1 -lp 9999

它可以在没有的情况下工作-q 1，但是在数据结束时netcat将卡住。有关的语法和注意事项，请参见tar（1）tar。如果有许多具有高冗余度（低熵）的文件，则可以尝试压缩（例如cz和xz而不是cand x），但是如果文件是典型的并且网络足够快，则只会减慢该过程。有关压缩的详细信息，请参见mikeserv的答案。

替代样式（目标侦听端口）

在目的地：

cd backups
nc -lp 9999 |tar x

来源：

tar c files or directories to be transferred >/dev/tcp/destination/9999

尝试有关直接连接并避免使用诸如ssh之类的加密协议的建议。然后，如果您仍然想发挥所有性能，请访问以下站点：https : //fasterdata.es.net/host-tuning/linux/，以获取有关优化TCP窗口的一些建议。

我将使用我编写的需要该程序包的脚本socat。

在源计算机上：

tarnet -d wherefilesaretosend pass=none 12345 .

在目标计算机上：

tarnet -d wherefilesaretogo pass=none sourceip/12345

如果有vbuf软件包（Debian，Ubuntu），则文件发送者将显示数据进度。文件接收器将显示接收到的文件。pass =选项可用于可能暴露数据（速度较慢）的地方。

编辑：

-n如果CPU是瓶颈，请使用该选项禁用压缩。

如果预算不是主要问题，则可以尝试将驱动器与Intel Xeon E5 12核心“驱动器连接器”连接。该连接器通常功能强大，甚至可以在其上运行当前的服务器软件。从两个服务器！

这看起来可能是一个有趣的答案，但是您应该真正考虑一下为什么要在服务器之间移动数据，以及是否拥有共享内存和存储的大型服务器更有意义。

不确定当前的规格，但是传输速度可能受磁盘速度而非网络速度的限制？

如果您只关心备份，而不关心硬盘驱动器的字节复制，那么我建议您使用backupPC。http://backuppc.sourceforge.net/faq/BackupPC.html设置起来有点麻烦，但是传输非常快。

我最初传输约500G数据的时间约为3个小时。随后的备份大约需要20秒。

如果您对备份不感兴趣，但尝试同步内容，则rsync或unison会更适合您的需求。

一个字节的硬盘字节拷贝通常是出于备份目的的一个糟糕主意（没有增量，没有节省空间，驱动器无法使用，您必须备份“空白空间”，并且必须备份垃圾） （例如16G交换文件或200G核心转储等）。使用rsync（或backuppc或其他工具），您可以及时创建“快照”，从而可以使用以下命令转到“文件系统看起来像30分钟前的样子”：很少的开销。

就是说，如果您真的想传输一个字节进行字节复制，那么您的问题将出在传输上，而不是从驱动器获取数据。如果没有400G的RAM，则320G的文件传输将花费很长的时间。使用未加密的协议是一种选择，但是无论如何，您只需要坐在那里等待几个小时（通过网络）即可。

无论使用哪种程序，我通常都发现通过网络“拉”文件比“推”文件快。也就是说，登录到目标计算机并进行读取比登录源计算机并进行写入要快。

另外，如果要使用中间驱动器，请考虑以下事项：获取使用eSATA而不是USB的外部驱动器（作为包装，或插入扩展坞的单独驱动器）。然后，在两台计算机的每台计算机上，要么安装带有eSATA端口的卡，要么获得一条简单的适配器电缆，该电缆将内部SATA端口之一连接到外部eSATA连接器。然后将驱动器插入源计算机，打开驱动器电源，然后等待其自动挂载（您可以手动挂载，但是如果反复执行此操作，则最好将其放入fstab文件中）。然后复制；您将以与内部驱动器相同的速度进行写入。然后卸下驱动器，关闭电源，插入另一台计算机，打开电源，等待自动安装并读取。

我建议您看一下NIC组合。这涉及使用并行运行的多个网络连接。假设您确实需要超过1Gb的传输，并且10Gb的价格高得令人望而却步，那么NIC团队提供的2Gb将是一笔很小的费用，并且您的计算机可能已经具有额外的端口。

FWIW，我一直使用这个：

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

关于此方法的问题是，它将维护机器之间的文件/文件夹许可权（假设两台机器上都存在相同的用户/组）（我也通常这样做是为了复制虚拟磁盘映像，因为我可以使用-S参数来处理稀疏文件。 ）

刚刚在两个繁忙的服务器之间进行了测试，并在216s（约64MB / s）的速度下管理了约14GB的内存-在专用计算机和/或压缩之间可能会做得更好... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

除非要进行文件系统取证，否则请对文件系统使用转储/恢复程序，以避免复制FS未使用的可用空间。根据您拥有的文件系统，通常会保留所有元数据，包括ctime。但是，根据不同的文件系统（xfs，ext4，ufs ...），inode号可能会更改。

还原目标可以是目标系统上的文件。

如果要使用分区表的全磁盘映像，则可以dd在磁盘的前1M处获取分区表/引导加载程序/内容，然后xfsdump获取分区。

我无法从您的信息转储中得知您实际上拥有哪种文件系统。如果是BSD ufs，那么我认为它具有转储/还原程序。如果是ZFS，最好是IDK，可能有些问题。

通常，除了恢复情况外，对其他任何东西来说，全盘复制都太慢了。您也无法以这种方式进行增量备份。

您也可以将系统设置为具有共享存储！

我正在考虑这些是彼此相邻的，您很可能会一遍又一遍....

以太网交叉电缆怎么样？您不必依赖无线速度，而可以限制NIC的有线速度。

这是带有类似解决方案示例的类似问题。

如今，显然只有一条典型的以太网电缆就足够了。显然，NIC越好，传输速度就越快。

总之，如果需要进行任何网络设置，则应仅限于为服务器和备用计算机设置子网掩码为255.255.255.0的静态IP。

祝好运！

编辑：

@Khrystoph在回答中谈到了这一点

一些人建议您跳过ssh，因为加密会使您变慢。现代CPU实际上可能足够快，达到1Gb，但是OpenSSH的内部窗口实现存在问题，可能会大大降低您的速度。

如果要使用ssh进行此操作，请查看HPN SSH。它解决了窗口问题，并添加了多线程加密。不幸的是，您将需要在客户端和服务器上都重建ssh。

好的，我尝试为两台彼此“靠近”的“非常大的管道”（10Gbe）的计算机回答这个问题。

您在这里遇到的问题是：由于管道太大，因此大多数压缩都会使cpu成为瓶颈。

传输10GB文件的性能（6 Gb网络连接[linode]，不可压缩的数据）：

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

在10 Gbe上的两个盒子，稍旧版本的netcat（CentOs 6.7），10GB文件：

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

因此，在一个实例中，netcat使用的cpu较少，在另一个实例中，netcat的使用较少，因此YMMV。

使用netcat，如果它没有“ -N -q 0”选项，则可以传输被截断的文件，请注意...其他选项，例如“ -w 10”，也可能导致被截断的文件。

在几乎所有这些情况下，正在发生的事情是CPU利用率最高，而不是网络利用率最高。 scp最大速度约为230 MB / s，将一个内核固定在100％的利用率下。

不幸的是，Iperf3创建损坏的文件。某些版本的netcat似乎无法传输整个文件，这很奇怪。特别是它的旧版本。

“ gzip作为通往netcat的管道”或“ mbuffer”的各种说法似乎也使gzip或mbuffer的cpu发挥到了最大，因此并没有导致使用如此大的管道更快地进行传输。lz4可能会有所帮助。另外，我尝试的某些gzip管道内容导致非常大（> 4 GB）文件的传输损坏，因此请小心:)

特别对于更高的延迟（？）可能有用的另一件事是调整tcp设置。以下是提及建议值的指南：

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm和https://fasterdata.es.net/host-tuning/linux/（从另一个答案中）可能是IRQ设置：https : //fasterdata.es .net / host-tuning / 100g-tuning /

来自linode的建议，添加到/etc/sysctl.conf：

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

此外，他们希望您运行：

 /sbin/ifconfig eth0 txqueuelen 10000 

调整后值得仔细检查，以确保更改也不会造成损害。

也可能值得调整窗口大小：https : //iperf.fr/iperf-doc.php#tuningtcp

使用较慢的连接，压缩绝对可以帮助您。如果管道很大，那么非常快的压缩可能会帮助您轻松压缩数据，而没有尝试过。

“同步硬盘驱动器”的标准答案是使文件同步，从而避免可能的传输。

另一个选择：使用“ parallel scp”（以某种方式或其他方式），那么它将使用更多的内核...