2台のコンピューター間で大量のデータを送信する最速の方法は何ですか？[閉まっている]

これは私が頻繁にいる状況です：

• 内部に320GBのハードドライブと16GBのRAMを備えたソースサーバーがあります（正確な仕様はここで入手できますが、これは他のマシンでも頻繁に遭遇する問題であるため、 「合理的な」Linuxマシン）
• 数テラバイトのハードドライブ領域を備えたバックアップサーバーがあります（正確な仕様はこちら、上記の免責事項を参照）

ソースサーバーからターゲットサーバーに320 GBのデータ（具体的にはからのデータ/dev/sda）を転送したい。

1. 2台のコンピューターは物理的に隣り合っているので、ケーブルを接続できます。
2. 私はLAN上にいて、新しいルーターを使用しています。これは、ネットワーク速度が「理想的には」1000Mビットであるべきだということです。
3. セキュリティは問題ではありません。私はローカルネットワーク上にあり、ルーターを含むネットワーク上のすべてのマシンを信頼しています。
4. （オプション）データの署名付きチェックサムは必ずしも必要ではありませんが、基本的なエラーチェック（ドロップされたパケットやドライブが読み取れなくなるなど）は、出力に消えるのではなく、検出する必要があります。

この質問をオンラインで検索し、いくつかのコマンドをテストしました。最も頻繁に表示されるのはこれです：

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

このコマンドは遅すぎることが判明しました（1時間実行し、データで約80GBしか得られませんでした）。1GBのテストパケットには約1分22秒かかり、圧縮されていない場合は2倍の速度になりました。また、転送されたファイルがソースシステムのRAM容量よりも少ないという事実によって、結果が歪められた可能性があります。

さらに（これは1GBのテストピースでテストされました）、gzipコマンドとdd; を使用すると問題が発生します。結果ファイルは、直接パイプされた場合とは異なり、ターゲットで抽出されたときとは異なるチェックサムを持ちます。私はまだこれが起こっている理由を解明しようとしています。

サーバーは物理的に隣り合っており、コメントで言及しているように、サーバーに物理的にアクセスできるため、最速の方法は、最初のコンピューターからハードドライブを取り出し、2番目に設置して、ファイルを転送することですSATA接続を介して。

netcat セキュリティが問題にならないこのような状況に最適です：

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

ddGNU coreutilsから使用している場合はSIGUSR1、プロセスに送信すると、stderrに進行状況が出力されることに注意してください。BSDのdd場合は、を使用しますSIGINFO。

pvは、コピー中の進行状況をレポートするのにさらに役立ちます。

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

1. 高速圧縮を使用してください。

   • 転送メディア（特にネットワークまたはusb）が何であれ、読み取り、キャッシュ、書き込みのデータバーストを処理しますが、これらは正確には同期されません。
   • ディスクファームウェア、ディスクキャッシュ、およびカーネル/ラムキャッシュに加えて、あなたはまたごとに交換されるデータの量に集中するために、何らかの形でのシステムのCPUを採用することができるならば、バーストを、あなたがそうする必要があります。
   • 圧縮アルゴリズムは、入力のスパース実行を可能な限り高速で自動的に処理しますが、ネットワークスループットで残りを処理するものはほとんどありません。
   • lz4 ここであなたの最良のオプションです：

     LZ4は非常に高速なロスレス圧縮アルゴリズムであり、コアあたり400 MB / sの圧縮速度を提供し、マルチコアCPUで拡張可能です。また、コアあたり数GB /秒の速度を備えた非常に高速なデコーダーを備えており、通常はマルチコアシステムでRAMの速度制限に達します。

