Linuxサーバー間で大きなファイルをコピーする
75 GBのtgz（mysql lvmスナップショット）をLAデータセンターのLinuxサーバーからNYデータセンターの別のLinuxサーバーに10MBリンクでコピーしようとしています。
200〜300時間変動するrsyncまたはscpで約20〜30Kb/sを取得しています。
現時点では、2番目のデータセンターがまだアクティブになっておらず、小さなファイル転送から優れた速度を得ているため、比較的静かなリンクです。
Google経由で見つけたさまざまなtcpチューニングガイドを使用しましたが、役に立ちませんでした（たぶん、間違ったガイドを読んでいるので、良いガイドを入手しましたか？）。
私はtar + netcatトンネルのヒントを見てきましたが、私の理解では、小さなファイルがたくさんある場合にのみ有効であり、ファイルの転送が実質的に終了しても更新されません。
ハードドライブを出荷する前に、誰かが良い情報を持っていますか？
PDATE：まあ...結局のところリンクかもしれません:(以下の私のテストを参照してください...
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リンクとしてラベル付けされている施設を運営している人たちと一緒に取り上げると思います。 （肩をすくめる）
Sneakernet Anyone？
これが1回限りのコピーであると仮定すると、ファイルをCD（または他のメディア）にコピーするだけで、一晩でコピー先にコピーできるとは思いませんか？
その接続を介したそのサイズのファイル転送は正しくコピーされない可能性があるため、実際にはこれが最も速いオプションである可能性があります。その場合、最初からやり直すことになります。
rsync
失敗した転送や部分的な転送などを検出し、中断したところから再開できるため、2番目の選択肢はrsyncです。
rsync --progress file1 file2 user@remotemachine:/destination/directory
--progressフラグを使用すると、ただ座って2番目に推測するのではなく、いくつかのフィードバックが得られます。 :-)
Vuze（bittorrent）
3番目の選択肢は、おそらくVuzeをトレントサーバーとして使用してから、リモートロケーションで標準のbitorrentクライアントを使用してダウンロードすることです。私はこれを行った他の人を知っていますが、あなたが知っています...彼らがそれをすべて設定して実行するようになっているときには...
あなたの状況次第だと思います。
幸運を！
更新：
ご存知のように、私はあなたの問題についてもう少し考えました。ファイルが単一の巨大なtarballである必要があるのはなぜですか？ Tarは、大きなファイルを（たとえば、メディアにまたがるように）小さいファイルに完全に分割できるので、その巨大なtarballをより管理しやすい部分に分割してから、その部分を転送しませんか？
私は過去に60GBのtbz2ファイルを使ってそれを行いました。スクリプトはもうありませんが、簡単に書き直すことができます。
まず、ファイルを2GB以下に分割します。
split --bytes=2000000000 your_file.tgz
各部分について、MD5ハッシュを計算し（これは整合性をチェックするため）、それをどこかに保存してから、選択したツール（me：netcat-tar-pipe in a screen）を使用して、部分とそのmd5をリモートサイトにコピーします。セッション）。
しばらくして、あなたの作品が大丈夫かどうかmd5で確認してください：
cat your_file* > your_remote_file.tgz
元のファイルのMD5も実行した場合は、それも確認してください。問題がなければ、ファイルをuntarできます。すべて問題ありません。
（時間があれば、スクリプトを書き直します）
通常、私はrsyncの大提唱者ですが、単一のファイルを初めて転送するときは、あまり意味がありません。ただし、わずかな違いのみでファイルを再転送する場合は、rsyncが勝者となるでしょう。とにかくrsyncを使用する場合は、一端を--daemonモードで実行して、パフォーマンスが低下するsshトンネルを排除することを強くお勧めします。マニュアルページでは、このモードについて完全に説明しています。
私の推薦？中断されたダウンロードの再開をサポートするサーバーとクライアントでのFTPまたはHTTP。どちらのプロトコルも高速で軽量であり、sshトンネルのペナルティを回避します。 Apache + wgetは速く叫ぶでしょう。
Netcatパイプトリックも正常に機能します。 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を使用）は非常に遅くなります。オーバーヘッドの少ないプロトコルを使用することを検討するでしょう。より単純な暗号化暗号を使用してみましたか、それともまったく使用していませんか？転送方法を変更するには、rsyncの--rshオプションを調べてみてください。
なぜFTPやHTTPではないのですか？
それは状況に少しのオーバーヘッドを追加しますが、BitTorrentは実際には大きなファイルを転送するための本当に素晴らしいソリューションです。 BitTorrentには、ファイルをネイティブにチャンクしたり、破損した場合に再送信できる各チャンクをチェックサムしたりするなど、多くの素晴らしい機能があります。
Azureus [現在はVuzeと呼ばれる]のようなプログラムには、1つのアプリでトレントを作成、サーバー、およびダウンロードするために必要なすべてのものが含まれています。豆知識Azureusは、BitTorrentで利用できる最もリーンなソリューションではなく、GUIも必要だと思います。ただし、Linuxには、コマンドラインで駆動されるトレントツールがたくさんあります。
まあ、個人的には、10Mb（10MBではなく10Mbと仮定）リンクでは20-30Kb/sはかなり低いようです。
私があなただったら、2つのことのどちらかを行います（物理的なアクセスが利用できない場合）-
どちらの場合も、転送中に破損した場合に備えて、大きなファイルを約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 ）