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

20

我正在尝试通过10MB链接从LA数据中心的Linux服务器将75 GB的tgz（mysql lvm快照）复制到NY数据中心的另一台Linux服务器。

我通过rsync或scp获得大约20-30Kb / s的波动，波动在200-300小时之间。

目前，这是一个相对安静的链接，因为第二个数据中心尚未启用，并且小文件传输使我获得了极佳的速度。

我遵循了通过Google找到的各种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链接。（耸耸肩）

— 内森·米尔福德（Nathan Milford）
source

只是发表评论，我最近收到了软件供应商发布的有关Seagate FreeAgent（USB磁盘）的消息，该消息大约为50 GB。有问题的公司确实拥有网络，通常要求客户简单地从其网站下载。认为这是一个有趣的解决方案，并认为这可能会添加一些信息以帮助您做出决定。

— mdpc

您看到什么样的延迟？

— 09年

通过链接大约80毫秒。

— 内森·米尔福德

是的，现在我感到困惑和沮丧。我将其分割成50mb的块，但它仍然运行缓慢！但rsyncing其它数据得到500KB / s的......肯定有什么可怕的错误EHRE我失踪....

— 弥敦道米尔福德

使用检查您的流量tcpdump。它可以帮助您找出导致传输速度变慢的原因。

— lexsys

16

Sneakernet有人吗？

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

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

同步

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

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

--progress标志将为您提供一些反馈，而不仅仅是坐在那里让您自己进行第二次猜测。:-)

Vuze（bittorrent）

第三种选择可能是尝试将Vuze用作洪流服务器，然后让您的远程位置使用标准的bitorrent客户端下载它。我知道其他这样做的人，但您知道...等到他们全部设置好运行时，等等...我本来可以将数据过夜。

我猜要看你的情况。

祝好运！

更新：

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

— KPWINC
source

3

+1，尽管在这种情况下可能并不划算。永远不要低估747硬盘的带宽：）

— 乍得·休尼库特

2

我找不到该链接，但是几年前Google一直在寻找各种包装的驱动器。如果您可以将总计为500TB的驱动器从A点移动到B点，则以任何方式削减它都是非常好的带宽

— STW

2

也许您指的是本文： arstechnica.com/science/news/2007/03/…–

— KPWINC

1

是的，我最终运送了一块硬盘。有人告诉我，真正的问题是交换机上的流量控制。

— 森·米尔福德

如果您有多个播种者，则Bittorrent仅比直接转移更好。即使OP在多台计算机上安装bt，他也只有一个连接。而且他已经确定多个小文件的运行速度不会比一个大文件快，这将矛头指向了网络连接。

— Xalorous

7

我过去使用60GB的tbz2文件来完成此操作。我没有脚本了，但是应该很容易重写它。

首先，将文件拆分为〜2GB的大小：

split --bytes=2000000000 your_file.tgz

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

片刻之后，请使用md5检查是否还可以，然后：

cat your_file* > your_remote_file.tgz

如果您还对原始文件进行了MD5处理，也请进行检查。如果可以，则可以解压缩文件，一切都可以。

（如果发现时间，我将重写脚本）

— 埃多玛
source

5

通常，我是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中死了，它将不允许您继续使用。

— Insyte
source

+1为rsyncd。实际上，我将其用于LAN上的传输，因为与CIFS或NFS相比，我看到了更高的吞吐量。

— Ophidian

1

尽管FTP和HTTP避免了“ ssh-tunnel惩罚”，但需要考虑不加密数据的“惩罚”。

— J.Money

3

试一下netcat（有时称为nc）。以下内容适用于目录，但是只需应对一个文件即可进行调整。

在目标框上：

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

在源框中：

tar czf * | netcat target_box 2342

您可以尝试删除两个tar命令中的'z'选项，以提高速度，因为文件已被压缩。

— 大卫
source

1

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

为什么不使用FTP或HTTP？

— 身份
source

1

我在源代码上通过commandlinefu完成了“ python -m SimpleHTTPServer”操作，并在目标上获取了文件。我仍然收到“ 18.5K / s eta 15d 3h”

— Nathan Milford

1

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

像Azureus [现在称为Vuze]之类的程序包含在一个应用程序中创建，处理和下载torrent所需的所有内容。注意：Azureus并不是可用于BitTorrent的最精益的解决方案，而且我认为也需要其GUI-尽管有许多用于Linux的命令行驱动的torrent工具。

— 残疾人豹
source

如果存在多个种子，bt只会比直接转移更快。他只有一个消息来源。更重要的是，他的网络连接不良，源网络单一。即使将文件复制到本地多个位置，然后使用多个种子设置bt也会由于该不良连接而产生相反的效果。再加上制作多份副本并将其设置为种子会使复制时间增加而不是减少复制时间。如果OP试图将大文件提供给多个收件人，那么BT可能是一个可行的解决方案。

— Xalorous

0

好吧，个人而言，对于10Mb（假设10Mb而不是10MB）的链接，20-30Kb / s似乎非常低。

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

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

如果块较小，请再次使用rsync，或者我个人更喜欢使用专用的Secure ftp会话，然后在完成后对文件进行CRC校验。

— 威廉·希尔森
source

0

几个问题可能对讨论有帮助：传输的数据有多重要？这是用于灾难恢复，热备份，脱机存储还是什么？您打算在数据库启动或关闭时对其进行备份吗？怎么样在远程系统上建立数据库并使用群集或通过更改日志进行更新使它们保持同步（我并不完全了解MySql数据库系统的功能）。这可能有助于减少需要通过链接传输的数据量。

— mdpc
source

它是另一个MYSQL副本（我们在其他地方的主要MYSQL实例）的LVM快照。一旦转移并放置了目标mysql实例，就可以简单地更新该快照（将其用作增量）与当前主机之间的差异。这是MYSQL备份并不重要，它只是我只需要移动一次的一大块数据。

— 内森·米尔福德

0

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

— 扎尔
source

0

Google员工的最新答案：

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

如果源文件在物理传输过程中发生更改，或者传输介质已满，则可以继续重复--only-write-batch |。船| --read-batch循环，直到目的地全部被捕获为止。

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

— 史蒂夫格
source