2. 不必要にシークしないでください。

   • これを測定することは困難です。

   • コピー元のデバイスに多くの空き領域があり、デバイスが最近ゼロ化されていないが、すべてのソースファイルシステムをコピーする必要がある場合は、まず最初に行う価値があります。何かのようなもの：

     </dev/zero tee >empty empty1 empty2; sync; rm empty*

   • しかし、それはソースを読むべきレベルに依存します。通常/dev/some_disk、ファイルシステムレベルでの読み取りには、ディスクを前後にシーケンシャルにシークする必要があるため、デバイスを最初から最後までデバイスファイルから読み取ることが望ましいです。したがって、読み取りコマンドは次のようになります。

     </dev/source_device lz4 | ...

   • ただし、ソースファイルシステム全体を転送する必要がない場合は、ファイルシステムレベルでの読み取りはかなり避けられないため、入力コンテンツをストリームにまとめる必要があります。paxその場合、一般的には最良かつ最も単純なソリューションですがmksquashfs、同様に考慮することもできます。

     pax -r /source/tree[12] | lz4 | ...
     mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
     

3. で暗号化しないでくださいssh。

   • 信頼できるメディアに暗号化オーバーヘッドを追加する必要はありません。また、データの読み取りには2回の読み取りが必要なため、持続的な転送速度に重大な悪影響を与える可能性があります。
   • PRNGは、読み出しデータを必要とする、またはその少なくとも一部は、ランダム性を維持します。
   • そしてもちろん、データも転送する必要があります。
   • また、暗号化オーバーヘッド自体を転送する必要があります。つまり、バーストごとに転送されるデータ量が少なく、より多くの作業が必要になります。

   • むしろ、他の場所で提案されているように、単純なネットワークコピーにnetcat（または、私が好むようにnmapプロジェクトの能力が高いほどncat）使用する必要があります。

     ###  on tgt machine...
     nc -l 9999 > out.lz4
     ###  then on src machine...
     ... lz4 | nc tgt.local 9999
     

転送速度を制限している可能性のあるいくつかの制限があります。

1. 1Gbpsパイプには固有のネットワークオーバーヘッドがあります。通常、これにより実際のスループットは900 Mbps以下に低下します。次に、これは双方向トラフィックであり、900Mbps未満の大幅なダウンが予想されることを覚えておく必要があります。

2. 「新しいルーター」を使用している場合でも、ルーターが1Gbpsをサポートしていると確信していますか？すべての新しいルーターが1Gbpsをサポートしているわけではありません。また、エンタープライズグレードのルーターでない限り、ルーターへの追加の送信帯域幅が非効率になる可能性があります。以下で見つけたものに基づいていますが、100Mbpsを超えているようです。

3. ネットワークを共有している他のデバイスからネットワークが混雑している可能性があります。あなたができると言ったように、直接接続されたケーブルを使ってみましたか？

4. 使用しているディスクIOの量は？おそらく、ネットワークによってではなく、ディスクドライブによって制限されています。ほとんどの7200rpm HDDは、約40MB / sしか取得しません。まったく空襲を使用していますか？SSDを使用していますか？リモートエンドで何を使用していますか？

バックアップのためにこれを再実行することが予想される場合は、rsyncを使用することをお勧めします。ssh / http / https / ftp接続を並列化するため、反対側のfilezillaなどのダウンローダーを使用してscp、ftp（s）、またはhttpを使用することもできます。これにより、他のソリューションが単一のパイプ上にあるため、帯域幅を増やすことができます。シングルパイプ/スレッドは、シングルスレッドであるという事実により制限されます。つまり、CPUにバインドされることさえあります。

rsyncを使用すると、ソリューションの複雑さを大幅に排除するだけでなく、圧縮、許可の保存、部分的な転送を許可できます。他にもいくつかの理由がありますが、一般的に大企業の推奨バックアップ方法（またはバックアップシステムの実行）です。Commvaultは、バックアップの配信メカニズムとして、実際にソフトウェアの下でrsyncを使用します。

80GB / hの指定例に基づいて、約177Mbps（22.2MB / s）を取得しています。2つのボックス間の専用イーサネット回線でrsyncを使用すると、これを簡単に倍増できると思います。これは、rsync over gigabitを使用した独自のテストでこれを達成できたためです。

これは定期的に対処しています。

私たちが使用する傾向がある2つの主な方法は次のとおりです。

1. SATA / eSATA /スニーカーネット
2. ダイレクトNFSマウント、ローカルcpまたはrsync

1つ目は、ドライブを物理的に再配置できるかどうかによって異なります。これは常にそうではありません。

