mkdir test
echo "hi" > test/file1
tar -c -f archive.0.tar -g test.snar test
touch -a test/file1 # changes atime and ctime, doesn't change mtime
tar -c -f archive.1.tar -g test.snar test
tar -t -G -vv -f archive.1.tar # lists Y for file1
それでは、GNU tarはアクセス時間（atime）とメタデータ変更時間（ctime）だけが変更されてもファイル全体を再保存するのでしょうか？私にとって、これは多くのファイルが読み込まれますが変更されないと合理的に期待できるので、これは非常に非効率的に見えます。
ベストアンサー1
増分バックアップはgtar信頼できませんが、タイムスタンプを誤って処理した結果ではありません。
ユーザー領域で動作するすべてのバックアップツールは、たとえば内部ファイルシステム構造を調べることはできず、zfs send同じ方法でタイムスタンプを処理する必要があります。そうしないと、正しい増分バックアップを許可できません。
atimeファイルが変更されたかどうかではなく、ファイルを読み取ったというメッセージだけが表示されるため、バックアップとは関係ありません。mtime一見すると興味深いように思えるかもしれませんが、問題ではありません。これはmtime、ファイル値をユーザー空間プログラムによって任意の値に設定できるためです。ctimeこれは操作できない唯一のタイムスタンプなので、増分バックアップに重要な唯一のタイムスタンプです。
ctimeコンテンツやメタデータは操作または更新できないため、ctimeバックアップツールは更新されるたびにファイルの内容とファイルのメタデータを保持する必要がありますctime。
そのため、変更されていないように見えるファイルmtimeにもコンテンツが変更されている可能性があるため、バックアップに入れる必要があります。
最後に：GNU tarはあなたが要求した方法を実装しません。動作はハードコードされています。
starただし、増分バックアップを試みるために2004年に作成されたオプションを提供します-dumpmeta。starただし、このオプションの使用に関する明示的な警告があります。マニュアルページをご覧ください。
-dumpmeta 増分ダンプモードでスターの動作を変更します。 -dumpmetaが使用され、最後の増分ダンプ以降のファイルのinode変更時間（st_ctime）のみが更新された場合、starはファイルの内容ではなく、ファイルのメタデータ（uid、権限など）のみをアーカイブします。 -dumpmetaを使用すると、デルタダンプが小さくなりますが、2つのデルタ間で生成され、st_mtimeが以前の日付に設定されたファイル（tar抽出の結果など）は、内容全体と一緒に保持されません。そのため、-dumpmetaを使用すると不完全な増分ダンプが発生する可能性があるため、慎重に使用する必要があります。
star基本方式は1981年頃からufsdump使用された方式ufsrestoreで、2005年2月から使用された方式でありstar、これらのプログラムを利用して増分バックアップを復元するのに問題があったことは一度もなかった。