我正尝试通过 10MB 链接将 75 GB 的 tgz（mysql lvm 快照）从我们洛杉矶数据中心的 Linux 服务器复制到我们纽约数据中心的另一台 Linux 服务器。
我使用 rsync 或 scp 获得的速度约为 20-30Kb/s，波动时间在 200-300 小时之间。
目前这是一个相对安静的链接，因为第二个数据中心尚未激活，并且我从小文件传输中获得了出色的速度。
我按照通过谷歌找到的不同的 tcp 调整指南进行操作，但无济于事（也许我读错了指南，有好的指南吗？）。
我已经看到了 tar+netcat 隧道提示，但我的理解是它只适用于大量小文件，并且在文件有效传输完成时不会更新您。
在我决定运送硬盘之前，有人有什么好的建议吗？
更新： 嗯...它可能毕竟是链接 :( 请参阅下面的测试...
从纽约到洛杉矶的交通：
获取一个空白文件。
[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 链接。（耸肩）
答案1
有谁知道 Sneakernet 吗？
假设这是一次性复制，我不认为可以将文件复制到 CD（或其他媒体）并在一夜之间将其送到目的地，对吗？
这实际上可能是最快的选择，因为通过该连接传输该大小的文件可能无法正确复制……在这种情况下，您必须重新开始。
同步
我的第二选择/尝试是 rsync，因为它可以检测失败的传输、部分传输等，并且可以从中断的地方继续。
rsync --progress file1 file2 user@remotemachine:/destination/directory
--progress 标志会给你一些反馈，而不是只是呆在那里让你自己猜测。:-)
Vuze (Bittorrent)
第三种选择可能是尝试使用 Vuze 作为 torrent 服务器，然后让您的远程位置使用标准 bitorrent 客户端下载它。我知道其他人也这样做过，但你知道……等他们把一切都设置好运行起来，等等……我可能已经连夜拿到了数据……
我想这取决于你的情况。
祝你好运！
更新：
你知道，我对你的问题有了更多的思考。为什么文件必须是一个巨大的 tarball？Tar 完全有能力将大文件分割成小文件（例如，跨媒体），那么为什么不将那个巨大的 tarball 分割成更易于管理的部分，然后将这些部分传输过来呢？
答案2
我以前也做过这个，用的是 60GB 的 tbz2 文件。我不再有这个脚本了，但重写它应该很容易。
首先，将文件分成~2GB 大小的块：
split --bytes=2000000000 your_file.tgz
对于每个片段，计算一个 MD5 哈希值（这是为了检查完整性）并将其存储在某处，然后开始使用您选择的工具（我：屏幕会话中的 netcat-tar-pipe）将这些片段及其 md5 复制到远程站点。
过一会儿，使用 md5 检查你的片段是否正确，然后：
cat your_file* > your_remote_file.tgz
如果你也对原始文件进行了 MD5 校验，也请检查一下。如果没问题，你可以解压文件，一切应该没问题。
（如果有时间我会重写剧本）
答案3
通常情况下，我非常支持 rsync，但当第一次传输单个文件时，它似乎没有多大意义。但是，如果您重新传输的文件只有细微的差异，rsync 显然是赢家。如果您无论如何都选择使用 rsync，我强烈建议您运行一端--daemon模式以消除性能下降的 ssh 隧道。手册页非常详细地描述了此模式。
我的建议是使用支持恢复中断下载的服务器和客户端的 FTP 或 HTTP。这两种协议都快速且轻量，避免了 ssh-tunnel 的惩罚。Apache + wget 的速度会非常快。
netcat 管道技巧也很好用。传输单个大文件时不需要 Tar。它没有在完成时通知您，是因为您没有告诉它。-q0在服务器端添加一个标志，它就会按照您预期的方式运行。
服务器$ nc -l -p 5000 > outfile.tgz 客户端$ nc -q0 server.example.com 5000 < infile.tgz
Netcat 方法的缺点是如果您的传输在 74GB 时终止，它将不允许您恢复......
答案4
默认 SCP 和 Rsync（使用 SCP）对于大文件来说非常慢。我想我会考虑使用开销较低的协议。您是否尝试过使用更简单的加密密码，或者根本没有尝试过？尝试查看--rshrsync 的选项以更改传输方法。
为什么不使用 FTP 或 HTTP？