it-swarm.cn

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

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

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

96
nicudotro

我会推荐焦油。当文件树已经很相似时,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
119
Scott Pack

外置硬盘和当日快递。

38
Adam

我会使用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/

17
Evan Anderson

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

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

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

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

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

8
Kyle Brandt

rsync,就像其他人已经建议的那样。如果加密带来的CPU开销是瓶颈,请使用另一种CPU占用率较低的算法,例如河豚。例如。就像是

rsync -ax -e 'ssh -c blowfish' /local/path [email protected]:/remote/path

7
janneb

昨天移动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安装的,源系统正在执行Push。不能加快速度,我们决定不保留atime个文件:

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

下图描述了从rsync到tar所做的更改的区别。这是我的 老板的 想法,而我的 同事 都执行了它,并做出了很棒的 他博客上的文字 。我只是喜欢 漂亮图片 。 :)

rsync_vs_tar

7
Philip Durbin

复制大量文件时,我发现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 [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
4
mfenniak

我也通过netcat方法使用tar,除了我更喜欢使用socat之外-可以通过调整mss来为自己的情况进行优化,以提供更多功能。 (也可以根据需要笑,但是我发现socat个参数比较容易记住,因为它们是一致的)。所以对我来说,最近这很普遍,因为我一直在将事物转移到新服务器上:

Host1$ tar cvf - filespec | socat stdin tcp4:Host2:portnum

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

别名是可选的。

3
R. Francis Smith
  • 网络文件系统(NFS),然后用您喜欢的任何方式复制它们,例如午夜指挥官(MC),鹦鹉螺(来自gnome)。我使用了NFS v3,效果很好。
  • Samba(CIFS),然后使用您想要的任何方式复制文件,但是我不知道它的效率如何。
  • [〜#〜] http [〜#〜]wget --mirror,因为 Evan Anderson 建议或任何其他http客户端。注意不要有任何讨厌的符号链接或误导性的索引文件。如果您只有MP3,那应该很安全。
  • rsync。我使用它的效果非常好,其尼斯功能之一就是您可以稍后中断并继续传输。

我注意到其他人建议使用netcat。基于我的经验,我可以说与其他解决方案相比,它的速度较慢。

2
Cristian Ciupitu

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

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

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

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

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

对于大量数据和高延迟网络,此选项很有用,但是在链路不稳定且掉线的情况下,此选项不是很有用。在这种情况下,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 [[email protected]]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的速度。

2
Daniel Santos

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

2
Adam D'Amico

您没有提到两台机器是否在同一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或 nison 以确保您拥有一切。
  • 如果愿意,可以使用tar而不是 cpio
  • 即使您最终使用ssh,我也会确保它本身未使用任何压缩,并通过gzip -1自己,以避免CPU饱和。 (或至少将CompressionLevel设置为1。)
1
Evan

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

一个比较表明:移动1.9GB的小文件(33926个文件)

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

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

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

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

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

我们还通过BBCP发送我们的zfs转储...这可以最大化我们的网络利用率并减少传输时间。

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

1
C. Shamis

我想我的答案在这里晚了一点,但是我在使用一台服务器上的mc(午夜指挥官)通过SFTP连接到另一台服务器方面取得了很好的经验。

通过FTP输入连接的选项在“左”和“右”菜单中,方法是输入如下地址:

/#ftp:[email protected]/

要么

/#ftp:[email protected]/

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

它具有一个内置选项,可以在后台进行复制,但是我更喜欢使用screen命令,并在mc复制时从屏幕上分离(我认为它运行的速度也比以前快)。

1
w-sky

到@scottpack的rSync选项答案

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

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

enter image description here

1
Dinesh Sunny

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

scp -C -c arcfour256 ./local/files.mp3 [email protected]:/opt/remote

使用这些选项,吞吐量可能会比没有选项快4倍或5倍(默认)

1
user57125

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

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

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

1
Brent

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

我也可能会通过ssh来回应做rsync的建议。就像是:

rsync -avW -e ssh $SOURCE [email protected]$REMOTE:$DEST

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

1
David Mackintosh

除了传输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交叉电缆上运行如此缓慢,则绝对需要修复某些问题。

1
Matt Simmons

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

  • 来源是具有250 Mbps和SATA驱动器的4核Intel(R)Xeon(R)CPU E5-1620 @ 3.60GHz
  • Destination是6核Intel®Xeon®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 -
1
Antares

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

0
Wim ten Brink

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

我用过rsync.

机器具有256 MB的内存。

我遵循的过程是这样的:

  • 已执行rsync而没有-H(花了9个小时)
  • rsync完成后,我同步了cpool目录并从pc目录开始;我削减了转账。
  • 然后使用-H标志重新启动rsync,并正确传输pc目录中硬链接的所有文件(该过程在cpool中找到了所有真实文件,然后链接到pc目录)(耗时3个小时)。

最后,我可以使用df -m验证没有多余的空间被花费。

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

0
Hector

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

0
Mijo

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

0
Adam Gibbins