web-dev-qa-db-ja.com

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

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

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

linuxperformancefile-transfer
96
nicudotro

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

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

以下のMackintoshのコメントに従って、これはrsyncに使用するコマンドです

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

外付けハードドライブと即日配達。

38
Adam

私は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/

17
Evan Anderson

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

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

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

Rsyncを使用する場合、多くのファイルがあるため、両端でバージョン3以降を取得しようとします。これは、バージョンが小さいほど、転送を開始する前にすべてのファイルが列挙されるためです。新しい機能はincremental-recursionと呼ばれます。

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

8
Kyle Brandt

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

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

7
janneb

昨日80 TB of data（何百万もの小さなファイル））を移動するときに、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への変更の違いを示しています。それは私の 上司 のアイデアであり、私の 同僚 はそれを実行して素晴らしい 彼のブログの記事 にしました。私は pretty pictures が好きです。 :)

rsync_vs_tar

7
Philip Durbin

多数のファイルをコピーするとき、多くのファイルを開いたり閉じたりするオーバーヘッドがあるため、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 [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
4
mfenniak

私はnetcatアプローチを通じてtarも使用しますが、socat-mssを調整するなどして、状況に合わせて最適化するためのより多くの能力を使用することを好みます。 （また、必要に応じて笑いますが、socat引数は一貫しているので覚えやすくなっています）。だから私にとっては、新しいサーバーに物事を移動しているので、これは最近非常に一般的です：

Host1$ tar cvf - filespec | socat stdin tcp4:Host2:portnum

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

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

3
R. Francis Smith
  • Network File System（NFS）そして、好きなようにコピーします。真夜中の司令官（mc）、ノーチラス（gnomeから）。私はNFS v3を使用して、良い結果を得ました。
  • Samba（CIFS）そして、好きなようにファイルをコピーしますが、どれほど効率的かはわかりません。
  • [〜＃〜] http [〜＃〜]とwget --mirror as Evan Anderson が提案した、または他の任意のhttpクライアント。厄介なシンボリックリンクや誤解を招くインデックスファイルを作成しないように注意してください。あなたが持っているすべてがMP3であるならば、あなたは安全であるはずです。
  • rsync。私はかなり良い結果でそれを使用しました、そしてその素晴らしい機能の一つはあなたが後で転送を中断して再開できることです。

他の人がnetcatの使用を勧めていることに気づきました。 私の経験に基づいて、他のソリューションと比較して遅いと言えます。

2
Cristian Ciupitu

上の答えにはいくつかのタイプミスがあるようです。これはうまくいくかもしれません：

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

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を高速化します。

2
Daniel Santos

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

2
Adam D'Amico

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または nison を実行して、すべてが確実に取得されるようにします。
  • tar の代わりにcpioを使用することもできます。
  • 最終的にsshを使用する場合でも、圧縮自体は使用せず、gzip -1代わりに、CPU飽和を回避するための自分。 （または、少なくともCompressionLevelを1に設定します。）
1
Evan

Src側にFTPサーバーがある場合は、 ncftpサイト からncftpgetを使用できます。内部でtarを使用するため、小さなファイルで問題なく動作します。

1つの比較はこれを示しています：1.9GBの小さなファイル（33926ファイル）の移動

  1. Scpの使用には11分59秒かかります
  2. Rsyncの使用には7分10秒かかります
  3. Ncftpgetの使用には1分20秒かかります
1
Ali Nikneshan

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

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

通常、私達はサフを動かさないように真剣に努力します。私たちは常にディスク容量を「追加」できるZFSプールを使用しています。しかし、時々...あなたはものを移動する必要があります。フルブラストに移行した場合でも、コピーに数時間（または数日）かかる可能性のある「ライブ」ファイルシステムがある場合、次の2つのステップのzfs送信ルーチンを実行します。

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

また、BBCPを介してzfsダンプを送信します。これにより、ネットワーク使用率が最大化され、転送時間が最小化されます。

BBCPは無料で入手でき、ググることもできます。コンパイルは簡単です。 srcと宛先マシンの両方の/ usr/local/binにコピーするだけで、ほとんど問題なく動作します。

1
C. Shamis

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

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

/#ftp:[email protected]/

または

/#ftp:[email protected]/

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

これには、バックグラウンドでコピーを行う組み込みオプションがありますが、mcがコピーしている間、screenコマンドを使用して画面から切り離すことをお勧めします（私はそれよりも高速に動作すると思います）。

1
w-sky

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

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

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

enter image description here

1
Dinesh Sunny

適切なオプションを使用した単純なscpは、LAN経由で9〜10 MB /秒に簡単に到達します。

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

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

1
user57125

より高速なネットワークカードをインストールしない限り、scpを超えることはできないと思います。インターネット経由でこれを行っている場合、それは助けにはなりません。

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

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

1
Brent

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

また、おそらくsshを介して、rsyncを行うという提案をエコーし​​ます。何かのようなもの：

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

100Mb/sでは、CPUはデータレートにそれほど影響を与えずに暗号化/復号化を処理できる必要があります。また、データフローを中断すると、中断したところから再開できるはずです。 「何百万」ものファイルがあると、スタートアップが実際に何かを転送するまでに少し時間がかかることに注意してください。

1
David Mackintosh

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クロスケーブルでネットワークの速度が低下している場合は、絶対に修正する必要があります。

1
Matt Simmons

ここにいくつかのテクニックを比較するための簡単なベンチマークがあります、

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

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

  • RSYNC：1分40.570秒
  • RSYNC + COMPRESSION：0m26.519s
  • TAR + NETCAT：1分58.763秒
  • TAR + COMPRESSION + NETCAT：0m28.009s

Tar/netcatのコマンドは：

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

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

0
Wim ten Brink

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

私はrsyncを使用しました。

マシンには256 MBのメモリが搭載されていました。

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

  • 実行されたrsyncなしで-H（9時間かかった）
  • rsyncが終了したら、cpoolディレクトリを同期し、pcディレクトリから始めました。振込をカットします。
  • 次にrsyncを-Hフラグを付けて再起動し、pcディレクトリにハードリンクされたすべてのファイルが正しく転送されました（この手順では、cpool内のすべての実際のファイルが見つかり、次にpcディレクトリにリンクされています）（3時間かかりました）。

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

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

0
Hector

1 GBのファイルをコピーするためにいくつかのツールを試しました。結果は次のとおりです。HTTPが最も速く、wget -c nc second in lineがscpが最も遅く、数回失敗しました。 rsyncを再開する方法はsshをバックエンドとして使用しないため、同じ結果になります。結論として、私はwget -bqcを使用してhttpにアクセスし、少し時間をかけます。これが役に立てば幸い

0
Mijo

rsyncまたはそれを1つのファイル内ですべて圧縮してからscpで圧縮することもできます。ディスクスペースが足りない場合は、作成中にsshに直接tarをパイプすることができます。

0
Adam Gibbins