Linuxでtarを使用して増分バックアップの問題を解決する方法を探しています。
テープにバックアップする必要がある大規模データセット（約3TB）があります。これを行うには、LTO4デバイスでlinux tarコマンドとmt / mtxを使用しています。
バックアップは非常に遅いので（他の質問に言及する必要があるようです）、実稼働中に実行されないように増分バックアップを使用する以外に選択肢はありません。
デフォルトでは、次のように進みます。
完全なtarが生成されました：（レベル0）
tar --new-volume-script=changetape.sh \ --exclude=.zfs \ --listed-incremental=file.index \ --label=full_DS01 \ -cvf /dev/nst0 \ /mnt/storage/sharename >>filelisting.log 2>>errlisting.errlog毎日の増分tar：
mtx -f /dev/sg1 load X #(load correct tape) mt -f /dev/nst0 eod #(forward to end of data to write a new incremental tar) tar --exclude=.zfs \ --listed-incremental=file.index \ --label=incremental_DS01 \ -czvf /dev/nst0 \ /mnt/storage/sharename >>filelisting.log 2>>errlisting.errlogタール増加を繰り返します。 2と同じプロセスを使用するので、常にレベル0にリストされている増分を使用して毎回調整します。これは、最後の増分更新以降に変更されたファイルを常にバックアップすることを意味します。 （diffとは対照的に、常にフルアップデートと比較します）
質問：
数回の反復後に増分が失敗し始めます。つまり、バックアップは実行されますが、実際にはフルバックアップを実行するのにすべてのファイルが変更されたと思うようです。
これは他のデータセットで発生します。
この問題をどのように解決できますか？これがどのように可能ですか？すべてがうまくいくようですが、すべてのファイルが変更されたと思いますか？
明確にするために：
- データセットは読み取り専用のマウントポイントです。
- フォルダ構造はフルバックアップと同じです。
- 親フォルダ名は変更されませんでした。
この問題をどのように解決できますか？
ベストアンサー1
gtarの増分機能には概念的な問題があり、すべての場合に正しく機能しません。 2004年にstarの増分機能を確認しようとしたとき、gtarは非常に早く失敗し、まったくテストできませんでした。
スターの増分バックアップを試してみましたか？
Freebsdはzfsバックアップにstarを使用し、Freebsdはいくつかの古いカーネルのバグを修正したのでうまくいきます。
gtar増分バックアップにはいくつかの問題があります。
重要なより大きなメタデータは、バックアップアーカイブの内部ではなく、ベンダー固有の
gtarオプションを使用した結果として生成された別々のファイルにあります-g。システムが完全にクラッシュすると、ファイルが失われる可能性が高くなります（少なくとも最新バージョンでは）。ただし、バックアップとは別に、このファイルの存在は実際には問題になりません。実際の問題は、ファイルが名前変更を追跡できないことです。gtarのバックアップアーカイブには、名前が変更されたファイルに関する情報は含まれていません。 1つのトレースでのみ新しいアーカイブに言及されていませんが、現在のファイルシステムにあるファイル名が消えて削除されたという仮定を許可します。
最上位ディレクトリの名前が変更されると、gtarはすべてのコンテンツを含むディレクトリツリー全体を保持する必要があります。これはgtarデルタを巨大にし、回復操作中にターゲットファイルシステムを簡単にオーバーフローさせる可能性があります。
gtar には、増分ファイルの種類を変更するディレクトリではなく、ファイルに問題があります。
gtarは、ディレクトリ名の変更と古い名前の新しいディレクトリの作成を処理できません。
そのため、2004年9月にstar用に作成したgtarを使用して初期手動テストを実行することはできませんでした。
一方、Starは1981年にufsdump / ufsrestore用に開発されてから35年間正確であると評価された基本アルゴリズムを使用しています。 Starの増分バックアップは次のように機能します。
各完全または増分ダンプのタイムスタンプ、レベル、およびファイルシステムを簡単に記録するダンプ日付ファイルがあります。
各tarアーカイブには、バックアップ間ファイルシステムのすべての変更を追跡するために必要なすべてのメタデータが含まれています。変更されたすべてのファイルに加えて、starは変更されたすべてのディレクトリのファイル名のリストと関連するinode番号のリストも保持します。これにより、いつでも増分バックアップのすべてのファイルの削除とすべてのファイル名の変更を追跡できます。
starは、バックアップからファイルシステムを復元すると、ファイル名、バックアップされたファイルシステムの元のinode番号、および抽出されたファイルシステムで使用された新しいinode番号を含む抽出されたすべてのオブジェクトのエントリを含むデータベースを作成します。これにより、starは2つの増分間のすべての変更を追跡できます。
ファイルシステムの最上位レベルでディレクトリの名前を変更するときは、starはそのディレクトリの内容内の個々のファイルではなく、ルートディレクトリと名前が変更されたディレクトリとそのメタデータのみをバックアップできます。
Starは、Berliosファイルシステムで10年間毎日累積増分バックアップと復元（通常は1日に2〜10 GBのデータ変更）を実行するために使用されており、一度も失敗したことはありません。
gtarを使用してバックアップを開始する前に、まず同様のリカバリテストを実行することをお勧めします。
注：増分回復でGNU tarがどのように失敗するかを確認するスクリプトは次のとおりです。システム全体のバックアップにtarを使用できますか？