2番目は驚くほどうまく機能します。一般的に、直接NFSマウントではかなり簡単に1gbps接続を最大化します。scp、dd over ssh、または同様のものを使用しても、これに近い場所には到達しません（100mpbsに疑わしいほどの最大レートが得られることがよくあります）。非常に高速なマルチコアプロセッサでも、2台のマシンのうち最も遅いマシンの1つのコアの最大暗号化スループットのボトルネックにぶつかります。これは、暗号化されていないネットワークマウントのフルボアcpまたはrsyncと比べて圧倒的に遅いです。時折、IOPSの壁にぶつかり、より一般的な〜110MB / sではなく〜53MB / s程度でスタックすることがありますが、ソースまたは宛先が実際にない限り、通常は短命です単一のドライブの場合、ドライブ自体の持続速度によって制限されることになります（実際に試してみるまでわからないランダムな理由で十分に変化します）。

NFSは、なじみのないディストリビューションにある場合、セットアップするのが少し面倒ですが、一般的に言えば、可能な限りパイプをいっぱいにする最も速い方法です。前回10gbps以上でこれを行ったとき、接続を最大にしたかどうかは実際にはわかりませんでした。コーヒーをつかんでから戻ってくる前に転送が終わったためです。送信元と送信先の間にいくつかのネットワークデバイスがある場合、ネットワークのスリンキー効果による若干の遅延または一時中断が発生する可能性がありますが、通常、これはオフィス全体（他のトラフィックがそれを混乱させることなく）またはデータセンターの一端からもう1つ（何らかの種類のフィルタリング/検査が内部で発生している場合を除き、この場合、すべてのベットはオフになります）。

編集

圧縮に関するおしゃべりに気付きました... 接続を圧縮しないでください。暗号化レイヤーと同じように速度が低下します。接続を圧縮すると、ボトルネックは常に単一のコアになります（そのコアのバスを特に有効に利用することさえできません）。状況でできる最も遅いことは、1gbps以上の接続で隣り合って座っている2台のコンピューター間で暗号化された圧縮チャネルを使用することです。

将来の証明

このアドバイスは2015年半ばの時点で有効です。これは、ほぼ間違いなく、もう何年もの間そうではありません。したがって、すべてを一粒の塩で取り、このタスクに定期的に直面する場合は、理論上の最適値に近いものを得るのではなく、実際の負荷でさまざまな方法を試してくださいトラフィックの多くはテキストです（ヒント：バルク転送は通常、主に画像、音声、ビデオ、データベースファイル、バイナリコード、オフィスファイル形式などで構成されており、既に圧縮されています独自の方法で、さらに別の圧縮ルーチンを実行してもほとんどメリットはありません。その圧縮ブロックサイズは、すでに圧縮されたバイナリデータと整合しないことがほぼ保証されています...）。

将来、SCTPのような概念はより興味深い場所に運ばれ、そこでは結合接続（または内部結合によるスペクトルチャネライズドファイバ接続）が一般的であり、各チャネルは他のチャネルから独立したストリームを受信でき、ストリームは並行して圧縮/暗号化などができます。それは素晴らしいことです！しかし、2015年の今日はそうではありません。空想と理論化は素晴らしいことですが、ほとんどの場合、Wootsonの回答を生成するBlue Gene / Qの内部に直接データを供給する低温チャンバー内で実行されるカスタムストレージクラスターはありません。それは現実ではありません。また、データペイロードを徹底的に分析して、圧縮が良いアイデアかどうかを判断する時間もありません。分析を完了する前に転送自体は終了するでしょう。

しかし...

時代は変わり、圧縮と暗号化に対する私の推奨は成り立たなくなります。私はこのアドバイスが典型的なケースですぐに覆されることを本当に望んでいます。それは私の人生を楽にするでしょう。

私は過去に使用した気の利いたツールですbbcp。ここに見られるように：https://www.slac.stanford.edu/~abh/bbcp/。

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htmも参照してください

このツールを使用すると、転送速度が非常に速くなりました。

何らかの方法で（ワイヤ/スニーカーネット/その他を介して）最初のパスを取得した場合、rsync後続の転送を大幅に高速化できる特定のオプションを検討できます。非常に良い方法は次のとおりです。

