15TBの小さなファイルを転送する

あるサーバーから別のサーバーにデータをアーカイブしています。最初はrsync仕事を始めました。5 TBのデータのファイルリストを作成するのに2週間、1 TBのデータを転送するのにさらに1週間かかりました。

その後、新しいサーバーでいくつかのダウンタイムが必要になるため、ジョブを強制終了する必要がありました。

おそらく再びアクセスする必要はないので、それをtarすることに同意しました。500 GBのチャンクに分割することを考えていました。私がtarそれをした後、私はそれをコピーしようとしましたssh。私は使用tarしてpigzいましたが、それでも遅すぎます。

それを行うより良い方法はありますか？両方のサーバーがRedhat上にあると思います。古いサーバーはExt4で、新しいサーバーはXFSです。

ファイルサイズは数KBから数MBの範囲で、5 TBには2400万のJPEGがあります。ですから、15TBで約6,000万から8,000万を推測しています。

編集：数日間rsync、nc、tar、mbuffer、pizzで遊んだ後。ボトルネックはディスクIOになります。データが500個のSASディスクと約2億5千万個のjpegにストライプ化されているため。しかし、今では、将来使用できるこれらすべての素晴らしいツールについて学びました。

私が使用して、非常に良好な結果を得ていtar、pigz（並列GZIP）とnc。

ソースマシン：

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

宛先マシン：

抽出するには：

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

アーカイブを保持するには：

nc source_machine_ip 9876 > smallstuff.tar.gz

転送速度を確認したい場合は、pv後でパイプスルーしてpigz -dください！

私はrsyncソリューションに固執します。モダン（3.0.0+）rsyncは増分ファイルリストを使用するため、転送前に完全なリストを作成する必要はありません。そのため、問題が発生した場合、再起動しても転送全体をやり直す必要はありません。最上位または第2レベルのディレクトリごとに転送を分割すると、これがさらに最適化されます。（ネットワークがドライブより遅い場合は、使用rsync -a -Pして追加し--compressます。）

、VPN（そのインターネットの場合）を設定し、（それext4を作る）、リモートサーバー上のいくつかの形式の仮想ドライブを作成し、リモートサーバーにマウント後、 iSCSIのようなブロックレベルのプロトコルを使用して（ローカルサーバー上のことをマウント）、ddまたは別のブロックレベルのツールを使用して転送を行います。その後、必要に応じて、仮想ドライブから実際の（XFS）ドライブにファイルをコピーできます。

2つの理由：

1. 主なパフォーマンスの原因であるファイルシステムのオーバーヘッドはありません
2. シークなし、両側のシーケンシャル読み取り/書き込みを見ている

古いサーバーが廃止され、ファイルが数分間オフラインになる場合、ドライブを古いボックスから引き出して新しいサーバーにケーブル接続し、マウント（今すぐオンラインに戻す）してファイルをコピーするのが最も速い場合がよくあります。新しいサーバーのネイティブディスクに。

mbufferを使用します。安全なネットワーク上にある場合は、暗号化手順を回避できます。

（多くの異なる答えが機能します。別の答えを次に示します。）

find -type f（これは数時間で終了するはずです）でファイルリストを生成し、それを小さなチャンクに分割し、を使用して各チャンクを転送しrsync --files-from=...ます。

スニーカーネットを検討しましたか？つまり、すべてを同じドライブに転送してから、そのドライブを物理的に移動するということです。

約1か月前、Samsungは16 TBドライブ（技術的には15.36 TB）を発表しました。これはSSDでもあります：http : //www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -ドライブ-16TB

私は、このドライブでこれがうまくいくと思います。それでもすべてのファイルをコピーする必要がありますが、ネットワークの待ち時間がなく、おそらくSATAまたは同様の高速なテクニックを使用できるため、かなり高速になるはずです。

重複排除時に高い成功率が得られる可能性がある場合は、borgbackupやAttic などを使用します。

そうでない場合は、netcat + tar + pbzip2ソリューションを確認し、ハードウェアに応じて圧縮オプションを調整します-ボトルネック（CPU？ネットワーク？IO？）を確認します。pbzip2はすべてのCPUに適切に適用され、パフォーマンスが向上します。

RedHat Linuxを使用しているため、これは適用されませんが、別のオプションとして：

iノードは問題にならないため、ZFSを使用して何百万ものファイルを保持することで大きな成功を収めました。

それがあなたにとっての選択肢だったなら、スナップショットを取り、zfsを使用して増分更新を送信できます。この方法を使用してデータを転送およびアーカイブすることで多くの成功を収めました。

ZFSは主にSolarisファイルシステムですが、illumos（SunのOpenSolarisのオープンソースフォーク）にあります。ZFSをBSDおよびLinuxで（FUSEを使用して）使用することにも多少の幸運があったことは知っていますが、それを試してみた経験はありません。

rsyncターゲットマシンでデーモンを起動します。これにより、転送プロセスが大幅に高速化されます。

次のように、tarとsshだけでこれを行うことができます。

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

または、個々のファイルを保持する場合：

tar zcf - <your files> | ssh <destination host> "tar zxf -"