如何在两个服务器之间快速复制大量文件

我需要在两个服务之间传送大量的mp3（Ubuntu）。我所说的巨大是指大约一百万个文件，平均30万个文件。我尝试过，scp但要花大约一周的时间。（大约500 KB / s）如果通过HTTP传输单个文件，则我的传输速度为9-10 MB / s，但我不知道如何传输所有文件。

有没有办法快速转移所有人？

我会推荐焦油。当文件树已经很相似时，rsync的性能会很好。但是，由于rsync将对每个文件进行多次分析，然后复制更改，因此它比tar慢得多。该命令可能会执行您想要的操作。它将在计算机之间复制文件，并同时保留权限和用户/组所有权。

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

根据下面的Mackintosh的注释，这是用于rsync的命令

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

外置硬盘和当日快递。

我会使用rsync。

如果已通过HTTP导出了它们并提供了可用的目录列表，则也可以使用wget和--mirror参数。

您已经看到HTTP比SCP快，因为SCP正在加密所有内容（因此成为CPU的瓶颈）。HTTP和rsync不会加密，因此运行速度更快。

以下是在Ubuntu上设置rsync的一些文档：https : //help.ubuntu.com/community/rsync

这些文档讨论了通过SSH隧道传输rsync，但是如果您只是在私有LAN上移动数据，则不需要SSH。（我假设您在专用LAN上。如果您通过Internet获得9-10MB /秒的速度，那么我想知道您拥有哪种连接！）

以下是一些其他非常基本的文档，可让您设置相对不安全的rsync服务器（不依赖SSH）：http : //transamrit.net/docs/rsync/

无需过多讨论，就可以使用netcat，网络瑞士刀。没有协议开销，您可以直接复制到网络套接字。例

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

如果您确实使用rsync，则有很多文件，我会尝试在两端获得版本3或更高版本。原因是较低的版本会在开始传输之前枚举每个文件。新功能称为增量递归。

现在，当rsync与另一个3.x版本交谈时，将使用新的增量递归算法。这样可以更快地开始传输（在找到所有文件之前），并且需要更少的内存。有关某些限制，请参见联机帮助页中的--recursive选项。

rsync，就像其他人已经推荐的那样。如果加密产生的CPU开销是瓶颈，请使用另一种CPU占用较少的算法，例如河豚。例如类似

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

昨天在移动80 TB数据（数百万个小文件）时，从切换rsync到的tar 速度被证明要快得多，因为我们停止尝试

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

改用tar...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

由于这些服务器位于同一LAN上，因此目标是在源系统上进行NFS安装的，源系统正在执行推送。不能加快速度，我们决定不保留以下atime文件：

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

下图描述了从rsync到tar所做的更改的区别。这是我老板的主意，而我的同事都执行了这个主意，并在他的博客上做了很多精彩的文章。我只喜欢漂亮的照片。:)

复制大量文件时，我发现诸如tar和rsync之类的工具效率不高，因为它们需要打开和关闭许多文件。在以下情况下，我编写了一个名为fast-archiver的开源工具，该工具比tar更快：https : //github.com/replicon/fast-archiver；通过执行多个并发文件操作，它可以更快地工作。

这是一个备份超过200万个文件的快速存档与tar的示例；快速存档需要27分钟才能存档，而tar需要1小时23分钟。

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

要在服务器之间传输文件，可以使用带有ssh的快速存档器，如下所示：

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

netcat除了喜欢使用tar 以外，我还使用tar 方式socat，例如，通过调整mss，可以使用更多功能来优化您的情况。（此外，如果您愿意，也可以大笑，但是我发现socat参数更容易记住，因为它们是一致的）。所以对我来说，最近这很普遍，因为我一直在将事物转移到新服务器上：

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

别名是可选的。

另一种选择是Unison。在这种情况下，它的效率可能比Rsync略高一些，并且设置监听器要容易一些。

似乎最高答案中可能有一些错别字。这可能会更好：

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

