Nat*_*ord 21 linux files rsync scp
我正在尝试通过 10MB 链接将 75 GB 的 tgz（mysql lvm 快照）从我们洛杉矶数据中心的 Linux 服务器复制到我们纽约数据中心的另一台 Linux 服务器。
我得到大约 20-30Kb/s 的 rsync 或 scp，它在 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 链接。（耸肩）
KPW*_*INC 16
有人吗？
假设这是一次性复制，我认为不可能将文件复制到 CD（或其他媒体）并在一夜之间将其复制到目的地？
这实际上可能是您最快的选择，因为通过该连接传输该大小的文件可能无法正确复制......在这种情况下，您将重新开始。
同步
我的第二个选择/尝试是 rsync，因为它可以检测失败的传输、部分传输等，并且可以从中断的地方继续。
rsync --progress file1 file2 user@remotemachine:/destination/directory
--progress 标志会给你一些反馈，而不是只是坐在那里让你自己猜测。:-)
Vuze (bittorrent)
第三个选择可能是尝试使用 Vuze 作为 Torrent 服务器，然后让您的远程位置使用标准的 bitorrent 客户端下载它。我知道其他人已经这样做了，但你知道......当他们把它全部设置好时，等等......我可以在一夜之间把数据......
看你的情况我猜。
祝你好运！
更新：
你知道，我更多地考虑了你的问题。为什么文件必须是一个巨大的 tarball？Tar 完全能够将大文件拆分为较小的文件（例如跨媒体），那么为什么不将这个巨大的 tarball 拆分为更易于管理的部分，然后将这些部分转移过来呢？
我过去做过，有一个 60GB 的 tbz2 文件。我没有脚本了，但重写它应该很容易。
首先，将您的文件分成 ~2GB 的部分：
split --bytes=2000000000 your_file.tgz
对于每个片段，计算一个 MD5 哈希值（这是为了检查完整性）并将其存储在某处，然后开始使用您选择的工具将片段及其 md5 复制到远程站点（我：屏幕中的 netcat-tar-pipe会议）。
过了一会儿，用 md5 检查你的作品是否还好，然后：
cat your_file* > your_remote_file.tgz
如果您还对原始文件做过 MD5，也请检查一下。如果没问题，你可以解压你的文件，一切都应该没问题。
（如果我找到时间，我会重写脚本）
通常我是 rsync 的忠实拥护者，但是当第一次传输单个文件时，它似乎没有多大意义。但是，如果您仅以细微差别重新传输文件，那么 rsync 将是明显的赢家。如果您无论如何都选择使用 rsync，我强烈建议您在--daemon模式下运行一端以消除影响性能的 ssh 隧道。手册页非常彻底地描述了这种模式。
我的推荐？带有支持恢复中断下载的服务器和客户端的 FTP 或 HTTP。这两种协议都快速且轻量级，避免了 ssh-tunnel 惩罚。Apache + wget 会很快尖叫。
netcat 管道技巧也可以正常工作。传输单个大文件时不需要 Tar。当它完成时它没有通知你的原因是因为你没有告诉它。-q0向服务器端添加一个标志，它的行为将完全符合您的预期。
server$ nc -l -p 5000 > outfile.tgz 客户端$ nc -q0 server.example.com 5000 < infile.tgz
netcat 方法的缺点是，如果您的传输在 74GB 中死亡，它将不允许您继续...