GFS保持ポリシーでは、保持数の設定から想定されるよりも多くの復元ポイントが削除されるのはなぜですか？
GFS保持ポリシーでは、保持数が独立したバックアップの単純な合計ではなく、期間の区分を示すため、予想より多くの復元ポイントが削除されることがあります。
keep-last、daily、weekly、monthly、yearlyなどのルールは通常、重複する期間から代表的な復元ポイントを選択します。1つのバックアップが複数の期間区分を満たす場合がある一方、タイムスタンプ、ソースグループ、ポリシーの継承、最近のポリシー変更などにより、別のバックアップがどの区分にも該当しないこともあります。一部のツールでは、定義された順序でルールを処理したり、すでに選択されたバックアップを後続の区分から除外したりします。pruneやcompactを実行する前に、正確なスケジュールをプレビューしてください。
すべての復元ポイントをポリシーグループとタイムスタンプ付きで一覧表示する
スナップショットまたはアーカイブのID、ソースホスト、パス、タグ、完了ステータス、現地時間、UTC時間、および各グループに適用されたポリシーをエクスポートします。すべてのリポジトリやソースをまとめて数えないでください。
Resticは、グループ化を変更しない限り、ホスト、パス、タグに基づいてスナップショットのグループに保持ポリシーを適用します。そのため、見た目がよく似た2つの復元ポイントでも、異なるポリシーに基づいて評価されることがあります。
予期しない削除が特定のホスト、パス、またはタググループにのみ影響している場合は、リポジトリ全体の保持設定を変更するのではなく、そのグループまたはセレクターを修正してください。
daily、weekly、monthlyの数を合計しない
各復元ポイントがどの期間を表すかを割り当てます。同じバックアップがdaily、weekly、monthlyの候補として選択されているかを確認します。
Proxmoxのpruneシミュレーターは、重複する保持区分を表示します
したがって、期待される合計は必ずしもkeep-daily + keep-weekly + keep-monthlyではありません。すべてのルール適用後に保持される、一意のバックアップIDを数えてください。 各期間内で、最新、最古、最初、または最後に成功したバックアップのどれが選択されるかを確認します。これを実際のジョブのバックアップ時刻と比較してください。 BorgはGFS形式のpruneルールについて説明しており、カレンダー境界の扱いが締め切り付近のアーカイブに影響する場合があるとしています。 深夜0時の直前と直後に実行されるジョブでは、現地時間では異なる日付に見える2つのバックアップが、タイムゾーンやスケジューラーによる変換後には1つのポリシー期間に収まることがあります。
グローバルなデフォルトだけを読むのではなく、実際に有効なポリシーをエクスポートします。ソースごとの上書き設定、継承された値、タグ、フォルダー、UIプリセットを確認してください。 Kopiaのポリシーコマンドは、ソースごとに継承された保持値をサポートしているため、別の場所に表示されるリポジトリレベルの設定と、実際に有効なルールが異なる場合があります。 ローカルのkeep値が0である場合や、継承境界が変更された場合、親ポリシーが正しく見えていても復元ポイントが削除されることがあります。解決済みのポリシーを監査記録とともに保存してください。 現在の保持値を以前のポリシーバージョンおよび最後のクリーンアップ時刻と比較します。古い復元ポイントがすぐに期限切れとしてマークされたかどうかを確認してください。 Microsoftは、保持期間の短縮が既存の復旧ポイントに影響するのは、将来のバックアップだけでなく、その後のクリーンアップジョブであると説明しています。 クリーンアップが遅れていると、多数の削除が一度に発生したように見えることがあります。ポリシー変更の記録と、別の実行を承認する前に削除対象としてマークされたポイントの一覧を保存してください。 weekly、monthly、yearlyのフラグが引き続き付いているか、また短期チェーンが選択されたポイントをサポートできるかを確認します。ソフトウェアのアップグレードやポリシー変換も確認してください。 Veeamは、GFS設定を変更すると、既存の候補からGFSステータスが失われる可能性があり、その後、通常の短期削除の対象になると警告しています。 復元ポイントの古いファイル名やフルバックアップとしての役割だけで、現在も長期保持されるとは限りません。有効なポリシーフラグを確認してください。 ポリシーの編集を凍結し、現在の復元ポイント一覧をエクスポートして、プラットフォームのdry-runまたはシミュレーターを実行します。その後、保持および削除されるIDを手動で確認したサンプルと比較してください。 大規模なスナップショット履歴に関するZimaSpaceの記事では、関連する復旧の背景を説明しています。この記事では、保持数の計算が単純なカウントと異なる理由に焦点を当てています。 シミュレーター、実効ポリシー、一意の保持IDが、少なくとも2つのカレンダー境界にわたって一致し、必要な復旧期間が削除対象としてマークされたポイントに依存していなければ、問題は解決しています。 必ずしもそうではありません。同じ復元ポイントが両方の期間を表す場合や、保持エンジンがすでにカバーされている候補を後続のルールから除外する場合があります。 はい。多くのシステムでは、将来のバックアップだけでなく、次回のクリーンアップ時に既存のポイントにも新しいポリシーを適用します。 ツールによって異なります。スナップショットやアーカイブをまずマークし、共有データの回収を別のcompactまたはガベージコレクションの処理で行うシステムもあります。ルールの順序と各期間で選択された候補を確認する
リポジトリ、ユーザー、ソースレベルで継承されたポリシーを確認する
最近のポリシー削減とクリーンアップのタイミングを確認する
GFSフラグ、短期保持、ポリシー変換を確認する
pruneとcompactの前にdry-runまたはシミュレーターを実行する
よくある質問
keep-dailyとkeep-weeklyの数は加算されますか？
保持期間を短縮すると、既存の復元ポイントを削除できますか？
pruneを実行すると、リポジトリの空き容量はすぐに増えますか？
おすすめ商品
サポートとヒント
もっと読む
Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか？
xattr のインベントリ、tar と Rsync のオプション、名前空間、保存先のサポート状況、権限、ラベル、アプリメタデータ、テストを網羅したボリューム復元の診断。
Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか？
ライブcgroup、再起動と再作成の違い、Composeのフィールド、ハードリミットとソフトリミット、親スコープ、スワップ、ランタイムヒープを網羅したメモリ制限の診断。
リバースプロキシを再起動すると、1つのセルフホストアプリですべてのセッションが無効になるのはなぜですか？
再起動の範囲、Cookieの所有権、シークレットのローテーション、キャッシュを利用したセッション、スティッキールーティング、認証ゲートウェイ、復旧を網羅したセッション喪失の診断。
