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

我需要在两个服务器(Ubuntu)之间传输大量的mp3。 巨大的我的意思是大约一百万个文件平均30万。 我试着用scp但是大概需要一个星期。 (约500 KB / s)如果我通过HTTP传输单个文件,我得到9-10 MB / s,但我不知道如何传输所有这些文件。

有没有办法快速转移他们所有的人?

    我会推荐焦油。 当文件树已经相似时,rsyncperformance非常好。 但是,由于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正在encryption所有内容(从而瓶颈CPU)。 由于HTTP和rsync没有进行encryption,因此移动速度会更快。

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

    那些文档讨论通过SSH隧道rsync,但如果你只是在私人局域网上移动数据,你不需要SSH。 (我假设你在一个私有的局域网上,如果你通过互联网获得了9-10MB /秒,那么我想知道你有什么样的连接!)

    这里有一些非常基本的文档,可以让你设置一个相对不安全的rsync服务器(不依赖于SSH)​​: http : //transamrit.net/docs/rsync/

    没有太多的讨论,使用netcat,networkingswissarmy刀。 没有协议开销,你直接复制到networking套接字。 例

     srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321 srv2$ nc -l -p 4321 |tar xfv - 

    如果你使用rsync的时候有很多的文件, 我会尝试在两端获得版本3或更高版本 。 原因是较小的版本会在开始传输之前枚举每个文件。 新function称为增量recursion

    当rsync与另一个3.x版本交谈时,现在使用新的增量recursionalgorithm。 这将开始更快的传输(在find所有文件之前),并且需要更less的内存。 请参阅联机帮助页中的–recursive选项以了解一些限制。

    rsync,像其他人已经推荐。 如果来自encryption的CPU开销是一个瓶颈,那么使用另一种CPU密集型algorithm,如河豚。 比如像

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

    当复制大量的文件时,我发现像tar和rsync这样的工具比他们需要的效率更低,因为打开和closures许多文件的开销。 我写了一个名为fast-archiver的开源工具,这个工具比tar更快: https : //github.com/replicon/fast-archiver ; 它通过执行多个并发文件操作而工作得更快。

    这里有一个快速归档器与tar对超过两百万个文件备份的例子; 快速归档器需要27分钟才能归档,而焦油需要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的fast-archiver,如下所示:

     ssh [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x 

    我也通过netcat方式使用焦油,除了我更喜欢使用socat – 更多的权力来优化你的情况 – 例如,通过调整mss。 (另外,如果你想要笑,但是我发现社会论点更容易记住,因为它们是一致的)。 所以对我来说,最近这种情况非常普遍,因为我一直在把东西搬到新的服务器上:

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

    别名是可选的。

    另一种select是Unison 。 在这种情况下,可能会比Rsync稍微高效一些,并且build立一个监听器也比较容易。

    看起来好像在顶部的答案可能有几个错别字。 这可能会更好地工作:

     tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir' 
    • networking文件系统(NFS) ,然后将它们复制到任何你喜欢的地方,例如Midnight Commander(mc),Nautilus(来自gnome)。 我已经使用了NFS v3,效果很好。
    • 桑巴(CIFS) ,然后复制文件与任何你想要的,但我不知道它是多么高效。
    • HTTP作为Evan Andersonbuild议的wget --mirror或任何其他的http客户端。 注意不要有任何令人讨厌的符号链接或误导索引文件。 如果你拥有的是MP3,你应该是安全的。
    • rsync 。 我已经使用它有相当好的结果,它的一个很好的function是,你可以中断并恢复传输。

    我注意到其他人推荐使用netcat 。 根据我的经验 ,我可以说,与其他解决scheme相比,它是缓慢的。

    在昨天移动了80TB的数据(数百万个微小的文件)之后,从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/ 

    由于这些服务器位于同一局域网上,所以在源系统上进行NFS安装的目的地正在进行推送。 没有更快,我们决定不保留文件的时间:

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

    下面的graphics描述了从rsync到tar所作的改变的区别。 这是我的老板的想法,我的同事都执行了它,并在他的博客做了很好的写作 。 我只是喜欢漂亮的照片 。 🙂

    rsync_vs_tar

    除非安装速度更快的网卡,否则我认为你不会比scp做得更好。 如果你通过互联网做这个,那也不会有帮助。

    我会build议使用rsync 。 这可能不会更快,但至less如果失败(或者因为时间太长而closures它),则可以在下次停止的地方重新开始。

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

    对于100Mb / s的理论吞吐量是12.5 MB / s,所以在10MB / s的时候你performance的相当不错。

    我也会回应build议做rsync,可能通过ssh。 就像是:

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

    在100Mb / s时,CPU应该能够处理encryption/解密,而不会明显影响数据速率。 如果你打断数据stream,你应该可以从你离开的地方恢复。 要小心,有了“数以百万计”的文件,启动需要一段时间才能实际传输任何内容。

    一个简单的scp和适当的选项将很容易通过局域网达到9-10 MB / s:

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

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

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

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

    通常情况下,我们尽量避免不得不移动。 我们使用ZFS池,我们总是可以“添加”更多的磁盘空间。 但有时候…你只需要移动东西。 如果我们有一个“活的”文件系统,甚至在全速启动时可能需要几个小时(或几天)的复制。我们执行两步zfs发送例程:

    1. 创build一个ZFS快照,并转移到新机器上的新池中。 只要花费时间就可以了。
    2. 制作第二张快照,并将其作为增量发送。 增量快照只包括自第一个以来(更小的)变更集,所以它相对较快。
    3. 一旦完成增量快照,您可以将原始文件转换为新的副本,并将“脱机停机时间”保持在最小值。

    我们还通过BBCP发送了我们的zfs转储…它最大限度地提高了我们的networking利用率并最大限度地减less了传输时间。

    BBCP是免费的,你可以谷歌它,这是一个直前进的编译。 只需将它复制到src和目标计算机上的/ usr / local / bin中,就可以工作了。

    rsync或者你可能希望将其全部放在一个文件中然后scp。 如果你缺less磁盘空间,你可以通过ssh直接通过ssh进行pipe道传输。

    如果您通过MP3和其他压缩文件发送,您将不会从任何试图进一步压缩这些文件的解决scheme中获得太多收益。 该解决scheme可能会在两台服务器之间创build多个连接,从而更加重视两个系统之间的带宽。 一旦这最大化,没有多less可以得到没有改善您的硬件。 (例如,在这些服务器之间使用更快的网卡。)

    我遇到过这个问题,除了我正在传输Oracle日志。

    这是故障

    • SCP

       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取得了很大的成功(在Gbnetworking上取得了巨大的成功,相当于〜700Mb / s)。 如果你得到了10MB(相当于80Mb / s),那么可能是错误的。

    你能告诉我们关于数据的来源和目的地吗? 单驱动器是单驱动器吗? RAID到USB?

    我知道这个问题已经有了答案,但是如果你的networking在Gb / s交叉电缆上运行速度很慢,那么绝对需要固定的东西。

    你没有提到两台机器是否在同一个局域网上,或者安全通道(如使用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> 

    它具有以下优点:

    • 没有CPU的开销为ssh有encryption。
    • gzip -1提供轻量级的压缩而不会使CPU饱和,所以它可以很好的权衡,在保持最大吞吐量的同时给予一点压缩。 (对于MP3数据可能不是那么有利,但是不会伤害。)
    • 如果您可以将文件分成多个组,则可以并行运行两个或更多pipe道,确保您的networking带宽饱和。

    例如,

     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 -1pipe道来避免CPU饱和。 (或者至less将CompressionLevel设置为1)

    我尝试了几个工具来复制一个1GB的文件结果如下:HTTP最快,wget -c nc第二行scp最慢,并且失败了几次。 没有办法恢复rsync使用SSH作为后端,从而相同的结果。 总之,我会用wget-bqc去寻找http,并给它一些时间。 希望这有助于

    我不得不将BackupPC磁盘复制到另一台机器上。

    我使用rsync。

    机器有256 MB的内存。

    我遵循的程序是这样的:

    • 执行rsync没有-H (花了9个小时)
    • 当rsync完成时,我同步cpool目录,并开始与pc目录; 我切断了转移。
    • 然后用-H标志重新启动rsync ,并且所有硬链接到pc目录的文件都被正确地转移了(程序find所有在cpool的真实文件,然后连接到pc目录)(耗时3个小时)。

    最后我可以用df -m来validation没有额外的空间。

    通过这种方式,我逃避了内存和rsync的问题。 所有的时间我都可以使用top和atop来validation性能,最后我调用了165GB的数据。

    如果你在src端有ftp服务器,你可以使用ncftp站点的 ncftpget 。 它在内部使用tar时工作于小文件。

    一个比较显示:移动1.9GB小文件(33926个文件)

    1. 使用scp需要11m59s
    2. 使用rsync需要7m10s
    3. 使用ncftpget需要1m20s

    我想我的答案在这里有点晚,但是我在一台服务器上使用mc(Midnight Commander)通过SFTP连接到另一台服务器的过程中取得了很好的经验。

    通过FTP连接的选项是在“左”和“右”菜单,通过input地址如下所示:

     /#ftp:[email protected]/ 

    要么

     /#ftp:[email protected]/ 

    您可以导航并执行文件操作,就像在本地文件系统上一样。

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