2つのサーバー間で数百万のファイルをコピーする最良の方法

1つのディレクトリに約500万個（5〜30k）の小さなファイルがあり、それらを同じギガビットネットワーク上の別のマシンにコピーしたいと思います。rsyncを使用してみましたが、数時間実行するとクロールが遅くなります。rsyncが毎回ソースファイルと宛先ファイルをチェックする必要があるためだと思いますか？

私の2番目の考えはscpを使用することですが、より良い方法があるかどうかを確認するために外部の意見を得たいと思いました。ありがとう！

このような何かがうまくいくはずです：

tar c some/dir | gzip - |  ssh host2 tar xz

また、ギガビットネットワークを使用しているため、gzipと抽出用の「z」フラグも省略している可能性があります。

単一のディレクトリにすべての500万ファイルがあるという事実は、多くのツールをむちゃくちゃにすることでしょう。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 /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. 

たとえば、2008年11月1日以降に変更されたファイル（2008年12月1日を含む）から2008年12月1日以降に変更されたファイル（これを含まない）

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はその日を救いました。

ご存知のように、私はtarソリューションをプラス1'dしましたが、環境に応じて、発生する別のアイデアが1つあります。dd（1）の使用について考えるかもしれません。このようなものの速度の問題は、ファイルを開いたり閉じたりするのに多くの頭の動きが必要なことです。これは500万回実行されます。これらを確実に割り当てるには、代わりにddを使用します。これにより、頭の動きの数が5倍以上削減されます。

現時点で最速の圧縮ツールとしてlz4を使用することを好みます。SSHオプション-c arcfour128は、デフォルトよりも高速な暗号化アルゴリズムを使用します。[1]

したがって、ディレクトリ転送は次のようになります。

tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'

Debian lz4コマンドではlz4cであり、CentOSではlz4であることに注意してください。

Robocopyはこのようなものに最適です。ネットワークがタイムアウトした後、再試行します。また、パケット間ギャップ遅延を設定して、パイプを圧倒します。

[編集]

これはWindows専用のアプリケーションであることに注意してください。

これは愚かかもしれませんが、外部ディスクにコピーして他のサーバーに引き継ぐことを考えたことがありますか？実際には、最も効率的でシンプルなソリューションかもしれません。

現在、この問題を調査中です。約1800万個の小さなファイル（合計約200GB）を転送する必要があります。従来のXCopyを使用して最高のパフォーマンスを達成しましたが、それでも時間がかかりました。1台のサーバーから別のサーバーまで約3日間、外付けドライブまで約2週間！

別のプロセスを通じて、サーバーを複製する必要がありました。これはAcronisで行われました。約3時間かかりました!!!

これについてはさらに調査します。上記のddの提案は、おそらく同様の結果を提供します。

すでにたくさんの良い提案がありますが、Beyond Compareを投入したかったのです。最近、ギガビットスイッチを介して、あるサーバーから別のサーバーに5KBから20MBの間で約750,000個のファイルを転送しました。しゃっくりさえしませんでした。確かにそれはしばらくかかりましたが、非常に多くのデータがあることを期待しています。

zip-> copy-> unzipの実行方法がわかります

またはあなたの好きな圧縮/アーカイブシステムが何であれ。

コピーする前にそれらを1つのファイルにパックし、コピー後に再度アンパックします。

同様の状況で、tarを使用してファイルをバッチ処理しました。tarコマンドの出力をターゲットマシンに直接渡して、ファイルをアンバンドルする受信tarプロセスに直接パイプする小さなスクリプトを作成しました。

tarアプローチは、scpまたはrsync（YMMV）と比較して転送速度をほぼ2倍にしました。

tarコマンドは次のとおりです。各マシンのホームディレクトリに.rhostsファイルを作成して、rコマンドを有効にする必要があることに注意してください（コピーが完了した後、これらを削除します-悪名高いセキュリティ問題です）。また、いつものように、HP-UXは扱いにくいことに注意してください。他の地域ではremote-shellコマンドに「rsh」を使用しますが、HP-UXは「remsh」を使用します。「rsh」は、HPの用語では制限されたシェルの一種です。

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

最初のtarコマンドは、「-」というファイルを作成します。これは、この場合「標準出力」を意味する特別なトークンです。作成されたアーカイブには、現在のディレクトリ（。）内のすべてのファイルとすべてのサブディレクトリが含まれます（tarはデフォルトで再帰的です）。このアーカイブファイルは、box2マシンに送信するremshコマンドにパイプされます。ボックス2では、最初に適切な受信ディレクトリに変更し、受信ファイルを「-」または「標準入力」から抽出します。

ネットワークリンクがデータで飽和していることを確認するために、これらのtarコマンドのうち6つを同時に実行しましたが、ディスクアクセスが制限要因だったのではないかと考えています。

ファイルシステムをバイパスします。

ファイルが存在するこのパーティションをアンマウントできますか、それとも読み取り専用でマウントできますか？それをしてから、次のようにします：

dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"

次にdiskimage.bin、宛先側でループバックデバイスとしてマウントし、そのファイルを実際の宛先ファイルシステムにコピーするか、適切なツールを使用して宛先側の空のパーティションにステッチバックします（危険ですが、おそらく可能です） 、私はそれをやったことがないが。）

本当に勇気があるならdd、宛先側のパーティションに直接戻すことができます。私はそれをお勧めしません。

あなたは次を試すことができます（ファイルのバッチであるかもしれません）

• ファイルのバッチをtar
• それらをgzipします
• 可能であればscpを使用してコピー
• ガンジップ
• ファイルを解凍します

sthが示唆するように、ssh経由でtarを試すことができます。

暗号化を必要としない場合（元はrsyncを使用していましたが、rsync + sshであるとは言及していませんでした）、netcatを使用してtarを試して、sshのオーバーヘッドを回避できます。

もちろん、gzipまたは他の圧縮方法を使用して、時間を短縮することもできます。

他に考慮すべきことがあります。これを試して：

• 動的なサイズのVHDを作成する
• おそらくディレクトリとしてマウントします
• 「ディスク全体を圧縮」属性を設定します

これを行うことにより、ファイルの書き込み時に行われたため、ディレクトリの反復または圧縮のオーバーヘッドがありません。移動するファイルはVHDのみです。

Windowsでは、デフォルトのTCPパケットサイズを16348のように大きく設定します。これは、IPヘッダーのオーバーヘッドが小さくなることを意味します。

しかし、私が遭遇したことの1つは、ネットワークまたはUSB転送のためにファイルサイズを100 Mb未満に保つことが最善であることです。そのためにRar.exeを使用します-ファイルを分割します。

チャンピオンのように機能します。これはLinuxの「dd」に相当します。圧縮されたファイルシステムをディレクトリにマウントする概念はLinuxでも同様であるため、同じロジックが適用されます。他の方法と同様に、操作を開始する前にすべてのファイルが閉じられていることを確認する必要があります。

これには、フォルダーにサイズクォータを設定できるという利点もあります。VHDが固定サイズである場合、その制限を超えてもサーバーは停止せず、ファイルの作成または書き込みでエラーが発生します。

NTFSとしてフォーマットされたVHDは、フォルダー内の数百万のファイルも処理できます。