1つのLinuxサーバーから別のサーバーに大きなファイルをコピーする

LAデータセンターのLinuxサーバーからNYデータセンターの別のLinuxサーバーに10MBリンクを介して75ギガバイトのtgz（mysql lvmスナップショット）をコピーしようとしています。

200〜300時間の間で変動するrsyncまたはscpを使用すると、約20〜30Kb / sになります。

現時点では、2番目のデータセンターがまだアクティブになっていないため、比較的静かなリンクであり、小さなファイルの転送で優れた速度を実現しています。

グーグル経由で見つけたさまざまなtcpチューニングガイドは役に立たなかった（間違ったガイドを読んでいるかもしれませんが、良いガイドがありますか？）。

tar + netcatトンネルのヒントを見てきましたが、私の理解では、小さなファイルがたくさんある場合にのみ有効であり、ファイルの転送が効果的に終了しても更新されません。

ハードドライブを出荷する前に、何か良い情報がありますか？

更新： まあ...それは結局リンクかもしれません:(以下の私のテストを参照してください...

NYからLAへの移動：

空のファイルを取得します。

[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

LAからNYへの転送：

空のファイルを取得します。

[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 / Ethernet 10MBリンクとしてラベル付けされている施設を運営している人々と一緒に取り上げると思います。（すくめ）

スニーカーネット

これが1回限りのコピーであると仮定すると、ファイルをCD（または他のメディア）にコピーするだけで、一晩で目的地にコピーできるとは思いませんか？

実際には、その接続を介したそのサイズのファイル転送が正しくコピーされない可能性があるため、これが最速のオプションである可能性があります...この場合、最初からやり直すことができます。

rsync

2番目の選択肢/試行は、失敗した転送、部分的な転送などを検出し、中断したところから再開できるため、rsyncです。

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

--progressフラグを使用すると、単にそこに座って自分で推測するのではなく、フィードバックが得られます。:-)

Vuze（ビットトレント）

3番目の選択肢は、おそらくVuzeをトレントサーバーとして使用し、リモートロケーションで標準のBitorrentクライアントを使用してダウンロードすることです。私はこれを行った他の人を知っていますが、あなたは知っています...彼らがそれをすべて実行するように設定するまでに...など、私はデータを一晩にしたかもしれません...

私はあなたの状況に依存すると思います。

がんばろう！

更新：

あなたの問題についてもう少し考えました。ファイルが単一の巨大なtarballである必要があるのはなぜですか？Tarは大きなファイルを小さなファイルに完全に分割できます（たとえば、メディアにまたがるなど）。その巨大なtarballをより管理しやすい断片に分割し、代わりに断片を転送しませんか？

私は過去に60GBのtbz2ファイルを使ってそれをしました。スクリプトはもうありませんが、簡単に書き直すことができます。

最初に、ファイルを〜2GBの断片に分割します。

split --bytes=2000000000 your_file.tgz

各ピースについて、MD5ハッシュを計算し（整合性をチェックするため）、どこかに保存し、選択したツールを使用してピースとそのmd5をリモートサイトにコピーし始めます（me：画面のnetcat-tar-pipeセッション）。

しばらくして、あなたの作品が大丈夫かどうかをmd5で確認してください：

cat your_file* > your_remote_file.tgz

元のファイルのMD5も行っている場合は、それも確認してください。それが大丈夫なら、あなたはあなたのファイルを解凍することができます、すべては大丈夫です。

（時間を見つけたら、スクリプトを書き直します）

通常、私はrsyncの大擁護者ですが、初めて単一のファイルを転送するときには、あまり意味がありません。ただし、わずかな違いのみを使用してファイルを再転送する場合、rsyncが明確な勝者になります。とにかくrsyncを使用することを選択した場合--daemon、パフォーマンスを殺すsshトンネルを排除するために、一方のモードをモードで実行することを強くお勧めします。マニュアルページでは、このモードについて詳しく説明しています。

私の推薦ですか？中断されたダウンロードの再開をサポートするサーバーおよびクライアントを使用したFTPまたはHTTP。両方のプロトコルは高速で軽量であり、sshトンネルのペナルティを回避します。Apache + wgetは速く叫びます。

netcat pipeトリックも正常に機能します。1つの大きなファイルを転送する場合、tarは必要ありません。そして、それが完了しても通知しないのは、あなたがそれを伝えなかったからです。-q0サーバー側にフラグを追加すると、期待どおりに動作します。

server $ nc -l -p 5000> outfile.tgz

client $ nc -q0 server.example.com 5000 <infile.tgz

netcatアプローチの欠点は、転送が74GBで死んだ場合に再開できないことです...

netcat（ncと呼ばれることもあります）を試してみてください。以下はディレクトリで機能しますが、1つのファイルをコピーするだけで簡単に調整できるはずです。

宛先ボックスで：

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

ソースボックスで：

tar czf * | netcat target_box 2342

ファイルがすでに圧縮されているので、もう少し高速にするために、両方のtarコマンドで 'z'オプションを削除してみてください。

デフォルトのSCPおよびRsync（SCPを使用）は、大きなファイルに対して非常に遅くなります。オーバーヘッドの少ないプロトコルの使用を検討すると思います。より単純な暗号化暗号を使用しようとしましたか、それともまったく使用しませんでしたか？--rshrsync のオプションを調べて、転送方法を変更してみてください。

FTPまたはHTTPを使用しない理由

状況に多少のオーバーヘッドが追加されますが、実際にはBitTorrentは大きなファイルを転送するための本当に素晴らしいソリューションです。BitTorrentには、ファイルをネイティブにチャンクすることや、破損した場合に再送信できる各チャンクをチェックサムすることなど、多くの便利な機能があります。

Azureus [現在のVuze]のようなプログラムには、1つのアプリでトレントを作成、サーバー、およびダウンロードするために必要なすべての要素が含まれています。Beanを念頭に置いて、AzureusはBitTorrentで利用可能な最もスリムなソリューションではなく、そのGUIも必要だと思います。

個人的には、10Mb（10MBではなく10Mbと想定）リンクの場合、20-30Kb / sはかなり低いようです。

もし私があなただったら、私は2つのことのうちの1つをするでしょう（物理的なアクセスが利用できないと仮定して）-

どちらの場合も、大きなファイルを小さなチャンクに分割することをお勧めします。転送中に破損した場合に備えて、約500MBです。

小さいチャンクがある場合は、rsyncを再度使用するか、個人的にセキュアなftpセッションを使用し、完了時にファイルをCRCすることを個人的に好みます。

議論にはいくつかの質問が役立ちます。データを転送することがどれほど重要か。これは災害復旧、ホットバックアップ、オフラインストレージ、または何のためですか？データベースが稼働中または停止中にバックアップするつもりですか？リモートシステムでデータベースをセットアップし、クラスタリングまたは変更ログを介した更新を使用してデータベースを同期させることについてはどうですか（MySqlデータベースシステムの機能に完全に精通しているわけではありません）。これにより、リンクを介して転送する必要があるデータの量を減らすことができます。

bbcpはファイルをチャンクし、複数のストリームでコピーします。

グーグルの遅い答え：

大規模なデータセットを転送する場合、rsyncを使用してソースと宛先を比較し、--only-write-batchフラグを使用してバッチファイルをローカルのリムーバブルメディアに書き込むことができます。次に、ローカルメディアをリモートの場所に発送し、プラグインし、-read-batchを使用してrsyncを再度実行し、変更をリモートデータセットに組み込みます。

物理的なトランスポート中にソースファイルが変更された場合、またはトランスポートメディアがいっぱいになった場合は、単に--only-write-batch | 船| -宛先がすべて追いつくまでの読み取りバッチサイクル。

（参照：私はrsyncでこの機能の作成者の1人でした-詳細な背景と使用例については、プロトタイプ実装に関する次の説明を参照してください：https : //lists.samba.org/archive/rsync/2005-March/011964 .html）