rsync -varzP sourceFiles destination

オプションは、冗長、アーカイブモード、再帰、圧縮、部分的な進行です。

zackseの答えへのコメントに元のポスターの主張を追加しましたが、それが典型的な状況で最速かどうかはわかりません。

bash特別なリダイレクト構文があります：
出力用：      > /dev/tcp/ IP  / ポート
入力用：       < /dev/tcp/ IP  / ポート
IPはドット付き10進IPまたはホスト名のいずれかを禁止します。 port banは、10進数またはからのポート名のいずれか/etc/servicesです。

実際の/dev/tcp/ディレクトリはありません。これはbash、TCPソケットを作成し、指定された宛先に接続し、通常のファイルリダイレクトと同じことを行う（つまり、それぞれの標準ストリームをdup2（2）を使用してソケットに置き換える）ように命令する特別な構文上のクラッジです。

したがって、ソースマシンからddまたはtarTCP経由で直接ソースマシンにデータをストリーミングできます。または、逆に、tarTCPを介してデータを直接または同様にストリーミングします。いずれの場合でも、1つの余分なnetcatが排除されます。

netcatに関する注意

ある古典のnetcatとGNUのnetcatとの構文で矛盾が。慣れ親しんだ古典的な構文を使用します。置き換え-lpで-lはGNU netcatをのために。

また、GNU netcatが-qスイッチを受け入れるかどうかもわかりません。

ディスクイメージの転送

（zackseの答えに沿って。）
目的地で：

nc -lp 9999 >disk_image

ソースで：

dd if=/dev/sda >/dev/tcp/destination/9999
 

tar.gzアーカイブを作成します。 tar

目的地で：

nc -lp 9999 >backup.tgz

ソースで：

tar cz files or directories to be transferred >/dev/tcp/destination/9999

交換する.tgzと.tbzしてczしてcjもらうためにbzip2-compressedアーカイブを。

ファイルシステムへの即時拡張を伴う転送

またtar。
目的地で：

cd backups
tar x </dev/tcp/destination/9999

ソースで：

tar c files or directories to be transferred |nc -q 1 -lp 9999

なし-q 1でも機能しますが、データが終了するとnetcatはスタックします。の構文と注意事項については、tar（1）を参照してくださいtar。高い冗長性（低エントロピー）を持つ多くのファイルがある場合には、圧縮（例えば、czとxzの代わりに、cとx）試みることができますが、ファイルが典型的であり、ネットワークが十分に高速であれば、それだけで、プロセスを遅らせるだろう。圧縮の詳細については、mikeservの回答を参照してください。

代替スタイル（宛先はポートをリッスンします）

目的地で：

cd backups
nc -lp 9999 |tar x

ソースで：

tar c files or directories to be transferred >/dev/tcp/destination/9999

直接接続に関する提案を試して、sshなどの暗号化されたプロトコルを避けてください。さらに、パフォーマンスのすべてを少しでも引き出したい場合は、https：//fasterdata.es.net/host-tuning/linux/にアクセスして、TCPウィンドウの最適化に関するアドバイスを読んでください。

パッケージを必要とするこのスクリプトを使用しsocatます。

ソースマシンで：

tarnet -d wherefilesaretosend pass=none 12345 .

ターゲットマシン：

tarnet -d wherefilesaretogo pass=none sourceip/12345

場合vbufパッケージ（Debianの、Ubuntuの）があるし、ファイル送信側はデータの進行状況が表示されます。ファイル受信者は、受信したファイルを表示します。pass =オプションは、データが公開される可能性がある（遅い）場合に使用できます。

編集：

-nCPUがボトルネックである場合、圧縮を無効にするオプションを使用します。

予算が主な関心事ではない場合は、Intel Xeon E5 12コア「ドライブコネクタ」でドライブを接続してみてください。このコネクタは通常非常に強力であるため、現在のサーバーソフトウェアを実行することもできます。両方のサーバーから！

これは楽しい答えのように見えるかもしれませんが、サーバー間でデータを移動している理由と、共有メモリとストレージを備えた大きなデータがより意味があるかどうかを本当に考慮する必要があります。

