古いファイルがすでに存在する場合、rsyncに--link-destオプションを使用して同一のファイルをリンクさせる方法

--link-dest同一のファイルを使用することがすべての場合に機能すると考える人もいるかもしれません。ただし、ファイルが古く、内容が異なる場合でも、ファイルが存在する場合はそうではありません。

これは、次のrsyncのマニュアルページから--link-destです。

「rsyncは既存のファイルを決定的なものとして扱うため、このオプションは空の宛先階層にコピーするときに最適に機能します（そのため、宛先ファイルがすでに存在する場合、rsyncはリンク先ディレクトリを参照しません）。

これは、y/fileソースと同じz/fileで、古くなっている場合、

rsync -a --del -link-dest=y source:/file z

TWOのinode（二回ディスク容量）が使用されて、になりますy/fileし、z/file同じ内容と日付スタンプを持つことになります。

基本的にこのスクリプトを1日に1回実行して毎日のバックアップを行うため、これに遭遇しました。

mv $somedaysago $today; 
yest=$today; today=`date +%Y%m%d`;
rsync -avPShyH --del --link-dest=../$yest host:/dirs $today

バックアップは最大10Mファイルに及ぶため、実行に時間rm -rf $olddir; rsync source:$dir newdirがかかりすぎます（特に、1日あたりファイルの0.5％しか変更されない場合、50Kの新しいファイルまたは変更されたファイルを処理するためだけに10M dirエントリの削除と作成が発生します。バックアップは翌日の時間内に完了しません）。

ここに状況のデモがあります：

aわれわれの情報源は、ある1を通じて4私たちの番号付きバックアップは、次のとおりです。

$ mkdir -p 1 2; echo foo > 1/foobar; cp -lrv 1/* 2
`1/foobar' -> `2/foobar'
$ ls -i1 */foobar
1053003 1/foobar
1053003 2/foobar

$ mkdir a; echo quux > a/foobar
$ mv 1 3; rsync -avPhyH --del --link-dest=../2 a/ 3
sending incremental file list
./
foobar
           5 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/2)

sent 105 bytes  received 34 bytes  278.00 bytes/sec
total size is 5  speedup is 0.04

$ ls -i1 */foobar
1053003 2/foobar
1053007 3/foobar
1053006 a/foobar

$ mv 2 4; rsync -avPhyH --del --link-dest=../3 a/ 4
sending incremental file list
./
foobar
           5 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/2)

sent 105 bytes  received 34 bytes  278.00 bytes/sec
total size is 5  speedup is 0.04


$ ls -il1 */foobar
1053007 -rw-r--r-- 1 math math 5 Mar 30 00:57 3/foobar
1053008 -rw-r--r-- 1 math math 5 Mar 30 00:57 4/foobar
1053006 -rw-r--r-- 1 math math 5 Mar 30 00:57 a/foobar

$ md5sum [34a]/foobar
d3b07a382ec010c01889250fce66fb13  3/foobar
d3b07a382ec010c01889250fce66fb13  4/foobar
d3b07a382ec010c01889250fce66fb13  a/foobar

これa/foobarで、タイムスタンプを含むすべての点で同じである2つのバックアップがありますが、異なるiノードを占有しています。

ソリューションは--delete-before、増分スキャンのメリットを失うと考えられるかもしれませんが、ファイルは削除されず、増分コピーが可能な場合の基礎として使用されるため、これも役に立ちません。

さらに推測すると、でこのインクリメンタルコピーヘッジをオフにできます--whole-fileが、これはアルゴリズムには役立ちません。必要なものを取得する方法はありません。

私はこの動作をrsyncの別のバグと考えています。有益な動作は、さまざまなコマンド引数を注意深く選択することで解釈できますが、望ましい結果は得られません。

解決策は、残念ながら、アトミック操作としての単一のrsync -nからでのrsync --link-dest予行演習に移行し、それをログに記録し、そのログを入力として処理し、変更されたすべてのファイルを手動で事前削除してから、実行して必要なものを取得します-大きな問題単一のクリーンなrsyncと比較。

補遺：プロダクションボックスに対するバックアップの前に、バックアップサーバーで事前リンク$yesterdayを試みましたが、結果は同じですが、長さが0であっても、存在するファイルは削除されず、リンクが削除されず、全体が削除されます。新しいコピーはsourcedirから新しいiノードで作成され、より多くのディスク領域を使用します。$todayrsync --link-dest=../$yesterday $yesterday/ $today

見てみるpax(1)ことができ、プリリンク・ビフォア・バックアップソリューションとして。

_{（質問編集から変換）}

これは、rsyncをアップグレードすることで解決します。バージョン3.1.1以降では、ターゲットと--link-destディレクトリ内の同一のファイルが1つのハードリンクされたファイルに置き換えられます。多くのスペースを節約します。