主页 / server / 问题 / 53531
Accepted
Nathan Milford
Asked: 2009-08-13 18:07:28 +0800 CST

将大文件从一台 Linux 服务器复制到另一台

  • 772

我正在尝试通过 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

获取快照压缩包。

[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

获取快照压缩包。

[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 链接。（耸肩）

linux

10 个回答

  1. Best Answer

    有人吗？

    假设这是一次复制，我认为不可能将文件复制到 CD（或其他媒体）并在一夜之间将其复制到目的地吗？

    这实际上可能是您最快的选择，因为通过该连接传输该大小的文件可能无法正确复制……在这种情况下，您可以重新开始。

    rsync

    我的第二个选择/尝试是 rsync，因为它检测到失败的传输、部分传输等，并且可以从中断的地方继续。

    rsync --progress file1 file2 user@remotemachine:/destination/directory

    --progress 标志会给你一些反馈，而不是坐在那里让你自己去猜测。:-)

    Vuze (bittorrent)

    第三种选择可能是尝试使用 Vuze 作为 torrent 服务器，然后让您的远程位置使用标准的 bitorrent 客户端下载它。我知道其他人已经这样做了，但你知道......当他们把它全部设置好运行时，等等......我本可以在一夜之间保存数据......

    取决于你的情况，我猜。

    祝你好运！

    更新：

    你知道，我开始考虑你的问题了。为什么文件必须是一个巨大的压缩包？Tar 完全有能力将大文件拆分成较小的文件（例如跨媒体），那么为什么不将那个巨大的 tarball 拆分成更易于管理的部分，然后将这些部分转移过来呢？

    • 17

  2. 我过去曾使用 60GB tbz2 文件这样做过。我没有脚本了，但重写它应该很容易。

    首先，将文件拆分为 ~2GB 的片段：

    split --bytes=2000000000 your_file.tgz

    对于每个片段，计算一个 MD5 哈希（这是为了检查完整性）并将其存储在某处，然后使用您选择的工具开始将片段及其 md5 复制到远程站点（我：屏幕中的 netcat-tar-pipe会议）。

    过了一会儿，用 md5 检查你的棋子是否还好，然后：

    cat your_file* > your_remote_file.tgz

    如果您还对原始文件进行了 MD5，请也进行检查。如果没问题，你可以解压你的文件，一切都应该没问题。

    （如果我有时间，我会重写脚本）

    • 9

  3. 通常我是 rsync 的大力倡导者，但是当第一次传输单个文件时，它似乎没有多大意义。但是，如果您重新传输文件时只有细微的差别，那么 rsync 将是明显的赢家。如果您仍然选择使用 rsync，我强烈建议您在--daemon模式下运行一端，以消除影响性能的 ssh 隧道。手册页非常彻底地描述了这种模式。

    我的推荐？带有支持恢复中断下载的服务器和客户端的 FTP 或 HTTP。两种协议都快速且轻量级，避免了 ssh 隧道的损失。Apache + wget 会尖叫得很快。

    netcat 管道技巧也可以正常工作。传输单个大文件时不需要 Tar。它完成后没有通知你的原因是你没有告诉它。向服务器端添加一个-q0标志，它的行为将完全符合您的预期。

    服务器$ nc -l -p 5000 > outfile.tgz

客户端$ nc -q0 server.example.com 5000 < infile.tgz

    netcat 方法的缺点是，如果您的传输在 74GB 中终止，它将不允许您恢复...

    • 5

  4. 试一试 netcat（有时称为 nc）。以下适用于目录，但它应该很容易调整以处理一个文件。

    在目标框中：

    netcat -l -p 2342 | tar -C /target/dir -xzf -

    在源框上：

    tar czf * | netcat target_box 2342

    您可以尝试删除两个 tar 命令中的“z”选项，以加快速度，因为文件已经被压缩。

    • 3

  5. 对于大文件，默认 SCP 和 Rsync（使用 SCP）非常慢。我想我会考虑使用开销较低的协议。您是否尝试过使用更简单的加密密码，或者根本不使用？尝试查看--rshrsync 的选项以更改传输方法。

    为什么不是 FTP 或 HTTP？

    • 1

  6. 虽然它增加了一些开销，但 BitTorrent 实际上是传输大文件的一个非常好的解决方案。BitTorrent 有很多不错的功能，例如本地分块文件并对每个块进行校验和，如果损坏可以重新传输。

    像Azureus [现在称为 Vuze] 这样的程序包含您在一个应用程序中创建、服务器和下载种子所需的所有部分。Bean in mind Azureus 不是 BitTorrent 可用的最精简的解决方案，我认为也需要它的 GUI——尽管有很多用于 linux 的命令行驱动的 torrent 工具。

    • 1

  7. 嗯，就个人而言，对于 10Mb（假设是 10Mb 而不是 10MB）链接来说，20-30Kb/s 似乎相当低。

    如果我是你，我会做两件事之一（假设物理访问不可用） -

    无论是哪一种，我都建议您将大文件分成较小的块，大约 500MB 以防万一在传输过程中损坏。

    当您拥有较小的块时，请再次使用 rsync，或者我个人更喜欢使用私有安全 ftp 会话，然后在完成后对文件进行 CRC 校验。

    • 0

  8. 几个问题可能有助于讨论：要传输的数据到底有多重要？这是用于灾难恢复、热备份、离线存储还是什么？您打算在数据库启动或关闭时备份数据库吗？在远程系统上设置数据库并使用集群或通过更改日志更新使它们保持同步怎么样（我并不完全精通 MySql 数据库系统的功能）。这可能有助于减少需要通过链路传输的数据量。

    • 0

  9. bbcp 将为您分块文件并使用多个流进行复制。

    • 0

  10. 谷歌员工的迟到答案：

    传输大型数据集时，可以使用 rsync 比较源和目标，然后使用 --only-write-batch 标志将批处理文件写入本地可移动媒体。然后，您将本地媒体发送到远程位置，将其插入并再次运行 rsync，使用 --read-batch 将更改合并到远程数据集中。

    如果源文件在物理传输期间发生更改，或者传输介质已满，您可以继续重复 --only-write-batch | 船舶| --read-batch 循环直到目的地都被赶上。

    （参考：我是 rsync 中此功能的作者之一——有关更多背景和用例，请参阅原型实现的讨论： https ://lists.samba.org/archive/rsync/2005-March/011964 .html )

    • 0

相关问题