2つのサーバー間で大量のファイルをすばやくコピーする方法

2つのサーブ（Ubuntu）間で大量のmp3を転送する必要があります。巨大とは、平均で300Kの約100万個のファイルを意味します。試しましたscpが、1週間ほどかかりました。（約500 KB /秒）HTTPで1つのファイルを転送すると、9〜10 MB /秒になりますが、すべてを転送する方法がわかりません。

それらすべてをすばやく転送する方法はありますか？

私はタールをお勧めします。ファイルツリーがすでに類似している場合、rsyncは非常にうまく機能します。ただし、rsyncは各ファイルで複数の分析パスを実行し、変更をコピーするため、初期コピーのtarよりもはるかに遅くなります。このコマンドはおそらくあなたが望むことをするでしょう。マシン間でファイルをコピーし、権限とユーザー/グループの所有権の両方を保持します。

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

以下のマッキントッシュのコメントによると、これはrsyncに使用するコマンドです

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

外付けハードドライブと同日配達サービス。

rsyncを使用します。

ディレクトリ一覧が利用可能なHTTP経由でエクスポートされている場合は、wgetおよび--mirror引数も使用できます。

SCPがすべてを暗号化している（したがってCPUのボトルネックになっている）ため、HTTPはSCPよりも高速であることがすでにわかっています。HTTPとrsyncは暗号化されていないため、より高速に移動します。

Ubuntuでのrsyncの設定に関するドキュメントを次に示します。https：//help.ubuntu.com/community/rsync

これらのドキュメントでは、SSHを介したrsyncのトンネリングについて説明していますが、プライベートLAN上でデータを移動するだけの場合は、SSHは不要です。（私はあなたがプライベートLANにいると仮定しています。インターネットで9〜10MB /秒を取得している場合、どのような接続があるのか​​知りたいです！）

比較的安全でないrsyncサーバーをセットアップできるようにする他の非常に基本的なドキュメントをいくつか紹介します（SSHに依存しない）：http : //transamrit.net/docs/rsync/

あまり議論することなく、netcat、ネットワークスイスナイフを使用します。プロトコルのオーバーヘッドはありません。ネットワークソケットに直接コピーします。例

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

rsyncを使用する場合、多くのファイルを使用して、両端でバージョン3以上を取得しようとします。その理由は、転送を開始する前に、下位バージョンがすべてのファイルを列挙するためです。新しい機能は、incremental-recursionと呼ばれます。

rsyncが別の3.xバージョンと通信しているときに、新しい増分再帰アルゴリズムが使用されるようになりました。これにより、転送がより迅速に開始され（すべてのファイルが検出される前）、必要なメモリがはるかに少なくなります。いくつかの制限については、マンページの--recursiveオプションを参照してください。

他の人がすでに推奨しているように、rsync 暗号化によるCPUオーバーヘッドがボトルネックである場合は、blowfishな​​ど、CPUをあまり使用しないアルゴリズムを使用してください。例えば

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

以下からの切り替えデータの80 TB（小さなファイルの何百万）昨日、移動中rsyncにtar はるかに高速であることが証明され、我々がしようと停止したように、

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

tar代わりに切り替えました...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

これらのサーバーは同じLAN上にあるため、宛先はソースシステムにNFSマウントされ、プッシュを実行しています。さらに高速化することはできません。atimeファイルを保存しないことにしました。

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

以下の図は、rsyncからtarへの変更の違いを示しています。それは私の上司のアイデアであり、私の同僚はそれを実行し、彼のブログですばらしい記事を書きました。きれいな写真が好きです。:)

大量のファイルをコピーするとき、多くのファイルを開いたり閉じたりするオーバーヘッドがあるため、tarやrsyncなどのツールは必要以上に効率が悪いことがわかりました。これらのシナリオでは、tarよりも高速なfast-archiverというオープンソースツールを作成しました。https：//github.com/replicon/fast-archiver ; 複数の同時ファイル操作を実行することにより、より高速に動作します。

200万を超えるファイルのバックアップでの高速アーカイバとtarの例を次に示します。fast-archiverはアーカイブに27分かかりますが、tarは1時間23分かかります。

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

サーバー間でファイルを転送するには、次のように、sshでfast-archiverを使用できます。

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

私も使用するnetcatことを好むことを除いて、同様にタールスルーアプローチを使用しますsocat-あなたの状況に合わせて最適化するためのより多くのパワー-例えば、mssを微調整することによって。（また、必要に応じて笑いますが、socat引数は一貫しているため覚えやすいと思います）。だから私にとって、これは最近、新しいサーバーに物事を移動しているので非常に一般的です：

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

エイリアスはオプションです。

別の選択肢はUnisonです。この場合、Rsyncよりもわずかに効率的である可能性があり、リスナーを設定する方が多少簡単です。

トップアンサーにタイプミスがいくつかあるようです。これはうまくいくかもしれません：

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

