違いのみを送信するため、同じファイルセットを送信する場合に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倍のスペースが必要であり、上記ですでに述べたように、いくつかの異なるオプションがあります。

rsync圧縮も行われる。フラグを使用してください-z。を超える場合は、sshSSH圧縮を使用することもできます。私の気持ちでは、繰り返しの圧縮レベルは役に立たないということです。これは重要な結果が得られずにサイクルだけを消費するだけです。圧縮を試すことをお勧めしますrsync。かなり効果があるようです。使用tarまたはその他の事前/事後圧縮をスキップすることをお勧めします。

私は通常rsyncをrsync -abvz --partial...。

今日私のホームディレクトリをNASにバックアップする必要がありましたが、この議論に触れて結果を追加したかったのです。簡単に言えば、私の環境では、ネットワークを介してターゲットファイルシステムにtaringすることは、同じターゲットのrsyncよりはるかに高速です。

環境：SSDハードドライブを使用するSource i7デスクトップコンピュータ。ターゲットコンピュータSynology NAS DS413jは、ギガビットLANを介してソースコンピュータに接続されています。

もちろん、関連するキットの正確な仕様は性能に影響を与え、両端のネットワークハードウェア品質に関して正確な設定の詳細を知らない。

ソースファイルは私の〜/ .cacheフォルダです。これにはほとんど1.2GBの非常に小さなファイルが含まれています。

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を完全に別々の段階に置いた。実際の適用のために、SSHを介してtar出力を受信機に送信する圧縮解除プロセスに関して、Gillesが上記の投稿を提案します。

時間：

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

rsyncのパフォーマンスがtar操作に比べて驚くほど劣っていることは明らかです。これはおそらく上記のネットワークパフォーマンスによるものです。

多数の（ほとんどの小さな）ファイル（ホームディレクトリのバックアップなど）をバックアップしたい人には、tar方法をお勧めします。 rsyncは非常に悪い選択肢のようです。私の手順のいずれかが正しくない場合は、この投稿に戻ります。

ギャップ

小さなディレクトリ（たとえば、小さなディスク容量を使用する）の場合、これは同期されるファイルのファイル情報を確認するオーバーヘッドによって異なります。一方では、rsync変更されていないファイルの転送に時間が節約されますが、他方では各ファイルの情報を転送する必要があります。

内部内容がよく理解できませんねrsync。ファイル統計によってレイテンシが発生するかどうかは、rsyncデータの転送方法によって異なります。ファイル統計が1つのフラグメントに送信される場合、RTTを使用するとtar + rsync + untarが高速になる可能性があります。

しかし、1GiBのデータがある場合、接続が非常に高速でなければ、rsyncはより速くなります！