現在の仕様についてはわかりませんが、低速転送はネットワークではなくディスク速度によって制限される可能性がありますか？

ハードドライブのバイトコピーごとではなく、バックアップのみが必要な場合は、backupPCをお勧めします。http://backuppc.sourceforge.net/faq/BackupPC.htmlセットアップするのは少し苦痛ですが、すぐに転送されます。

約500Gのデータの最初の転送時間は約3時間でした。後続のバックアップは約20秒で行われます。

バックアップに興味はないが、同期しようとしている場合は、rsyncまたはunisonがニーズに合っています。

ハードディスクのバイトコピーのバイトは、通常、バックアップ目的のための恐ろしいアイデアです（増分、スペース節約、ドライブは使用できません。「空のスペース」をバックアップする必要があり、ゴミをバックアップする必要があります） （16 Gスワップファイルまたは200 Gのコアダンプなど）。rsync（またはbackuppcまたはその他）を使用して、「スナップショット」を時間内に作成できるため、「30分前のファイルシステムの外観」に移動できます。オーバーヘッドはほとんどありません。

つまり、バイトコピーのためにバイトを本当に転送したい場合、問題は、ドライブからのデータの取得ではなく、転送にあります。400GのRAMを使用すると、320Gのファイル転送には非常に長い時間がかかります。暗号化されていないプロトコルを使用することはオプションですが、何があっても、そこに座って数時間（ネットワーク経由で）待つ必要があります。

プログラムに関係なく、私は通常、ネットワークを介した「プル」ファイルが「プッシュ」よりも高速であることを発見しました。つまり、移行先コンピューターにログインして読み取りを行う方が、移行元コンピューターにログインして書き込みを行うよりも高速です。

また、中間ドライブを使用する場合は、これを考慮してください。USBではなくeSATAを使用する外部ドライブ（パッケージとして、またはドッキングステーションにプラグインされた別のドライブ）を入手します。次に、2台のコンピューターのそれぞれに、eSATAポートを備えたカードを取り付けるか、内部SATAポートの1つを外部eSATAコネクターに接続する簡単なアダプターケーブルを入手します。次に、ドライブをソースコンピューターに接続し、ドライブの電源を入れて、自動マウントされるまで待ちます（手動でマウントできますが、これを繰り返し行う場合は、fstabファイルに入れることもできます）。次にコピーします。内蔵ドライブと同じ速度で書き込みます。次に、ドライブをアンマウントし、電源を切り、他のコンピューターに接続し、電源を入れ、自動マウントを待ってから読み取ります。

NICチーミングを確認することをお勧めします。これには、並行して実行されている複数のネットワーク接続の使用が含まれます。本当に1Gbを超える転送が必要であり、10Gbのコストが非常に高いと仮定すると、NICチーミングによって提供される2Gbはわずかなコストになり、コンピューターには既に余分なポートがあります。

FWIW、私はいつもこれを使用しています：

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

この方法に関することは、マシン間でファイル/フォルダーのアクセス許可を維持することです（同じユーザー/グループが両方に存在すると仮定します）（また、スパースファイルを処理するために-Sパラメーターを使用できるため、通常はこれを仮想ディスクイメージをコピーするために行います。 ）

2つのビジーなサーバー間でこれをテストし、216秒で約14GB（約64MB /秒）を管理しました-専用マシンおよび/または圧縮間でより良い結果が得られる可能性があります... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

ファイルシステムのフォレンジックを行いたい場合を除き、ファイルシステム用のダンプ/復元プログラムを使用して、FSが使用していない空き領域をコピーしないようにします。使用しているファイルシステムに応じて、通常、これはを含むすべてのメタデータを保持しますctime。ただし、iノード番号は、どのファイルシステム（xfs、ext4、ufs ...）によっても変わる可能性があります。

復元ターゲットは、ターゲットシステム上のファイルにすることができます。

パーティションテーブル付きのフルディスクイメージが必要な場合ddは、ディスクの最初の1Mでパーティションテーブル/ブートローダー/ものを取得し、その後パーティションを取得できますxfsdump。