• ネットワークファイルシステム（NFS）を使用し、Midnight Commander（mc）、Nautilus（gnomeから）など、好きなものをコピーします。NFS v3を使用した結果は良好です。
• Samba（CIFS）を使用して、必要なファイルをコピーしますが、どれほど効率的かはわかりません。
• HTTPでのwget --mirrorようエヴァンアンダーソンが示唆しているまたはその他のHTTPクライアント。厄介なシンボリックリンクや誤解を招くインデックスファイルが含まれないように注意してください。持っているのがMP3だけであれば、安全である必要があります。
• rsyncを。私はかなり良い結果でそれを使用しましたが、その素晴らしい機能の1つは、後で転送を中断して再開できることです。

他の人がnetcatの使用を推奨していることに気付きました。基づいて、私の経験それに私はそれが他のソリューションと比べて遅いだと言うことができます。

Scott Packのすばらしい回答のおかげで（以前はsshでこれを行う方法を知りませんでした）、この改善を提供できます（bashシェルの場合）。これにより、並列圧縮、進行状況インジケータが追加され、ネットワークリンク全体の整合性がチェックされます。

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pvは、パイプ用の優れたプログレスビューアプログラムでありpigz、CPUがデフォルトで持つスレッドと同じ数のスレッドを使用する並列gzipプログラムです（最大8個まで）。あなたはチューニング圧縮レベルは、より優れた帯域幅をネットワークし、それを交換するCPUの比率に合わせてすることができますpxz -9eし、pxz -dあなたが帯域幅よりもはるかに多くのCPUを持っている場合。完了時に2つの合計が一致することを確認するだけです。

このオプションは、非常に大量のデータや高遅延ネットワークに役立ちますが、リンクが不安定でドロップした場合にはあまり役立ちません。これらの場合、rsyncはおそらく再開できるため、最良の選択です。

サンプル出力：

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

ブロックデバイスの場合：

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

明らかに、count =、skip =、seek =などで同じサイズまたは制限であることを確認してください。

この方法でファイルシステムをコピーすると、多くの場合、最初dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefsにほとんどの未使用スペースがゼロになり、xferが高速化されます。

高速なネットワークカードをインストールしない限り、scpよりも良い結果が得られるとは思いません。インターネットでこれをしている場合、それは助けにはなりません。

rsyncの使用をお勧めします。速くはならないかもしれませんが、少なくとも失敗した場合（または時間がかかりすぎてシャットダウンした場合）、次回中断したところから再開できます。

ギガビットイーサネットを使用して2台のマシンを直接接続できる場合は、おそらく最速です。

100Mb / sの場合、理論上のスループットは12.5 MB / sであるため、10MB / sではかなりうまくいきます。

また、おそらくsshを使用して、rsyncを実行することを提案します。何かのようなもの：

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

100Mb / sでは、CPUがデータレートに大きな影響を与えることなく暗号化/復号化を処理できるはずです。また、データフローを中断した場合、中断したところから再開できるはずです。スタートアップが実際に何かを転送するまでに数百万のファイルがあるので注意してください。

Oracleログを転送していたことを除いて、これに遭遇しました。

内訳は次のとおりです

• scp

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

FTPを大成功で使用しました（大成功はGbネットワークで〜700Mb / sに相当します）。10MB（80Mb / sに相当）を取得している場合、おそらく何かが間違っています。

データのソースと宛先について教えてください。シングルドライブからシングルドライブですか？RAID to USB？

この質問にはすでに答えがありますが、Gb / sクロスオーバーケーブルでネットワークがこれほど遅い場合は、絶対に修正が必要です。

2つのマシンが同じLAN上にあるか、またはセキュアチャネル（つまりSSHを使用する）が必須であるかについては言及しませんでしたが、使用できる別のツールはnetcatです。

私は受信側のマシンで次を使用します：

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

次に、送信側で：

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

次の利点があります。

• sshが持つ暗号化のCPUオーバーヘッドはありません。
• gzip -1それは、最大スループットを維持しながら、圧縮のビットを与え、良好なトレードオフを行うようにCPUを飽和させることなく光の圧縮を提供します。（おそらくMP3データにはそれほど有利ではありませんが、害はありません。）
• ファイルをグループに分割できる場合は、2つ以上のパイプを並行して実行して、ネットワーク帯域幅が飽和状態になっていることを確認できます。

例えば、

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

ノート：

• 転送方法に関係なく、rsyncまたはunisonを後で実行して、すべてを確実に取得できるようにします。
• tar代わりに使用することもできますcpio。
• 最終的にsshを使用する場合でも、圧縮自体を使用していないことを確認し、gzip -1代わりにCPUの飽和を回避するために自分自身をパイプ処理します。（または、少なくともCompressionLevelを1に設定します。）

適切なオプションを備えたシンプルなscpは、LAN経由で9〜10 MB / sに簡単に到達します。

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

これらのオプションを使用すると、オプションがない場合よりもスループットが4倍または5倍速くなった可能性があります（デフォルト）

