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

我会推荐焦油。 当文件树已经相似时，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所作的改变的区别。 这是我的老板的想法，我的同事都执行了它，并在他的博客做了很好的写作 。 我只是喜欢漂亮的照片 。 🙂

除非安装速度更快的网卡，否则我认为你不会比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正在复制时从屏幕上分离（我认为它也运行得更快）。