違いのみを送信するため、同じファイルセットを送信する場合にrsync適しています。tarすべてが常に送信されるため、すでに多くのデータがある場合はリソースが無駄になります。この場合、tar + rsync + untarフォルダをrsync --delete。

ファイルを初めてコピーする場合は、最初に圧縮してから送信して解凍すると（AFAIKはパイプ入力を許可しない）、とにかく作業を行う必要がないため、面倒でrsync常にrsyncよりも悪くなります。rsynctar

ヒント：rsyncバージョン3以降は増分再帰を実行します。つまり、すべてのファイルを計算する前に、ほぼ即座にコピーを開始します。

rsyncヒント2：overを使用している場合は、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

そして、この2つの方法を使用して、リモートサーバーへのファイル転送を複数回テストします（同じ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上の両方のシステムで同じテストを実行し、rsync + tarははるかに少ないネットワークトラフィックでより良いパフォーマンスを発揮しました。ジャンボフレームだと思います。

より大きなデータセットでは、rsync + tarがrsyncよりも優れている可能性があります。しかし、正直なところ、私はそれが問題を引き起こす価値がないと思います。荷物を安くして解放するためには、両側に2倍のスペースが必要であり、上記ですでに述べたように、いくつかの異なるオプションがあります。