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

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

#1 楼

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

#2 楼

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

注意，如果您使用的是GNU coreutils中的dd，则可以将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

#3 楼

请使用快速压缩。


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

lz4是您的最佳选择：


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





最好不要不必要地寻找。


这可能很难衡量。

如果要复制的设备上有很多可用空间，并且该设备最近没有被清零，但是应该复制所有源文件系统，则它是也许值得您花些时间先执行以下操作：

 </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 | ...
 

请勿加密ssh。


不必要在可信介质上添加加密开销，并且可能对持续传输的速度造成严重损害，因为读取的数据需要读取两次。
PRNG需要读取的数据或至少其中一些数据来维持随机性。
当然，您还需要传输数据。
还需要传输加密开销本身-这意味着需要做更多的工作

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

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

#4 楼

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


1Gbps管道存在固有的网络开销。通常，这会将ACTUAL吞吐量降低到900Mbps或更低。然后，您必须记住，这是双向流量，您应该期望其速度大大低于900Mbps。
即使您使用的是“新型路由器”，您是否也确定该路由器支持1Gbps？并非所有新路由器都支持1Gbps。另外，除非它是企业级路由器，否则您可能会失去效率低下的路由器的额外传输带宽。尽管根据我在下面的发现，看来您正在达到100Mbps以上。
共享您的网络的其他设备可能会造成网络拥塞。您是否尝试过按照您说的那样使用直接连接的电缆？
您正在使用多少磁盘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设法做到了这一点。

#5 楼

我们会定期处理此问题。

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


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


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

第二个效果出奇的好。通常，通过直接NFS挂载，我们可以轻松实现最大1gbps的连接。使用scp，dd而不是ssh或类似的东西，您将无法获得与之接近的任何结果（可疑的最大速率通常会接近100mpbs）。即使在速度非常快的多核处理器上，您也将遇到两台机器中最慢的一个内核最大加密吞吐量的瓶颈，与未加密的网络安装上的全口径cp或rsync相比，这令人沮丧地慢。有时您会碰到一会儿iops墙，停留在〜53MB / s左右，而不是典型的〜110MB / s，但这通常是短暂的，除非源或目标实际上是单个驱动器，那么您可能会受到驱动器本身持续速率的限制（由于实际原因，该速率会因随机原因而变化得足够大，直到您实际尝试时才会知道）–嗯。

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

EDIT

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

未来的发展


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

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

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

#6 楼

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

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

该工具的传输速度非常快。

#7 楼

如果您以某种方式（通过有线/ sneakernet /任何方式）获得了第一遍认证，则可以通过某些选项来查看rsync，从而极大地加快后续传输的速度。一个很好的方法是：

rsync -varzP sourceFiles destination

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

#8 楼

在不确定zackse答案的注释中添加了原始海报的坚持，尽管我不确定这在典型情况下最快。

bash具有特殊的重定向语法：
对于输出：> /dev/tcp/ IP /端口
输入：< /dev/tcp/ IP / portIP禁令可以是点分十进制IP或主机名;
端口禁令可以是十进制数或/etc/services中的端口名。

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

因此，可以直接通过TCP在源计算机上从dd或tar流数据。或者相反，直接通过TCP将数据流传输到tar或类似的东西。在任何情况下，都可以消除一个多余的netcat。

有关netcat的说明

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

此外，我不确定GNU netcat是否接受-q开关。

传输磁盘映像

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

nc -lp 9999 >disk_image

在来源：

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

使用tar创建tar.gz归档文件


目标位置：

nc -lp 9999 >backup.tgz

源代码：

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

将.tgz替换为.tbz，将cz替换为cj，以获得bzip2压缩的存档。

立即扩展到文件系统的传输

也带有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的语法和注意事项的说明，请参见tar（1）。如果有很多文件具有很高的冗余度（低熵），则可以尝试压缩（例如cz和xz而不是c和x），但是如果文件很典型并且网络速度足够快，则只会减慢压缩速度处理。有关压缩的详细信息，请参见mikeserv的答案。

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

在目标位置：

cd backups
nc -lp 9999 |tar x

来源：

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

#9 楼

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

#10 楼

我将使用我编写的需要socat软件包的脚本。

在源计算机上：

tarnet -d wherefilesaretosend pass=none 12345 .

在目标计算机上：

tarnet -d wherefilesaretogo pass=none sourceip/12345

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

编辑：

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

#11 楼

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

这似乎是一个有趣的答案，但是您应该真正考虑一下为什么要在服务器之间移动数据，以及是否有共享内存和存储的大型服务器更有意义。 />
不确定当前的规格，但是传输速度可能会受到磁盘速度的限制，而不是网络的速度？

#12 楼

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

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

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

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

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

#13 楼

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

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

#14 楼

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

#15 楼

FWIW，我一直使用以下方法：

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

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

仅在两个繁忙的服务器之间进行了测试，并管理了〜14GB在216s
（约64MB / s）中-在专用计算机和/或压缩之间可能会做得更好... 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

#16 楼

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

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

如果您希望使用带有分区表的全磁盘映像，则可以dd磁盘的第一个1M来获取分区表/引导加载程序/内容，然后xfsdump分区。

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

通常情况下，对全盘复制磁盘速度太慢，除了恢复情况外，其他任何事情都不会。您也无法通过这种方式进行增量备份。

#17 楼

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

我正在考虑它们彼此相邻，并且您很可能会一遍又一遍....

#18 楼

以太网交叉电缆怎么样？不再依赖于无线速度，您可以限制NIC的有线速度。
对于这种解决方案的一些例子，这也是一个类似的问题。
如今，显然只有一条典型的以太网电缆就足够了。显然，您的NIC越好，传输速度就越快。
总而言之，如果需要进行任何网络设置，则应仅限于为服务器和备用计算机设置静态IP，并使用子网掩码255.255.255.0
。祝你好运！
编辑：
@Khrystoph在回答中谈到了这个问题

#19 楼

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

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

#20 楼

好的，我尝试为两台彼此“靠近”的“非常大的管道”（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使用的cpu较少，因此，YMMV。

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

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

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

“ gzip作为通向netcat的管道”或“ mbuffer”的各种说法似乎也使gpu或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”（以某种方式），那么它将使用更多的内核...