tar + rsync + untar。 rsyncに勝る速度のメリットはありますか？
私はよく、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と同期させておく利点も失われます。
初めてファイルをコピーする場合、最初にパケット化してから送信してからアンパックする（AFAIK rsyncはパイプで入力されない）と、rsyncが勝つため、単にrsyncするよりも常に厄介でとにかくtar以上のタスクを実行する必要はありません。
ヒント：rsyncバージョン3以降は増分再帰を実行します。つまり、すべてのファイルをカウントする直前にコピーを開始します。
ヒント2：rsyncよりも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
この場合、rsync + tarを使用してもネットワークトラフィックが少なくてもメリットはありません。これは、デフォルトのmtuが1500で、ファイルサイズが10kの場合に予想されます。 rsync + tarはより多くのトラフィックを生成し、2〜3秒間遅くなり、クリーンアップする必要がある2つのガベージファイルを残しました。
私は同じLAN上の2台のマシンで同じテストを行いましたが、rsync + tarの方がはるかに良い時間で、はるかに少ないネットワークトラフィックでした。ジャンボフレームの原因を想定しています。
たぶん、rsync + tarは、はるかに大きなデータセットのrsyncだけよりも優れているでしょう。しかし、率直に言って、それは問題に値するものではないと思います。パックとアンパックには両側に2つのスペースが必要です。また、すでに説明したように、他にもいくつかのオプションがあります。
rsyncも圧縮を行います。 -zフラグを使用します。 sshで実行している場合は、sshの圧縮モードも使用できます。繰り返しのレベルの圧縮は役に立たないと感じています。サイクルを燃やすだけで、大きな結果は得られません。 rsync圧縮を試すことをお勧めします。かなり効果があるようです。また、tarやその他の事前/事後の圧縮の使用はスキップすることをお勧めします。
私は通常、rsync -abvz --partial...としてrsyncを使用します。
今日、ホームディレクトリをNAS=にバックアップする必要があり、このディスカッションに遭遇しました。結果を追加すると思いました。長い話ですが、ターゲットファイルシステムへのネットワーク経由のtar私の環境では、同じ宛先にrsyncするよりも高速です。
環境：SSDハードドライブを使用するソースマシンi7デスクトップ。宛先マシンSynology NASソースマシンへのギガビットLAN接続上の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出力をレシーバーのuntaringプロセスにパイプすることを含む上記の投稿をお勧めします。
タイミング：
1a - 33 seconds
1b - 1 minutes 48 seconds
2 - 22 minutes
Rsyncのパフォーマンスがtar操作と比較して驚くほど低いことは非常に明らかです。これは、おそらく上記の両方のネットワークパフォーマンスに起因する可能性があります。
ホームディレクトリのバックアップなど、ほとんどが小さなファイルを大量にバックアップする場合は、tarアプローチを使用することをお勧めします。 rsyncは非常に悪い選択のようです。私の手順のいずれかが不正確であると思われる場合は、この投稿に戻ります。
ニック
プロセスに検証レイヤーを追加するので、rsyncを使用して実際に要求されたとおりにtarアーカイブを送信することは、無駄またはリソースの再利用になります。 Rsyncは、個々のファイルをチェックしたい場合に、tarファイルの正確性をチェックサムします。 （送信側で欠陥がある可能性のあるtarファイルがすでに受信側で同じ効果を示していることを知ることは役に立ちません）。アーカイブを送信する場合は、ssh/scpで十分です。
アーカイブの送信を選択しなければならない理由の1つは、選択したtarが、アクセス制御リストや、拡張属性（Solaris）やリソースフォーク（MacOS）に保存されることが多いその他のメタデータなど、ファイルシステムの特殊機能をより多く保存できるかどうかです。 ）。そのようなことに対処するときの主な関心事は、どのファイルがソースファイルシステム上のファイルに関連付けられているすべての情報を保存できるかということです。
速度が主な関心事である場合、それはファイルのサイズに大きく依存します。一般に、多数の小さなファイルはrsyncやscpよりも正しくスケーリングされません。これは、個々のネットワークパケットをそれぞれ無駄にするためです。1つのtarファイルには、単一のネットワークパケットのデータロード内にそれらのファイルがいくつか含まれます。小さなファイルは個別に圧縮するよりも全体として圧縮する可能性が高いため、tarファイルが圧縮されている場合はさらに優れています。私の知る限り、最初の転送のように単一のファイル全体を送信すると、rsyncとscpの両方が最適化に失敗し、各ファイルがプロトコルオーバーヘッド全体でデータフレーム全体を占有します（そして、チェックとバックに多くを浪費します）。ただし、 Janecek は、これがscpにのみ当てはまることを示しており、rsyncがネットワークトラフィックを最適化することを詳述していますが、メモリ内に巨大なデータ構造を構築することを犠牲にしています。記事 Efficient File Transfer、Janecek 2006 を参照してください。そのため、彼によれば、scpとrsyncの両方が小さなファイルで不適切にスケーリングすることは事実ですが、まったく異なる理由があります。今週末、情報源を掘り下げる必要があると思います。
実際の関連性としては、ほとんど大きなファイルを送信していることがわかっている場合、速度に大きな違いはありません。rsyncを使用すると、中断されたときに残っていた場所を処理できるという追加の利点があります。
追記：最近、 rdist は忘却に陥るようですが、rsyncが登場する以前は、非常に有能なツールであり、広く使用されていました（sshで安全に使用すると安全で、それ以外では安全ではありません）。変更されたコンテンツを転送するだけでは最適化されなかったため、rsyncほどパフォーマンスは良くありませんでした。 rsyncとの主な違いは、それが設定されている方法と、ファイルの更新ルールがどのように記述されているかにあります。
小さなディレクトリ（使用されているディスク領域のように小さい）の場合、同期されるファイルのファイル情報を確認するオーバーヘッドに依存します。一方、rsyncは、変更されていないファイルを転送する時間を節約します。一方で、実際には、各ファイルに関する情報を転送する必要があります。
rsyncの内部は正確にはわかりません。ファイル統計が遅延を引き起こすかどうかは、rsyncがデータを転送する方法に依存します。ファイル統計が1つずつ転送される場合、RTTはtar + rsync + untarをより高速にする可能性があります。
しかし、もしあれば、1 GiBデータの場合、接続が本当に高速でない限り、rsyncはかなり高速になります！
数テラバイトのデータを全国に1回だけ移動する必要がありました。実験として、rsyncとssh/tarを使用して2つの転送を実行し、それらの比較を確認しました。
結果：
rsyncは、平均速度2.76メガバイト/秒でファイルを転送しました。ssh/tarは、平均速度4.18メガバイト/秒でファイルを転送しました。
詳細：私のデータは数百万の.gz圧縮ファイルで構成されており、その平均サイズは10メガバイトですが、一部は1ギガバイトを超えるものもあります。ディレクトリ構造はありますが、ファイル内のデータのサイズによって小さくなります。他にほとんど何でもすることがあれば、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 -)"