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

我试图从我们的洛杉矶数据中心的一台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。