2つのサーバー間で数百万のファイルをコピーする最良の方法
同じギガビットネットワーク上の別のマシンにコピーする単一のディレクトリに約500万の小さな（5〜30k）ファイルがあります。 rsyncを使用してみましたが、実行の数時間後にはクロールが遅くなります。rsyncが毎回ソースと宛先のファイルをチェックする必要があるためと思いますか？
私の2番目の考えはscpを使用することですが、より良い方法があるかどうかを確認するために外部の意見を得たいと思いました。ありがとう！
このようなものはうまくいくはずです：
tar c some/dir | gzip - | ssh Host2 tar xz
ギガビットネットワークを使用しているため、抽出のためにgzipと "z"フラグを省略することもできます。
5つのMILLIONファイルがすべて1つのディレクトリにあるという事実は、多くのツールを混乱させます。 rsyncがこれを適切に処理しなかったことに驚いていません。これは非常に「ユニークな」状況です。ファイルをある種のディレクトリ構造に構造化する方法を理解できたら、rsyncなどの標準の同期ツールの方がはるかに応答が速いと思います。
ただし、実際のアドバイスを提供するためだけに-おそらく1つの解決策は、ドライブを物理的に宛先マシンに一時的に移動して、（ネットワーク経由ではなく）実際のサーバーでファイルのコピーを実行することです。次に、ドライブを元に戻し、rsyncを使用して最新の状態に保ちます。
（信頼できる環境で）ギガビットスイッチを介して数百万のファイルをコピーするには、user55286ですでに提案されているように、netcat (or nc)とtarの組み合わせを使用することもできます。これにより、すべてのファイルが1つの大きなファイルとしてストリーミングされます（ 高速ファイルコピー-Linux！（39 GB） を参照）。
# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf - # destination box
tar -cz /source/dir | nc Target_Box 2342 # source box
ディレクトリには約100万個のファイルがありました（約4年分のファイル）。
また、robocopyを使用してファイルをYYYY/MMディレクトリに移動しました（1か月あたり約35〜45,000ファイル）。robocopyスクリプトを.batファイルに次のように配置します。
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02
簡単なメモ.. /ns /nc /nfl /npは、追加情報でログファイルが肥大化するのを避けるためです/log+...は、要約情報をログファイルに書き込むことです。
/minage and /maxage is to copy files modified with in that date range.
したがって、たとえば、変更されたファイル> = 01/Nov/2008（包括的）から変更されたファイル<01/Dec/2008（包括的ではない）
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
/movファイルを移動します
次にソースディレクトリが来る
次に、宛先ディレクトリーが表示されます（ディレクトリーは、必要に応じてその場で作成されます）。
1か月分の転送に約40〜60分かかりました（約35〜45,000ファイル）。1年分の転送にかかる時間は約12時間以下です。
Windows Server 2003を使用します。
すべてのものはログファイルに記録されます...開始時刻、終了時刻、およびコピーされたファイルの数。
Robocopyはその日を救った。
現時点で最速の圧縮ツールとしてlz4を使用することを好みます。 SSHオプション-carcfour128は、デフォルトよりも高速な暗号化アルゴリズムを使用します。 [1]
したがって、ディレクトリ転送は次のようになります。
tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'
Debianではlz4コマンドはlz4cであり、CentOSではlz4であることに注意してください。
ご存知のように、私はtarソリューションをプラス1しましたが、-環境によっては-もう1つのアイデアがあります。 dd（1）の使用について考えるかもしれません。このような速度の問題は、ファイルを開いたり閉じたりするために多くのヘッドモーションを必要とすることです。これは500万回実行されることになります。これらが確実に連続して割り当てられるようにするには、代わりにddを使用します。これにより、頭の動きの数が5倍以上に削減されます。
Robocopy はこのようなものに最適です。ネットワークのタイムアウト後に再試行し、パケット間ギャップ遅延を設定してパイプを圧倒することもできます。
[編集]
これはWindows専用のアプリケーションです。
これは馬鹿げているかもしれませんが、外部ディスクにコピーして他のサーバーに引き継ぐことを考えましたか？それは実際には最も効率的でシンプルなソリューションかもしれません。
この問題は現在調査中です。約1,800万個の小さなファイルを転送する必要があります-合計で約200GB。旧式のXCopyを使用して最高のパフォーマンスを達成しましたが、それでも長い時間がかかりました。あるサーバーから別のサーバーに約3日、外部ドライブに約2週間！
別のプロセスを通じて、サーバーを複製する必要がありました。これはアクロニスで行われました。約3時間かかりました!!!
これについてはもう少し調査します。上記のddの提案は、おそらく同様の結果を提供します。
すでにたくさんの良い提案がありますが、 Beyond Compare を投入したいと考えていました。私は最近、5KBから20MBまでの約750,000個のファイルを、ギガビットスイッチを介してサーバー間で転送しました。それは全くしゃっくりもしませんでした。確かに少し時間がかかりましたが、データが多すぎると思います。
ファイルシステムをバイパスします。
ファイルが存在するこのパーティションをマウント解除するか、読み取り専用でマウントできますか？それを行うと、次のようになります。
dd if=/dev/PARTITION | ssh username@Host "dd of=diskimage.bin"
その後、diskimage.bin宛先側のループバックデバイスとして、ファイルから実際の宛先ファイルシステムにファイルをコピーするか、適切なツールを使用して宛先側の空のパーティションにステッチして戻します（危険ですが、おそらく可能ですが、私はそれをやったことがない。）
本当に勇気があるなら、宛先側のパーティションに直接ddできます。それはお勧めしません。
Zip-> copy-> unzipのパフォーマンスを確認します
またはあなたの好きな圧縮/アーカイブシステムは何でも。
コピーする前にそれらを単一のファイルにパックし、コピー後に再度解凍します。
同様の状況で、tarを使用してファイルをまとめました。 tarコマンドの出力をターゲットマシンに直接パイプして、ファイルをアンバンドルする受信tarプロセスに送る小さなスクリプトを書きました。
Tarアプローチでは、scpまたはrsync（YMMV）に比べて転送速度がほぼ2倍になります。
次に、tarコマンドを示します。各マシンのホームディレクトリに.rhostsファイルを作成して、rコマンドを有効にする必要があることに注意してください（コピーが完了したらこれらを削除します-これらは悪名高いセキュリティ問題です）。また、HP-UXはいつものように扱いにくいことに注意してください。他の国では、リモートシェルコマンドに「rsh」を使用していますが、HP-UXでは「remsh」を使用しています。 「rsh」は、HP用語では制限付きのシェルの一種です。
box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "
最初のtarコマンドは「-」というファイルを作成します。これは、この場合「標準出力」を意味する特別なトークンです。作成されたアーカイブには、現在のディレクトリ（。）内のすべてのファイルとすべてのサブディレクトリが含まれます（tarはデフォルトで再帰的です）。このアーカイブファイルは、ボックス2マシンに送信するremshコマンドにパイプされます。ボックス2で、最初に適切な受信ディレクトリに移動し、次に受信ファイルを「-」または「標準入力」から抽出します。
ディスクアクセスが制限要因だったのではないかと思いますが、ネットワークリンクがデータで飽和するように、これらのtarコマンドのうち6つを同時に実行しました。
考慮すべきことが他にあります。これを試して：
- 動的サイズのVHDを作成する
- おそらくディレクトリとしてマウントしてください
- 「ディスク全体を圧縮する」属性を設定する
これを行うことにより、ファイルの書き込み時に行われるため、ディレクトリの反復や圧縮にオーバーヘッドが発生しません。移動するファイルはVHDのみです。
Windowsでは、デフォルトのTCPパケットサイズを16348のように大きく設定しています。これは、IPヘッダーのオーバーヘッドが少ないことを意味します。
しかし、私が遭遇したことの1つは、ネットワークまたはUSB転送の場合、ファイルサイズを100 MB未満に保つのが最善であることです。私はそのためにRar.exeを使用しています-ファイルを分割するためです。
チャンピオンのように機能します。これは、Linuxの「dd」に相当します。圧縮されたファイルシステムをディレクトリにマウントするという概念は、Linuxでも正常なので、同じロジックが適用されます。他の方法と同様に、操作を開始する前にすべてのファイルを確実に閉じる必要があります。
これには、フォルダーにサイズクォータを配置できるという追加の利点があります。 VHDが固定サイズの場合、その制限を超えてもサーバーはダウンせず、ファイルの作成または書き込みでエラーが発生するだけです。
NTFSとしてフォーマットされたVHDは、フォルダー内の数百万のファイルも処理できます。
あなたは次のことを試すことができます（ファイルのバッチであるかもしれません）
- ファイルのバッチをtar
- それらをgzip
- 可能であればscpを使用してコピー
- ガンジップ
- ファイルを解凍します
Sthで提案されているように、sshではなくtarを試すことができます。
暗号化が必要ない場合（最初はrsyncを使用しましたが、rsync + sshであるとは言及していませんでした）、sshのオーバーヘッドを回避するためにnetcatでtarを試すことができます。
もちろん、gzipまたは他の圧縮方法を使用して、所要時間を短縮することもできます。