15TBの小さなファイルを転送
サーバー間でデータをアーカイブしています。最初にrsyncジョブを開始しました。 5 TBのデータの場合のみファイルリストを作成するのに2週間かかり、1 TBのデータの場合転送にもう1週間かかりました。
その後、新しいサーバーでダウンタイムが必要なため、ジョブを強制終了する必要がありました。
再度アクセスする必要はおそらくないので、タール化することで合意しました。 500 GBのチャンクに分割することを考えていました。 tarした後、sshを介してコピーします。 tarとpigzを使用していましたが、まだ遅いです。
それを行うより良い方法はありますか？どちらのサーバーもRedhat上にあると思います。古いサーバーはExt4で、新しいサーバーはXFSです。
ファイルサイズの範囲は数KBから数mbで、5 TBに2400万jpegがあります。したがって、15 TBで約6,000〜8,000万と推測しています。
編集：rsync、nc、tar、mbuffer、およびpigzを数日間遊んだ後。ボトルネックはディスクIOです。データは500 SASディスクと約2億5,000万の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
転送速度を確認したい場合は、pigz -dの後にpvをパイプするだけです。
私はrsyncソリューションに固執します。最新（3.0.0+）rsyncは増分ファイルリストを使用するため、転送前に完全なリストを作成する必要はありません。したがって、再起動しても、問題が発生した場合に転送全体を再度行う必要はありません。転送をトップレベルまたはセカンドレベルのディレクトリごとに分割すると、さらに最適化されます。 （私はrsync -a -Pと追加--compressネットワークがドライブより遅い場合。）
VPNをセットアップし（インターネットの場合）、リモートサーバー上に何らかの形式の仮想ドライブを作成し（ext4にします）、リモートサーバーにマウントしますthenローカルサーバーにマウントします（使用iSCSIなどのブロックレベルのプロトコル）、ddまたは別のブロックレベルのツールを使用して転送を行います。その後、自分の都合に合わせて、仮想ドライブから実際の（XFS）ドライブにファイルをコピーできます。
2つの理由：
- パフォーマンスの主な原因であるファイルシステムのオーバーヘッドがない
- シークなし、両側で順次読み取り/書き込みを確認している
古いサーバーが使用停止になり、ファイルが数分間オフラインになる可能性がある場合は、ドライブを古いボックスから引き出して新しいサーバーにケーブル接続し、マウントして（今すぐオンラインに戻し）、ファイルをコピーするのが最も高速です。新しいサーバーのネイティブディスクに。
スニーカーネットを検討したことがありますか？つまり、すべてを同じドライブに転送し、そのドライブを物理的に移動します。
約1か月前に、Samsungは16 TB=ドライブ（技術的には15.36 TB）を発表しました。これはSSDでもあります： http://www.theverge.com/2015/ 8/14/9153083/samsung-worlds-largest-hard-drive-16tb
私はこのドライブがこれのためにちょうどするだろうと思います。それでもすべてのファイルをコピーする必要がありますが、ネットワーク遅延がなく、SATAまたは同様の高速技術を使用できるため、かなり高速になるはずです。
Mbufferを使用してください。安全なネットワーク上にある場合は、暗号化手順を回避できます。
（多くの異なる答えが機能します。ここに別の答えがあります。）
find -type fを使用してファイルリストを生成し（これは数時間で完了するはずです）、それを小さなチャンクに分割し、rsync --files-from=...を使用して各チャンクを転送します。
RedHat Linuxを使用しているため、これは当てはまりませんが、別のオプションとして：
Iノードは問題ではないので、ZFSを使用して何百万ものファイルを保持するのに大成功しました。
それが選択肢である場合は、スナップショットを作成し、zfsを使用して増分更新を送信できます。この方法を使用して、データの転送とアーカイブに多くの成功を収めてきました。
ZFSは主にSolarisファイルシステムですが、illumos（SunのOpenSolarisのオープンソースフォーク）にあります。 BSDとLinuxでZFSを使用して（FUSEを使用して？）.
重複排除時に高い成功率が得られる可能性がある場合は、 borgbackup またはAtticなどを使用します。
そうでない場合は、netcat + tar +pbzip2ソリューションを確認し、ハードウェアに応じて圧縮オプションを調整します-ボトルネック（CPU？ネットワーク？IO？） ）。 pbzip2は、すべてのCPUにまたがってうまく機能し、パフォーマンスが向上します。
ターゲットマシンでrsyncデーモンを起動します。これにより、転送プロセスが大幅にスピードアップします。