多くの場合、10Kか​​ら100Kのファイルを含むフォルダーをリモートマシン（キャンパス内の同じネットワーク内）に送信しています。

私はそれを信じる理由があるかどうか疑問に思っていました、

 tar + rsync + untar

または単に

 tar (from src to dest) + untar

実際にはより速くなる可能性があります

rsync 

初めてファイルを転送するとき。

私は、圧縮を使用する場合と使用しない場合の2つのシナリオで上記に対処する回答に興味があります。

更新

10,000個の小さなファイル（合計サイズ= 50 MB）を移動するいくつかの実験をtar+rsync+untar実行しましたが、rsync直接実行するよりも一貫して高速でした（両方とも圧縮なし）。

同じファイルのセットを送信する場合は、rsync差分のみを送信するため、より適しています。tar常にすべてを送信します。これは、大量のデータが既に存在する場合のリソースの無駄です。tar + rsync + untarこの場合には、この優位性を失うだけでなく、とに同期フォルダを保つことの利点rsync --delete。

初めてファイルをコピーし、最初にパケットを送信し、次に送信してからアンパックすることは（rsync面倒なパイプ入力を受け取らない）面倒でありrsync、tarとにかく何もする必要がないので、単にrsyncするよりも常に悪いです。

ヒント：rsyncバージョン3以降はインクリメンタル再帰を実行します。つまり、すべてのファイルをカウントする直前にコピーを開始します。

ヒント2：rsyncover を使用する場合はssh、次のいずれかを使用することもできますtar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

あるいは単に scp

scp -Cr srcdir user@server:destdir

一般的なルール、シンプルに保ちます。

更新：

59Mのデモデータを作成しました

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

両方の方法を使用して、リモートサーバーへのファイル転送（同じLANにない）を数回テストしました

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

送信されたsshトラフィックパケットから個別のログを保持しながら

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

この場合、デフォルトのmtuが1500で、ファイルのサイズが10kである場合に期待されるrsync + tarを使用しても、ネットワークトラフィックが少ないという利点はありません。rsync + tarはより多くのトラフィックを生成し、2〜3秒間遅くなり、クリーンアップする必要がある2つのガベージファイルを残しました。

同じLAN上の2台のマシンで同じテストを行ったところ、rsync + tarのほうがはるかに良い時間を過ごし、ネットワークトラフィックははるかに少なくなりました。ジャンボフレームの原因と思われます。

たぶん、rsync + tarは、はるかに大きなデータセットでrsyncを行うよりも良いでしょう。しかし、率直に言って、私はそれが面倒の価値があるとは思わない、あなたは荷造りと荷解きのためにそれぞれの側に二重のスペースを必要とします。

rsync圧縮も行います。-zフラグを使用します。オーバーランした場合ssh、sshの圧縮モードを使用することもできます。私の感覚では、圧縮の繰り返しレベルは有用ではありません。重大な結果なしにサイクルを燃焼させるだけです。rsync圧縮を試すことをお勧めします。かなり効果的です。そして、tar圧縮の使用や他の圧縮の前後をスキップすることをお勧めします。

私は通常rsyncを使用しrsync -abvz --partial...ます。

今日、ホームディレクトリをNASにバックアップする必要があり、この議論にぶつかりました。結果を追加すると思いました。要するに、ネットワークを介してターゲットファイルシステムにtarすることは、同じ宛先にrsyncするよりも私の環境でははるかに高速です。

環境：SSDハードドライブを使用するソースマシンi7デスクトップ。ソースマシンへのギガビットLAN接続上の宛先マシンSynology NAS DS413j。

含まれるキットの正確な仕様は、当然、パフォーマンスに影響を与えます。また、両端のネットワークハードウェアの品質に関する正確なセットアップの詳細はわかりません。

ソースファイルは、ほとんどの非常に小さなファイルの1.2Gbを含む〜/ .cacheフォルダーです。

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

タスクを説明するためだけに、1aと1bを完全に別個のステップとして保持しました。実際のアプリケーションでは、Gillesがsshを介してtar出力をレシーバーの展開プロセスにパイプすることを含む上記の投稿をお勧めします。

タイミング：

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

rsyncのパフォーマンスがtar操作に比べて驚くほど低いことは非常に明らかです。tar操作はおそらく上記の両方のネットワークパフォーマンスに起因する可能性があります。

ホームディレクトリのバックアップなど、大部分が小さなファイルを大量にバックアップする場合は、tarアプローチを使用することをお勧めします。rsyncは非常に貧弱な選択のようです。自分の手順のいずれかで不正確だったと思われる場合は、この投稿に戻ります。

ニック

