我试图从我们的洛杉矶数据中心的一台Linux服务器上复制一个75GB的tgz（mysql lvm快照）到我们纽约数据中心的另一台Linux服务器。
我得到大约20-30Kb / s的rsync或scp在200-300小时之间波动。
目前这是一个相对比较安静的环节，因为第二个数据中心还没有启动，而且我从小文件传输中获得了出色的速度。
我跟着不同的tcp调优指南，我发现通过谷歌无济于事（也许我正在阅读错误的指南，得到一个很好的？）。
我已经看到了tar + netcat的隧道提示，但是我的理解是，只有在文件被有效地完成传输的时候才会更新你的小文件。
之前我诉诸硬盘驱动器，有没有人有任何好的投入？
更新：嗯…它可能是链接afterall :(请参阅我的testing下面…
从纽约转到洛杉矶：
获取一个空白文件。
[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000 4700000+0 records in 4700000+0 records out 4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s [nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST . FROM_NY_TEST 3% 146MB 9.4MB/s 07:52 ETA 获取快照tarball。
[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz -rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz [nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz . db_dump.08120922.tar.gz 0% 56MB 574.3KB/s 14:20:40 ET
从洛杉矶转到纽约：
获取一个空白文件。
[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000 4700000+0 records in 4700000+0 records out 4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s [nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST . FROM_LA_TEST 0% 6008KB 497.1KB/s 2:37:22 ETA
获取快照tarball。
[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz -rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz [nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz . db_dump_08120901.tar.gz 0% 324KB 26.8KB/s 314:11:38 ETA
我想我会和运行我们设施的人一起把链接标记为MPLS /以太网10MB链接。 （耸肩）
Sneakernet有人吗？
假设这是一次性复制，我不认为只是将文件复制到CD（或其他介质），并将它过夜到达目的地？
这实际上可能是你最快的select，因为这个大小的文件传输，可能无法正确复制…在这种情况下，你可以重新开始。
rsync的
我的第二select/尝试是rsync，因为它检测到失败的传输，部分传输等，并可以从中断的地方拿起。
rsync --progress file1 file2 user@remotemachine:/destination/directory
– 进步标志将给你一些反馈，而不是坐在那里，让你第二次猜测自己。 🙂
Vuze（bittorrent）
第三种select可能是尝试使用Vuze作为Torrent服务器，然后让您的远程位置使用标准的bitorrent客户端来下载它。 我知道其他人已经这样做了，但是你知道…当他们把所有的东西都build立起来了，等等…我可能会对数据进行过度的检测。
取决于你的情况我猜。
祝你好运！
更新：
你知道，我想到你的问题多一点。 为什么文件必须是一个巨大的tarball？ Tar完全可以将大文件分割成小文件（例如跨越媒体），那么为什么不把这个庞大的压缩文件分割成更多的可pipe理的文件，然后把这些文件转移过来呢？
过去我已经做了60GB的tbz2文件。 我不再有脚本，但应该很容易重写它。
首先，把你的文件分成〜2GB的块：
split --bytes=2000000000 your_file.tgz
对于每一块，计算一个MD5散列（这是为了检查完整性）并将其存储在某个地方，然后开始使用您select的工具（me：netcat-tar-pipe在屏幕中将碎片和它们的md5复制到远程站点会话）。
过了一段时间，如果你的作品没问题的话，查看md5，然后：
cat your_file* > your_remote_file.tgz
如果您还完成了原始文件的MD5，请检查它。 如果没关系，你可以解压你的文件，一切都可以。
（如果我find时间，我会重写脚本）
通常我是rsync的大提倡者，但是当第一次传输单个文件的时候，似乎没什么意义。 但是，如果您只是稍有不同的重新传输文件，rsync将是明显的赢家。 如果您select使用rsync，我强烈build议在--daemon模式下运行一个端点来消除性能查杀ssh隧道。 手册页相当透彻地描述了这种模式。
我的build议？ FTP或HTTP与服务器和客户端，支持恢复中断的下载。 两种协议都是快速和轻量级的，避免了ssh-tunnel的惩罚。 Apache + wget会快速尖叫。
netcatpipe道技巧也将工作正常。 传输单个大文件时，不需要焦油。 而当它完成时没有通知你的原因是因为你没有告诉它。 将一个-q0标志添加到服务器端，它的行为将与您所期望的完全一致。
服务器$ nc -l -p 5000> outfile.tgz 客户端$ nc -q0 server.example.com 5000 <infile.tgz
netcat方法的缺点是，如果你的转移死在74GB的话，它不会让你恢复。
给netcat（有时叫nc）一枪。 下面的工作目录，但它应该很容易调整，只是应付一个文件。
在目的地框上：
netcat -l -p 2342 | tar -C /target/dir -xzf -
在源框中：
tar czf * | netcat target_box 2342
您可以尝试删除两个tar命令中的'z'选项，以更快的速度查看文件已被压缩。
默认的SCP和Rsync（使用SCP）对于大文件来说非常慢。 我想我会考虑使用较低开销的协议。 你有没有尝试过使用一个更简单的encryption密码，或者根本不？ 尝试查看rsync的--rsh选项来更改传输方法。
为什么不是FTP或HTTP？
虽然它增加了一些开销的情况BitTorrent实际上是一个非常好的解决scheme来传输大文件。 BitTorrent有很多很好的function，如本地分块文件和校验每个块可以重新传输，如果损坏。
像Azureus （现在称为Vuze）这样的程序包含了您将需要创build，服务器和下载种子在一个应用程序中的所有作品。 Bean记住，Azureus并不是BitTorrent可用的最精简的解决scheme，我想也需要它的GUI – 尽pipe如此，还是有很多命令行驱动的torrent工具。
那么对于一个10Mb（假设是10Mb而不是10MB）链路来说，20-30Kb / s似乎相当低。
如果我是你，我会做两件事情之一（假设没有物理访问） –
无论哪一种，我build议您将大文件拆分成更小的块，大约500MB只是在运输过程中腐败。
当你有更小的块时，再次使用rsync，或者我个人更喜欢使用专用的安全ftp会话，然后在完成时对文件进行CRC校验。
有几个问题可能有助于讨论：数据传输的关键程度如何？ 这是用于灾难恢复，热备份，离线存储还是什么？ 你打算在数据库启动的时候备份吗？ 在远程系统上设置一个数据库，并通过更新日志进行集群或更新（我不完全熟悉MySql数据库系统的function）来保持同步。 这可能有助于减less需要通过链接传输的数据量。
bbcp将为你的文件块和复制多个stream。