info-dumpから、実際にどのようなファイルシステムを持っているのかわかりません。BSD ufsの場合、ダンプ/復元プログラムがあると思います。ZFS、IDKの場合は、何かあるかもしれません。

一般に、ディスクのフルコピーは、回復状況以外の場合には遅すぎます。そのように増分バックアップを行うこともできません。

システムをセットアップして共有ストレージを使用することもできます！

私はこれらが互いに隣り合っていることを考えています、そして、あなたはこれを何度も何度もするでしょう....

イーサネットクロスオーバーケーブルはどうですか？ワイヤレス速度に依存する代わりに、NICの有線速度に制限されます。

この種のソリューションのいくつかの例と同様の質問があります。

どうやら今日では典型的なイーサネットケーブルで十分です。NICが優れているほど、転送は高速になります。

要約すると、ネットワークのセットアップが必要な場合、サブネットマスク255.255.255.0を使用してサーバーとバックアップコンピューターの静的IPを設定するだけに制限する必要があります。

幸運を！

編集：

@Khrystophは彼の答えでこれに触れました

暗号化によって速度が低下するため、sshをスキップすることをお勧めします。最近のCPUは実際には1Gbで十分に高速かもしれませんが、OpenSSHには内部ウィンドウ処理の実装に問題があり、大幅に速度が低下する可能性があります。

sshでこれを行うには、HPN SSHをご覧ください。ウィンドウの問題を解決し、マルチスレッド暗号化を追加します。残念ながら、クライアントとサーバーの両方でsshを再構築する必要があります。

OK「非常に大きなパイプ」（10Gbe）があり、互いに「近い」2台のコンピューターでこの質問に答えようとしました。

ここで遭遇する問題は、パイプが非常に大きいため、ほとんどの圧縮がCPUでボトルネックになることです。

10GBファイルを転送するパフォーマンス（6 Gbネットワーク接続[linode]、非圧縮データ）：

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

10 Gbeの2つのボックス、少し古いバージョンのnetcat（CentOs 6.7）、10 GBファイル：

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

そのため、あるインスタンスではnetcatのCPU使用量が少なく、他のsocatではYMMVが使用されていました。

netcatでは、「-N -q 0」オプションがない場合、切り捨てられたファイルを転送できます。注意してください...「-w 10」などの他のオプションも切り捨てられたファイルになる可能性があります。

これらのケースのほとんどすべてで起こっているのは、ネットワークではなくCPUが最大限に使用されていることです。 scp最大約230 MB / sで、100％の使用率で1つのコアをペギングします。

残念ながら、Iperf3は破損したファイルを作成します。netcatの一部のバージョンは、ファイル全体を転送しないようです。非常に奇妙です。特に古いバージョン。

「netcatへのパイプとしてのgzip」または「mbuffer」のさまざまな呪文も、gzipまたはmbufferを使用してCPUを最大限に使用するように思われたため、このような大きなパイプでは高速転送ができませんでした。lz4が役立つかもしれません。さらに、私が試みたgzipパイプの一部は、非常に大きな（4 GBを超える）ファイルの転送が破損するため、注意してください:)

特に待ち時間が長い場合（？）に機能する可能性がある別のことは、tcp設定を調整することです。推奨値を記載したガイドは次のとおりです。

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htmおよびhttps://fasterdata.es.net/host-tuning/linux/（別の回答から）おそらくIRQ設定：https : //fasterdata.es .net / host-tuning / 100g-tuning /

linodeからの提案、/ etc / sysctl.confに追加：

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

さらに、彼らはあなたに実行してほしい：

 /sbin/ifconfig eth0 txqueuelen 10000 

微調整後、変更によっても害が生じないことを確認するために再確認する価値があります。

また、ウィンドウサイズを調整する価値があるかもしれません：https : //iperf.fr/iperf-doc.php#tuningtcp

遅い接続では、圧縮が確実に役立ちます。大きなパイプがある場合、非常に高速な圧縮が容易に圧縮可能なデータに役立つ可能性があります。試してはいません。

「ハードドライブの同期」の標準的な答えは、ファイルをrsyncすることです。これにより、可能な限り転送が回避されます。

別のオプション： "パラレルscp"（なんとかして）を使用すると、より多くのコアが使用されます...