rsyncを使用して要求どおりにtarアーカイブを送信することは、プロセスに検証レイヤーを追加するため、実際には無駄であるかリソースを再利用することになります。個々のファイルをチェックしたい場合、Rsyncはtarファイルの正確性をチェックサムします。（送信側で欠陥があったかもしれないtarファイルが受信側で同じ効果を既に示していることを知ることは助けになりません）。アーカイブを送信する場合、ssh / scpが必要です。

アーカイブの送信を選択しなければならない理由の1つは、選択したtarが、拡張属性（Solaris）またはRessource Forks（MacOS ）。そのようなことを扱うとき、あなたの主な関心事は、どのツールがソースファイルシステム上のファイルに関連付けられているすべての情報を保存できるかということです。ターゲットファイルシステムにもそれらを追跡する機能があります。

速度が主な関心事である場合、ファイルのサイズに大きく依存します。一般に、多数の小さなファイルはrsyncまたはscpに比べて大きくスケーリングします。これは、個々のネットワークパケットをすべて浪費するためです。tarファイルには、単一のネットワークパケットのデータロード内にそれらのいくつかが含まれます。tarファイルが圧縮されていれば、小さなファイルは個別よりも全体として圧縮される可能性が高いため、さらに良いでしょう。私の知る限り、rsyncとscpは両方とも、初期転送のように単一ファイル全体を送信するときに最適化に失敗し、各ファイルがそのプロトコルオーバーヘッド全体でデータフレーム全体を占有します（そして、チェックバックとチェックバックにより多くを浪費します）。しかしジャネチェクこれはscpのみに当てはまると述べており、rsyncはネットワークトラフィックを最適化するが、メモリ内に巨大なデータ構造を構築するという犠牲を払うことを詳述しています。効率的なファイル転送、Janecek 2006の記事を参照してください 。したがって、彼によると、scpとrsyncの両方が小さなファイルでひどくスケーリングすることは事実ですが、まったく異なる理由があります。今週末、情報源を掘り下げて調べる必要があると思います。

実用的な関連性については、大部分がより大きなファイルを送信していることがわかっている場合、速度に大きな違いはありません。rsyncを使用すると、中断されたときに残った場所に戻ることができるという利点があります。

あとがき：最近、rdistは忘れられているように見えますが、rsyncが登場する前は非常に有能なツールであり、広く使用されていました（sshで使用すると安全、それ以外は安全ではありません）。ただし、変更されたコンテンツを転送するだけでは最適化されなかったため、rsyncほどパフォーマンスは良くありませんでした。rsyncとの主な違いは、その構成方法と、ファイルを更新するためのルールの綴り方にあります。

小さなディレクトリ（使用済みディスク領域のように小さい）の場合、同期されるファイルのファイル情報をチェックするオーバーヘッドに依存します。一方では、rsync、変更されていないファイルを転送する時間を節約し、他方で、実際には各ファイルに関する情報を転送する必要があります。

の内部を正確に知りませんrsync。ファイルの統計が遅れを引き起こすかどうかは、rsyncデータの転送ます。ファイル統計が1つずつ転送される場合、RTTはtar + rsync + untarを高速化する可能性があります。

しかし、たとえば1 GiBのデータがある場合、接続が本当に高速でない限り、rsyncははるかに高速になります。

全国で数テラバイトのデータを正確に一度移動する必要がありました。実験として、rsyncとssh/tarを使用して2つの転送を実行し、それらの比較を確認しました。

結果：

• rsync 1秒あたり2.76メガバイトの平均速度でファイルを転送しました。
• ssh/tar 毎秒4.18メガバイトの平均速度でファイルを転送しました。

詳細： 私のデータは数百万の.gz圧縮ファイルで構成されており、その平均サイズは10メガバイトですが、一部はギガバイトを超えています。ディレクトリ構造がありますが、ファイル内のデータのサイズによって小さくなります。他にやることがほとんどある場合は、使用するだけでしたrsyncが、この場合ssh/tarは機能的なソリューションです。

私の仕事のrsync構成：

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

fileList.txtは、反対側のファイルの相対パス名の長いリストです。（--compress開始後、圧縮ファイルの生産性が低下していることに気付きましたが、再起動するつもりはありませんでした。）

私はsshとtarで別のものを始めました：

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

これがすべてをコピーすることを確認します。申し訳ありませんが、これは100％リンゴとリンゴの比較ではありません。

会社の社内ネットワークを使用しているときに、データソースコンピューターにアクセスするために仲介者を経由する必要があることを追加する必要があります。ターゲットコンピューターから仲介者へのping時間は21ミリ秒、仲介者からデータソースへのping時間は26ミリ秒です。これは両方の転送で同じでした。

仲介者を介したSSL接続は、~/.ssh/configエントリを介して行われます。

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

この時間：

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"