あなたは、SRC側にftpサーバを持っている場合は、使用することができますncftpgetからncftpのサイト。内部でtarを使用するため、小さなファイルでも問題なく機能します。

ある比較では、1.9GBの小さなファイル（33926ファイル）を移動しています。

1. scpの使用には11分59秒かかります
2. rsyncの使用には7分10秒かかります
3. ncftpgetの使用には1分20秒かかります

BBCPコマンドを使用して転送を試みることもできます。それは本当に悲鳴を上げるバッファー付きの並列sshです。パイプの供給を維持できれば、通常は90％以上のラインレートを取得できます。

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

通常、私たちはサフを動かさずに済むように真剣に努力します。ZFSプールを使用します。これは、常にディスクスペースを「追加」するだけです。しかし、時には...あなたはただ物を動かす必要があります。フルブラストでもコピーに数時間（または数日）かかる「ライブ」ファイルシステムがある場合、ole 2ステップのzfs送信ルーチンを実行します。

1. ZFSスナップショットを作成し、新しいマシンの新しいプールに転送します。それがかかる限りそれを取りましょう。
2. 2番目のスナップショットを作成し、増分として送信します。増分スナップショットには、最初からの（非常に小さい）変更セットのみが含まれているため、比較的迅速に処理されます。
3. 増分スナップショットが完了すると、元のスナップショットを切り替えて新しいコピーにカットオーバーでき、「オフラインダウンタイム」が最小限に抑えられます。

また、zfsダンプもBBCP経由で送信します。ネットワークの使用率を最大化し、転送時間を最小化します。

BBCPは無料で利用でき、グーグルで検索することができ、簡単にコンパイルできます。srcマシンと宛先マシンの両方の/ usr / local / binにコピーするだけで、ほとんど機能します。

私の答えはここでは少し遅れていると思いますが、SFTPを介して他のサーバーに接続するために、あるサーバーでmc（Midnight Commander）を使用して良い経験をしました。

FTP経由で接続するオプションは、「左」および「右」メニューにあり、次のようにアドレスを入力します。

/#ftp:name@server.xy/

または

/#ftp:name@ip.ad.dr.ess/

ローカルファイルシステムとほぼ同じように、ファイル操作をナビゲートして実行できます。

バックグラウンドでコピーを実行する組み込みオプションがありますが、mcのコピー中にscreenコマンドを使用して画面からデタッチすることをお勧めします（実行速度も速いと思います）。

rSyncオプションの@scottpack回答へ

アップロードの進行状況を表示するには、以下に示すように、コマンドで-avWの後にオプションとして「--progess」を使用します。

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

以下は、いくつかの手法を比較するための簡単なベンチマークです。

• ソースは4コアIntel（R）Xeon（R）CPU E5-1620 @ 3.60GHz、250 MbpsおよびSATAドライブ
• 宛先は、6コアIntel（R）Xeon（R）CPU E-2136 @ 3.30GHz、帯域幅1 GbpsおよびSSDドライブです

ファイル数：9632、合計サイズ：814 MiB、平均サイズ：84 KiB

• RSYNC：1m40.570s
• RSYNC +圧縮：0m26.519s
• TAR + NETCAT：1分58.763秒
• TAR +圧縮+ NETCAT：0m28.009s

tar / netcatのコマンドは次のとおりです。

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

rsyncまたはtarを使用して、すべてを1つのファイル内に含めてから、scpにします。ディスクスペースが不足している場合は、作成中にsshにtarを直接パイプできます。

MP3やその他の圧縮ファイルを使用して送信している場合、これらのファイルをさらに圧縮しようとするソリューションから多くを得ることができません。解決策は、両方のサーバー間に複数の接続を作成し、2つのシステム間の帯域幅により大きな負荷をかけることができるものです。これが限界に達すると、ハードウェアを改善しなければ得られるものはあまりありません。（たとえば、これらのサーバー間の高速ネットワークカード。）

1GBのファイルをコピーするためのツールをいくつか試しました。結果は以下のとおりです。rsyncを再開する方法はsshをバックエンドとして使用しないため、同じ結果になります。結論として、wget -bqcを使用してhttpにアクセスし、しばらく時間がかかります。これが役立つことを願っています

BackupPCディスクを別のマシンにコピーする必要がありました。

rsyncを使用しました。

マシンには256 MBのメモリがありました。

私が従った手順はこれでした：

• rsyncなしで実行-H（9時間かかりました）
• rsyncが終了したら、cpoolディレクトリを同期し、ディレクトリで開始しましたpc。乗り換えを切りました。
• その後rsync、-Hフラグを付けて再起動し、pcディレクトリにハードリンクされたすべてのファイルが正しく転送されました（プロシージャはすべての実際のファイルを見つけcpoolてpcディレクトリにリンクしました）（3時間かかりました）。

最終的にdf -m、余分なスペースが消費されていないことを確認できました。

このようにして、メモリとrsyncの問題を回避します。常にtopとtopを使用してパフォーマンスを確認でき、最終的に165GBのデータを転送しました。