リテンション ポリシー#
概要#
バックアップの保持ポリシーは、データのバックアップコピーが時間の経過とともに処理される方法を管理するように設計された一連の戦略的ガイドラインです。このポリシーは、バックアップを保持する期間、アーカイブまたは削除する時期、および編成方法に関するルールとガイドラインの概要を示しています。明確に定義された保持ポリシーの実装は、データ保護を保証、ストレージ使用の最適化、およびコンプライアンス要件を満たすために重要です。
リテンションポリシーの主要コンポーネント#
これらのポリシーの主要コンポーネントを理解することは、データ保護、ストレージ効率、コンプライアンスのバランスを保つシステムを設計するために重要です。
リテンション期間#
Time-Based Retention このコンポーネントは、バックアップを固定期間30日、1年など、バックアップを保持する期間を指定します。時間ベースの保持は簡単で、特定の期間より古いバックアップが自動的に削除されます。
Quantity-Based Retention あるいは、保持ポリシーは、保持されたバックアップの数たとえば、最後の10バックアップなどに基づくことができます。この方法は、経過期間に関係なく、特定の数の最近のバックアップを維持するのに役立ちます。
バックアップの種類#
Full Backups :これらのバックアップはデータセット全体をキャプチャし、その包括的な性質により長く保持されることがよくあります。他の種類と比べて、フルバックアップには異なる保持ポリシーが適用される場合があります。
Incremental Backups インクリメンタル バックアップは、最後のバックアップ以降の変更をキャプチャします。これらのバックアップの保持ポリシーは、バックアップチェーンでのロールと他のバックアップへの依存関係を反映して、異なる場合があります。
クリーンアップルール#
Automated Cleanup 効果的な保持ポリシーには、事前定義されたルールに従って古いバックアップを特定および削除する自動クリーンアップメカニズムが含まれます。これにより、手動介入が削減され、不要なデータが保持されるリスクが最小限に抑えられます。
Archiving and Deletion クリーンアップルールでは、古いバックアップを削除前にアーカイブするか、直接削除するかを指定できます。アーカイブは、コンプライアンスまたはその他の目的で履歴データを維持するのに役立ちます。
リテンションポリシーの主な目的#
堅牢なリテンションポリシーの実装は、効果的なバックアップ管理の基礎であり、いくつかの重要な目的を含みます。
十分なデータ保護の確保#
Historical Recovery 保持ポリシーは、さまざまな時点からのリカバリーを促進するためにバックアップを保持する期間を定義します。これは、データの損失、破損、または誤った変更が発生した場合に、最近のバックアップからだけでなく、古いバックアップからデータを復旧するためにも重要です。
Recovery Flexibility さまざまな期間にわたってバックアップを保持することにより、最新のデータの復元、破損の問題への対処、または誤った操作の元に戻すなど、さまざまな種類のデータ復旧シナリオに対応できます。
ストレージ使用の最適化#
Efficient Storage Management 保持ポリシーは、貴重なストレージ領域を消費する古いバックアップの蓄積を防ぐのに役立ちます。これは、バックアップの数または保持期間に制限を設定することにより実現され、それによりストレージ使用率が最適化され、コストが効果的に管理されます。
Cost Control 古いバックアップのクリーンアップを自動化することにより、組織はストレージインフラストラクチャと関連するメンテナンスに関連する不必要な費用を回避できます。
コンプライアンスとレギュレーション#
Meeting Legal Requirements 多くの業界には、データ保持を管理する特定の規制があり、バックアップの最小保持期間を規定する場合があります。明確に定義された保持ポリシーにより、これらの規制要件が満たされることが保証され、組織が法的および業界標準に準拠し続けるのに役立ちます。
Audit Readiness 適切な保持ポリシーは、保持規制へのコンプライアンスを示す明確で編成されたバックアップ履歴を維持することにより、監査を容易にします。
最小限の冗長性の安全性#
グローバルまたはサーバーごとの構成で minimum_redundancy オプションを使用して、Postgresサーバーのバックアップの最小数を設定できます。デフォルトでは、このオプションは0に設定されています。
minimum_redundancy を0より大きい数値に設定すると、 Barmanは常に少なくともその数のバックアップがサーバー上で利用できるようにします。
この設定は、バックアップの誤った削除からの保護に役立ちます。
注釈
リテンションポリシーが最小冗長設定と競合しないことを確認します。 Barmanのログに関連するメッセージがないか定期的にチェックしてください。
リテンションポリシーの範囲#
Barman、2つの方法で保持ポリシーを定義できます。
バックアップの冗長性#
保持するバックアップの数を指定します。 Barmanは、最新のバックアップを指定された数まで保持します。このタイプのポリシーは、保持期間は考慮せず、バックアップ数に焦点を当てます。
たとえば、冗長性を3に設定すると、 Barmanは3つの最新のバックアップを保持し、古いものは破棄します。
リカバリーウィンドウ#
そのウィンドウ内の任意のポイントにリカバリーできるように、バックアップを保持する期間を指定します。間隔ウィンドウは常に現在の時刻に終了し、指定された期間逆方向にスパンします。 Barmanは、このウィンドウ内の任意の時点へのポイントインタイムリカバリーに必要なバックアップとアーカイブログを保持します。
たとえば、7日間の復旧ウィンドウを設定すると、 BarmanはバックアップとWALファイルを保持して、過去7日以内の任意のポイントにリカバリーできるようにします。これは、ウィンドウの外にある最初のバックアップは対応するWALで保持されますが、このバックアップとすべての古いWALより前のバックアップは時代遅れとしてマークされ、最終的に削除されることを意味します。
Keepコマンド#
keep コマンドを使用して、特定のバックアップをマークして、無期限に保持できます。これは、そのバックアップについて前述した保持ポリシーをオーバーライドします。 keep コマンドの詳細については、 keep を参照してください。
ユースケース#
ポイント インタイム リカバリー#
ベースバックアップとアーカイブされたWALファイルには、同じ保持ポリシーがあります。この設定により、Postgresサーバーからデータを最も古いバックアップの終了時間からの任意の時点に復旧できます。
業務効率とスペース管理#
特にリソースが制限されている環境では、古いバックアップを定期的に削除して、ストレージコストを節約し、ストレージ領域を効果的に管理しながら、特定の数の最近のバックアップを維持することができます。
長期アーカイブ#
コンプライアンスまたは履歴の目的で、通常の操作要件を超えて長期間バックアップを保持する必要がある場合があります。これは、データを特定の期間保持する必要がある規制業界で多くの場合必要です。
保持ポリシーが適用される方法#
Barmanのリテンションポリシーは、 barman cron によって実行されるBarmanのメンテナンスタスクによって自動的に適用されます。
構成と構文#
リテンションポリシーは、マルチサーバー環境での柔軟性を提供する retention_policy オプションを使用してグローバルまたはサーバーごとに構成されます。デフォルトでは、 retention_policy オプションの値が設定されていないため、保持は強制されません。
リテンションポリシーの構文は次のとおりです。
retention_policy = {REDUNDANCY value | RECOVERY WINDOW OF value {DAYS | WEEKS | MONTHS}}
値は0より大きい整数である必要があります。
バックアップ冗長性の場合、値はサーバーの最小冗長レベル以上である必要があります。
リカバリウィンドウの場合、値は逆の順序でサーバーの最小冗長レベルと少なくとも同じ高さである必要があります。
値が割り当てられていない場合、警告が生成されます。
重要
ブロックレベルのインクリメンタルバックアップは、親バックアップとルートバックアップに依存するため、リテンションポリシーでは考慮されません。ルートバックアップのみが保持期間を決定するために使用されます。
ブロックレベルのインクリメンタルバックアップのリテンションポリシー#
保持ポリシーが適用される場合
Barmanはルートバックアップに焦点を当てます。
ルートバックアップが
KEEP:FULLとしてマークされている場合、ルートバックアップが保持ポリシー内にあるかどうかに関係なく、関連するすべてのインクリメンタルバックアップはVALIDとしてマークされます。ルートバックアップが
KEEP:STANDALONEとしてマークされ、保持ポリシー内にある場合、関連するすべてのインクリメンタルバックアップはVALIDとしてマークされます。ただし、ルートバックアップが保持ポリシーの対象外である場合、関連するすべてのインクリメンタルバックアップはOBSOLETEとしてマークされます。ルートバックアップが
KEEPフラグでマークされていない場合、関連するすべてのインクリメンタルバックアップは同じラベルを継承します。たとえば、ルートバックアップがOBSOLETEとしてマークされている場合、関連するすべてのインクリメンタルバックアップもOBSOLETEとしてマークされます。
クラウドバックアップのリテンションポリシー#
クラウドバックアップには2つのシナリオがあります。
Barmanサーバーで snapshots backups を一元化されたバックアップおよびリカバリーマネージャーとして使用する。
クラウドオブジェクトストレージで cloud backups を使用して、 Barmanサーバーを使用せずにバックアップを管理します。
最初のシナリオでは、 Barmanは cron で説明しているように、メンテナンス操作と保持ポリシーの適用に cron を使用します。この場合、 snapshot バックアップは他の rsync または postgres バックアップと同じように扱われます。
2番目のシナリオでは、 Barmanサーバーが存在しないため、保持ポリシーを適用するためのメンテナンス操作用のcronがありません。代わりに、 barman-cloud-backup-delete を -r RETENTION_POLICY オプションとともに使用する必要があります barman-cloud-backup-delete を参照してください。これにより、指定された保持ポリシーを満たさないバックアップが削除されます。さらに、フックスクリプトまたはカスタムスクリプトを使用してこれらのコマンドをスケジュールして、クラウドバックアップのcronメンテナンスをシミュレートすることもできます。