• 网络文件系统（NFS），然后使用任何您喜欢的文件进行复制，例如Midnight Commander（mc），Nautilus（来自gnome）。我使用了NFS v3，效果很好。
• Samba（CIFS），然后使用您想要的任何方式复制文件，但是我不知道它的效率如何。
• HTTP使用wget --mirror的埃文·安德森曾建议或任何其他HTTP客户端。注意不要有任何讨厌的符号链接或误导性的索引文件。如果您只有MP3，那应该很安全。
• rsync。我用它取得了很好的效果，它的一个不错的功能是您可以在以后中断并继续传输。

我注意到其他人建议使用netcat。根据我的经验，我可以说与其他解决方案相比，它的运行速度很慢。

感谢Scott Pack的精彩回答（以前我不知道如何使用ssh做到这一点），所以我可以提供这一改进（如果bash是您的shell）。这将添加并行压缩，进度指示器并检查整个网络链接的完整性：

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pv是用于管道的不错的进度查看器程序，并且pigz是并行gzip程序，默认情况下使用的线程数与CPU的数量相同（我相信最多为8个）。您可以调整压缩级别，以更好地适应CPU与网络带宽的比率，pxz -9e并pxz -d在您的CPU比带宽更多的情况下将其替换掉。您只需在完成时验证两个总和是否匹配即可。

对于大量数据和高延迟网络，此选项很有用，但在链路不稳定且掉线的情况下，此选项不是很有用。在这种情况下，rsync可以恢复，因此可能是最佳选择。

样本输出：

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

对于块设备：

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

显然，请确保它们的大小或限制与count =，skip =，seek =等相同。

当我以这种方式复制文件系统时，我通常会首先dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs将大多数未使用的空间归零，这会加快xfer的速度。

我认为除非安装更快的网卡，否则您不会比scp做得更好。如果您通过互联网进行此操作，那将无济于事。

我建议使用rsync。它可能没有更快的速度，但是至少如果失败了（或者因为它花费的时间太长而将其关闭），则可以在下一次停止的地方继续。

如果您可以使用千兆位以太网直接连接两台计算机，那可能是最快的。

对于100Mb / s，理论吞吐量为12.5 MB / s，因此在10MB / s的情况下，您的表现相当不错。

我也会回应建议通过rsh进行rsync。就像是：

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

在100Mb / s的速度下，您的CPU应该能够处理加密/解密而不会明显影响数据速率。而且，如果您中断了数据流，则应该能够从上次中断的地方恢复。当心，随着“数百万”个文件的启动，启动将需要一段时间才能真正传输任何内容。

除了传输Oracle日志外，我已经遇到了这一点。

这是细分

• scp

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• 同步

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

我使用FTP取得了巨大的成功（巨大的成功相当于Gb网络上的〜700Mb / s）。如果您获得10MB（等于80Mb / s），则可能是错误的。

关于数据的来源和目的地，您能告诉我们什么？是单驱动器还是单驱动器？RAID转USB？

我知道这个问题已经有了答案，但是如果您的网络在Gb / s交叉电缆上运行如此缓慢，则绝对需要修复某些问题。

您没有提到两台计算机是否在同一LAN上，或者是否必须使用安全通道（即使用SSH），但是可以使用的另一种工具是netcat。

我会在接收机上使用以下内容：

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

然后在发送方：

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

具有以下优点：

• ssh加密没有CPU开销。
• 可以在gzip -1不使CPU饱和的情况下提供轻度压缩，因此可以做出良好的折衷，在保持最大吞吐量的同时进行一点压缩。（对于MP3数据可能没有那么大的优势，但并没有受到伤害。）
• 如果您可以将文件分成几组，则可以并行运行两个或更多管道，并真正确保您的网络带宽达到饱和。

例如，

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

笔记：

• 无论您采用哪种传输方式，之后我都可能会运行rsync或统一以确保您拥有一切。
• 如果愿意，可以使用tar代替cpio。
• 即使您最终使用ssh，我也会确保它本身未使用任何压缩，gzip -1而是通过管道进行遍历，以避免CPU饱和。（或至少将CompressionLevel设置为1。）

具有适当选项的简单scp通过LAN可以轻松达到9-10 MB / s：

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

使用这些选项，吞吐量可能会比没有选项快4倍或5倍（默认）

如果您在src端拥有ftp服务器，则可以从ncftp site使用ncftpget。它在内部使用tar时，可与小型文件配合使用。

