我的意思是大约一百万个文件,平均30万个文件。
我尝试过使用
scp
,但是大约需要一周的时间。 (大约500 KB / s)如果我通过HTTP传输单个文件,我将获得9-10 MB / s的速度,但是我不知道如何传输所有文件。
有办法快速转移所有人吗?
#1 楼
我会推荐焦油。当文件树已经很相似时,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
评论
+1 tar选项对于大量小文件而言效率更高,因为scp和rsync在网络上每个文件的往返行程都会更多。
– Sekenre
09年2月2日在21:16
rsync对我来说比tar更有效
– nicudotro
09年2月2日在22:24
另外,如果您有足够的CPU可用量(两端),但是(至少)主机之间的连接较慢,则值得在tar命令中启用压缩功能(gzip或bzip)。
–疫苗
2010-10-14 14:03
@Jamie:如果您使用的是ssh-agent,则应使用它。否则,只需使用“ -i”选项来指定在哪里可以找到私钥。有关详细信息,请参见手册页。
–斯科特包
2012年7月10日在17:03
@niXar仅在SSH使用终端的情况下启用〜转义字符。当您指定远程命令时,情况并非如此(除非您通过-t选项)。因此,您的关注无效。
–吉尔斯'所以-不再是邪恶的'
2013年9月18日下午14:55
#2 楼
外置硬盘和当日快递。评论
嘿嘿...没有任何一种网络技术能胜过载有90 MPH磁带的旅行车的带宽,是吗? (昵称)我以为他在局域网上,因为他说他的HTTP速度为9-10MB /秒。
–埃文·安德森(Evan Anderson)
09年6月2日在20:01
我可以通过互联网获得这种速度,但是我住的地方很幸运!如果在局域网上,那就便宜了!
–亚当
09年2月2日在20:15
啊-没看你的位置。是的-我听说韩国的互联网连接非常壮观。卡在美国这里,我很高兴通过“网络”获得900KB /秒的速度。
–埃文·安德森(Evan Anderson)
09年6月2日在20:24
是的,但是在等待下载完成时,您可以得到美味的墨西哥卷饼,即使在首尔,也只有大约三家像样的墨西哥餐厅...
–亚当
09年2月2日在20:58
#3 楼
我会使用rsync。如果通过HTTP导出了目录列表,则可以使用wget和--mirror参数。
已经知道HTTP比SCP快,因为SCP正在加密所有内容(从而造成CPU瓶颈)。 HTTP和rsync不会加密,因此运行速度更快。
以下是一些在Ubuntu上设置rsync的文档:https://help.ubuntu.com/community/rsync
这些文档讨论了通过SSH隧道传输rsync,但是如果您只是在不需要SSH的专用LAN上移动数据。 (我假设您在专用LAN上。如果您通过Internet获得9-10MB /秒的速度,那么我想知道您的连接方式是什么!)
这里还有其他一些连接非常基本的文档,可让您设置相对不安全的rsync服务器(不依赖SSH):http://transamrit.net/docs/rsync/
评论
尽管SCP确实使用了一些CPU来加密数据,但我认为他没有100%的CPU使用率,因此CPU并不是瓶颈。我已经太多次注意到SCP在快速转移方面效率低下。
–克里斯蒂安·丘皮图
09年6月2日在20:27
考虑到他在SCP上看到300K,在HTTP上看到9MB,我认为一个与SCP相关的瓶颈(通常是CPU)正在发挥作用。当然,可能还有其他事情。不知道有关机器的硬件规格,这很难说。
–埃文·安德森(Evan Anderson)
09年6月2日在20:36
rsync几乎肯定会使用ssh进行传输,因为这是默认行为,因此由scp加密引起的任何开销也将出现在rsync中
–丹尼尔·劳森(Daniel Lawson)
09年3月3日,0:35
“您已经看到HTTP比SCP快,因为SCP正在加密所有内容”→WRONG。除非他拥有10年的服务器,否则他不受CPU限制。
– niXar
2011年5月4日9:43
@RamazanPOLAT-您的命令行太长。以其他方式指定文件选择,它将对您很好。通常,您只需在源目录末尾指定通配符即可。您也可以使用--include和--exclude参数来获得更多细微差别。
–埃文·安德森(Evan Anderson)
2014年2月19日14:49
#4 楼
无需过多讨论,就可以使用netcat,网络瑞士刀。没有协议开销,您可以直接复制到网络套接字。示例
srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321
srv2$ nc -l -p 4321 |tar xfv -
评论
不幸的是,从我注意到的netcat效率来看,即使它不是应该的,它的效率也非常低。
–克里斯蒂安·丘皮图
09年6月2日在20:27
我拒绝您,因为这是非常非常糟糕的建议。有一个正确的答案:rsync。我可以列出所有更好的原因,但不适用于此页面,更不用说这个小小的注释框了。
– niXar
2011年5月4日,9:45
@niXar:如果您要做的只是一次文件传输(无需进一步同步),那么tarpipe实际上就是您所需要的。
–Witiko
13年6月14日,0:03
如果您在私有vlan和/或VPN等安全环境中进行此操作,则@niXar netcat很好。
–张怡
2013年6月25日在2:56
netcat对于安全的环境非常有用,除非您有点不习惯并且整个1TB数据流都不好。我有一个像这样的精心编写的脚本,具有并行压缩,进度输出(通过pv)和通过sha512sum进行完整性检查,但是一旦被翻转,整个流就很糟糕,因为无法恢复它。当我们需要低开销时,我们真正需要的是一种轻量级协议,例如流媒体洪流,用于我们需要低开销的东西-它将检查块(例如4MB)级别的完整性,并且在一个块出现故障时可以重新释放块。 TCP crc不够强大。
–丹尼尔·桑托斯(Daniel Santos)
19-10-9在21:36
#5 楼
如果您确实使用rsync,则有很多文件,我会尝试在两端获得版本3或更高版本。原因是较低的版本会在开始传输之前枚举每个文件。新功能称为增量递归。现在,当rsync与另一个3.x版本进行通讯时,将使用新的增量递归算法
。这样可以使传输更快地进行传输
(在找到所有文件之前),并且需要更少的内存。
有关某些限制,请参见联机帮助页中的--recursive选项。
#6 楼
昨天在移动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所做的更改的区别。这是我老板的主意,而我的同事都执行了这个主意,并在他的博客上做了精彩的文章。我只喜欢漂亮的照片。 :)
评论
我信任的一位黑客告诉我“在tc上比在nfs上运行tar甚至可能更快”。即tar cf-目录| ttcp -t dest_machine来自ftp.arl.mil/mike/ttcp.html
– Philip Durbin
2012年4月4日13:20
不相关的问题,但是该图来自何处?
–CyberJacob
2014年6月11日19:48在
#7 楼
像其他人已经推荐的rsync。如果加密产生的CPU开销是瓶颈,请使用另一种CPU占用率较低的算法,例如河豚。例如。像rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path
评论
+1表示更改密码
–丹尼尔·劳森(Daniel Lawson)
09年3月3日,0:37
除非您拥有10G以太网和10年的CPU,否则CPU不会成为瓶颈。
– niXar
2011年5月4日上午10:46
只需评论:密码“ -c arcfour”的速度更快。
–Arman
2013年5月3日13:58
@niXar:但是,如果您的计算机上已经有消耗CPU的任务,那就很麻烦了。
–艾萨克
2014年12月20日上午11:44
#8 楼
复制大量文件时,我发现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
#9 楼
我也通过netcat
方法使用tar,但我更喜欢使用socat
-例如,通过调整mss,可以为您的情况进行优化以提供更多功能。 (也可以根据需要笑,但是我发现socat
参数更容易记住,因为它们是一致的)。所以对我来说,最近这很普遍,因为我一直在将事物转移到新服务器上:host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum
host2$ socat tcp4-listen:portnum stdout | tar xvpf -
别名是可选的。
#10 楼
另一种选择是Unison。在这种情况下,它的效率可能比Rsync略高,并且设置侦听器也更容易。#11 楼
似乎最高答案中可能有一些错别字。这可能会更好:tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'
评论
我发现使用-f选项时命令失败。
–user11749
2012年7月20日14:22
@ user11749:该命令中有两个-f选项,这两个都是必需的。您是否在谈论将-f传递给ssh以使其进入后台?
–溯源
2012年7月26日在13:59
#12 楼
网络文件系统(NFS),然后使用您喜欢的任何文件进行复制,例如午夜指挥官(MC),鹦鹉螺(来自gnome)。我使用了NFS v3,效果很好。
Samba(CIFS),然后用您想要的任何方式复制文件,但是我不知道它的效率如何。
Evan Anderson建议的带有
wget --mirror
的HTTP或任何其他HTTP客户端。注意不要有任何讨厌的符号链接或误导性的索引文件。如果您只有MP3,那应该很安全。rsync。我使用它的效果非常好,它的一个不错的功能是您可以稍后中断并继续传输。
我注意到其他人建议使用netcat。根据我的经验,我可以说与其他解决方案相比,它的速度较慢。
#13 楼
感谢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
是并行gzip该程序默认使用与CPU一样多的线程(我相信最多8个线程)。您可以调整压缩级别以更好地适应CPU与网络带宽的比率,如果CPU的带宽远远大于带宽,则可以将其替换为pigz
和pxz -9e
。您只需要在完成时验证两个总和是否匹配即可。此选项对大量数据以及高延迟网络很有用,但是在链接不稳定且掉线的情况下却无济于事。在这些情况下,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 =等相同。
复制文件系统时这样,我通常会先将大多数未使用的空间
pxz -d
设为零,这会加快xfer的速度。#14 楼
我认为除非安装更快的网卡,否则您不会比scp做得更好。如果您通过Internet进行此操作,那将无济于事。我建议使用rsync。它可能没有更快的速度,但是至少如果失败了(或者因为它花费的时间太长而将其关闭),则可以在下一次中断的地方继续。
如果可以连接2直接使用千兆以太网的计算机,这可能是最快的。
评论
我之间直接有一个未使用的100mbps链接
– nicudotro
09年6月2日在20:02
不会比SCP做得更好吗? SCP正在通过加密步骤推送所有数据。 SCP将成为复制它的最慢方式之一!
–埃文·安德森(Evan Anderson)
09年6月2日在20:02
SCP对数据进行加密是正确的,但是加密速度比网络连接快几个数量级,因此可以忽略不计。
–布伦特
2009年6月3日15:37
#15 楼
对于100Mb / s,理论吞吐量为12.5 MB / s,因此在10MB / s时,您的表现还不错。我也赞同建议通过rsh进行rsync。诸如此类:
rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST
在100Mb / s的速度下,您的CPU应该能够处理加密/解密,而不会明显影响数据速率。而且,如果您中断了数据流,则应该能够从上次中断的地方恢复。当心,随着“数百万”个文件的启动,启动将需要一段时间才能真正传输任何内容。
#16 楼
除了我正在传输Oracle日志外,我已经遇到了这一点。这里是故障
inefficient and encrypted (encrypted = slower than unencrypted
depending on the link and your processor)
rsync
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交叉电缆上运行缓慢,则绝对需要解决。
#17 楼
您没有提及两台计算机是否在同一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。)#18 楼
用正确的选项简单SCP将轻松达到9-10 MB / s以上LAN:scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote
随着/>这些选择很可能是吞吐量成为4倍或5倍比没有快选项(默认)
评论
而不是一百万个小文件。您是否尝试过自己的解决方案?
– Sajuuk
19-4-3在6:33
#19 楼
如果在src端有ftp服务器,则可以从ncftp站点使用ncftpget。它可以在内部使用tar的情况下处理小型文件。一个比较显示了这一点:移动1.9GB的小型文件(33926个文件)
使用scp需要11m59s
使用rsync需要7分10秒
使用ncftpget需要1分20秒
#20 楼
您也可以尝试使用BBCP命令进行传输。这是一个真正尖叫的缓冲并行ssh。如果我们可以保持管道进给,通常我们可以得到90%+的线速。$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'
通常,我们会尽力避免不必要地移动袖带。我们使用ZFS池,总是可以向其中添加更多的磁盘空间。但是有时候...你只需要移动东西。如果我们有一个“实时”文件系统,即使进行完全爆炸,它也可能要花费数小时(或数天)进行复制。.我们执行两步zfs发送例程:
ZFS快照,并传输到新计算机上的新池中。让它花费尽可能长的时间。
再创建一个快照,并将其作为增量发送。增量快照仅包含自第一个以来的(小得多)变更集,因此它的处理速度相对较快。
完成增量快照后,您可以翻转原始快照并切换到新副本,并且将“离线停机时间”保持在最低限度。
我们也通过BBCP发送我们的zfs转储...这可以最大程度地提高网络利用率并缩短传输时间。
BBCP是免费提供的,您可以在Google上对其进行搜索,并且它是直接的编译器。只要将其复制到src和目标计算机上的/ usr / local / bin中,它就可以正常工作。
#21 楼
我想我的回答来晚了一点,但是我在使用一台服务器上的mc(午夜指挥官)通过SFTP连接到另一台服务器上有了很好的经验。通过FTP连接的选项位于在“左侧”和“右侧”菜单中输入以下地址:
/#ftp:name@server.xy/
或
/#ftp:name@ip.ad.dr.ess/
您可以像在本地文件系统上一样导航和执行文件操作。
它具有内置选项,可以在后台进行复制,但是我更喜欢使用screen命令并与mc正在复制时的屏幕(我想它的运行速度也会更快)。
#22 楼
要rsync选项的@scottpack答案要显示上载进度,请在命令中的-avW之后使用'--progess'作为选项,如下所示。
rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir
#23 楼
这是一个比较一些技术的快速基准测试,来源是4核Intel(R)Xeon(R)CPU E5-1620 @ 3.60GHz,具有250
Mbps和SATA驱动器
目标是6核Intel®Xeon(R)CPU
E-2136 @ 3.30GHz,具有1 Gbps带宽和SSD驱动器
文件数:9632,
总大小:814 MiB,
平均大小:84 KiB
RSYNC:1m40.570s
RSYNC +压缩:0m26.519s
TAR + NETCAT:1m58.763s
TAR +压缩+ NETCAT:0m28.009s
tar / netcat的命令为:
Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -
#24 楼
rsync或您可能希望将其压缩为一个文件,然后将其压缩。如果缺少磁盘空间,则可以在制作tar时直接将其通过ssh传递给管道。#25 楼
如果您要通过MP3和其他压缩文件进行发送,则任何试图进一步压缩这些文件的解决方案都不会带来太多好处。解决方案是可以在两个服务器之间创建多个连接,从而对两个系统之间的带宽施加更大的压力。一旦达到极限,不改善硬件就无济于事。 (例如,这些服务器之间的快速网卡。)#26 楼
我尝试了几种用于复制1GB文件的工具结果如下:
HTTP最快,而wget -c
rsync使用ssh作为后端,因此结果相同。
最后,我将使用wget -bqc选择http并给它一些时间。
希望这会有所帮助
评论
您是否了解http为什么最快?
– Sajuuk
19年4月3日在6:34
#27 楼
我必须将BackupPC磁盘复制到另一台计算机上。我使用了rsync。
该计算机具有256 MB的内存。
过程我接下来是这个:
执行了没有
rsync
的-H
(花了9个小时)rsync完成后,我同步了
cpool
目录并从pc
目录开始;我中断了传输。然后使用
rsync
标志重新启动了-H
,所有在pc
目录中硬链接的文件都已正确传输(该过程在cpool
中找到了所有真实文件,然后链接到pc
目录)(耗时3个小时) )。最后我可以用
df -m
验证是否没有多余的空间。这样,我就可以避免内存和rsync的问题。我一直都可以使用top和top验证性能,最后我传输了165GB的数据。
评论
服务器之间有什么样的网络。我在每台计算机的1个NIC之间使用了GB以太网交叉。通过使用SCP进行该配置,我获得了很好的结果
您可能想调查为什么scp这么慢。由于加密,它可能比ftp之类的东西要慢,但是它不应该那么慢。
我之间有100 mbps。小文件(大多数文件很小)上的scp较慢