一项比较显示：移动1.9GB的小文件（33926个文件）

1. 使用scp需要11分59秒
2. 使用rsync需要7分10秒
3. 使用ncftpget需要1分20秒

您也可以尝试使用BBCP命令进行传输。这是一个真正尖叫的缓冲并行ssh。如果我们可以保持管道供气，通常我们可以获得90％+的线速。

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

正常情况下，我们会尽力避免不必要地移动肩带。我们使用ZFS池，总是可以向其中添加更多的磁盘空间。但是有时候...您只需要移动东西。如果我们有一个“实时”文件系统，即使进行完全爆炸，它也可能要花费数小时（或数天）进行复制。.我们执行两个步骤的zfs send例程：

1. 制作ZFS快照，然后转移到新计算机上的新池中。让它花尽可能长的时间。
2. 制作第二张快照，并将其作为增量发送。增量快照仅包含自第一个以来的（小得多）更改集，因此它的处理速度相对较快。
3. 增量快照完成后，您可以翻转原始快照并切换到新副本，并且将“离线停机时间”保持在最低限度。

我们还通过BBCP发送我们的zfs转储...这可以最大程度地提高网络利用率并缩短传输时间。

BBCP是免费提供的，您可以在Google上对其进行搜索，并且它是直接的编译器。只要将其复制到src和目标计算机上的/ usr / local / bin中，它就可以正常工作。

我想我的答案来晚了一点，但是我在使用一台服务器上的mc（午夜指挥官）通过SFTP连接到另一台服务器上获得了很好的经验。

通过FTP输入连接的选项位于“左”和“右”菜单中，方法是输入如下地址：

/#ftp:name@server.xy/

要么

/#ftp:name@ip.ad.dr.ess/

您可以像在本地文件系统上一样浏览和执行文件操作。

它具有一个内置选项，可以在后台进行复制，但是我更喜欢使用screen命令，并在mc复制时从屏幕上分离（我认为这样做的速度也更快）。

到@scottpack的rSync选项答案

要显示上传进度，请在命令中的-avW之后使用'--progess'作为选项。

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

这是比较某些技术的快速基准，

• 来源是具有250 Mbps和SATA驱动器的4核Intel（R）Xeon（R）CPU E5-1620 @ 3.60GHz
• Destination是6核Intel（R）Xeon（R）CPU E-2136 @ 3.30GHz，具有1 Gbps带宽和SSD驱动器

文件数：9632，总大小：814 MiB，平均大小：84 KiB

• 同步：1m40.570s
• RSYNC +压缩：0m26.519s
• TAR + NETCAT：1分58.763秒
• TAR +压缩+ NETCAT：0m28.009s

tar / netcat的命令为：

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

rsync或您可能希望将其压缩为一个文件，然后将其压缩。如果缺少磁盘空间，则可以在制作tar时将其直接通过ssh传递。

如果要通过MP3和其他压缩文件进行发送，则任何尝试进一步压缩这些文件的解决方案都不会带来太大的好处。解决方案是可以在两个服务器之间创建多个连接，从而在两个系统之间的带宽上施加更大的压力。一旦达到极限，不改善硬件就无济于事。（例如，这些服务器之间的快速网卡。）

我尝试了几种用于复制1GB文件的工具，结果如下：HTTP最快，wget -c nc连续第二秒scp最慢，并且失败了几次。恢复rsync的方法无法使用ssh作为后端，因此结果相同。总之，我将使用wget -bqc来访问http，并花一些时间。希望这会有所帮助

我必须将BackupPC磁盘复制到另一台计算机上。

我用过rsync

机器具有256 MB的内存。

我遵循的过程是这样的：

• rsync不执行-H（花了9个小时）
• rsync完成后，我同步cpool目录并从目录开始pc；我削减了转账。
• 然后rsync使用-Hflag 重新启动，并pc正确传输目录中所有硬链接的文件（该过程在其中找到了所有真实文件cpool，然后链接到该pc目录）（耗时3个小时）。

最后，我可以证明df -m没有多余的空间被花费。

通过这种方式，我可以避免内存和rsync的问题。我一直都可以使用top和top验证性能，最后我传输了165GB的数据。