Ops Manager は、バックアップデータを S3バケットにブロックとして書き込み、Ops Managerアプリケーションデータベースでメタメタデータを追跡することで、スナップショットや oplog を含むバックアップを S3 または S3 と互換性のあるオブジェクトストアに保存できます。不変の S3 バックアップでは、Ops Manager は S3 Object lock または同等と統合され、次の機能を提供します。
バックアップデータとバックアップメタデータをS3バケットにまとめて保存します。
オブジェクトストアによって強制される、定義された保持期間が終了するまでバックアップオブジェクトを削除または変更から保護します。
障害復旧または移行のために、新しいまたは再構築された Ops Manager の配置に、完全なポイントインタイム復元チェーン、スナップショット、およびoplog をまとめて Object-Lock 対応バケットからインポートします。
この機能を使用して、ランサムウェア攻撃や演算子エラーなど、悪意のある削除または誤って削除からバックアップを保護します。S3 に保存しているもののみを使用して、新しい Ops Managerインスタンスにバックアップを復元できます。
このガイドでは、ホスト上で直接インストールおよび管理する3 Ops Manager 配置の不変の S バックアップについて説明します。 MongoDB Controls for Kubernetes Operator（MVK）を使用して Ops Manager を配置する場合は、 Ops Managerリソース仕様の例 を参照してください。
重要
Ops Manager は、バージョン 8.0.19 以降の不変の S3 スナップショットをサポートします。この保護を拡張して、完全に不変でインポート可能なバックアップからのポイントインタイム復元をサポートする 不変の S3 oplog には、バージョン 9.0 または 8.0.28 が必要です。
不変の S3 バックアップの仕組み
Object-Lock 対応バケットで S3読み取りを構成し、不変のバックアップを有効にすると、次の操作が実行されます。
Ops Manager は、Ops Managerアプリケーションデータベースのみにメタデータを保持するのではなく、スナップショット ブロックと復元に必要なメタデータを S3バケットに書込みます。
構成すると、Ops Manager はスナップショットごとに オブジェクト ロックの保持を延長し、バックアップジョブの保持ウィンドウが終了する前にオブジェクトストアによる削除または変更を防止します。
Ops Manager は、S3バケットに保存されているデータのみを読み取ることで、これらの不変のスナップショットを検出し、事前に入力されたバケットから別の Ops Managerインスタンスにインポートできます。
オブジェクト ロック を有効にして S3 oplogストアも構成する場合:
Ops Manager は、スナップショット データの場合と同じ方法で、 oplogスライスと復元に必要なメタデータを S3 oplogストアのバケットに書込みます。
MongoDB Agent は 、そのバックアップジョブ の過半数がコミットしたoplogエントリのみを追跡するため、Ops Manager は、後のロールバックによって削除される可能性のあるoplogエントリをバックアップすることはありません。
Ops Manager は、これらの不変の oplog とインポートされた不変のスナップショットを別の Ops Managerインスタンスに検出してインポートし、インポートされたバックアップからの ポイントインタイム復元 をサポートします。
前提条件
不変の S3 バックアップを使用するには、次の条件があることを確認してください。
不変スナップショットの場合は、Ops Manager 8.0.19 以降。不変の oplog にはさらにバージョン 9.0 または 8.0.28 が必要です。
Ops Manager で構成された S3読み取り（ブロックストア）。不変のスナップショットは S3 ベースのスナップショット ストアのみをサポートし、 MongoDBブロックストアやファイルシステム スナップショット ストアはサポートしません。
AWS S3 や互換性のあるアプライアンスなど、オブジェクト ロックをサポートし、ストアに使用するバケットでオブジェクト ロックが有効になっているオブジェクト ストア。ほとんどの S3 プロバイダーでは、オブジェクト ロックが機能するためにオブジェクト バージョン管理が必要であり、一部のプロバイダーではバケット作成時のみオブジェクト ロックが許可されます。
標準バックアップ要件。たとえば、適切なノードでバックアップが有効になっているMongoDB Agent や、PITR 用のoplog （操作ログ）ストアなどがあります。
読み取りに対して Object lock が有効になっている S3バケット。バケットは新しい必要はなく、このストア専用である必要はありませんが、専用のバケットが推奨されます。 Ops Manager で既存の S3 スナップショット ストアの構成に対してオブジェクト ロックを有効にするには、設定を変更します。オブジェクト ロックが有効になっているバケットをポイントする新しい S3読み取りを構成する必要があります。
不変の oplog を使用する場合: oplogストアに対してバージョン管理とオブジェクト ロックが有効になっている S3バケット。バケットは新しい必要はなく、このストア専用である必要はありませんが、専用のバケットが推奨されます。 Ops Manager で既存の S3 oplogストアの構成に対してオブジェクト ロックを有効にするには、設定を変更します。バージョン管理とオブジェクト ロックが有効になっているバケットをポイントする新しい S3 oplogストアを構成する必要があります。
Considerations
不変の S3 バックアップを計画する場合は、次の項目を考慮してください。
回帰の不変はありません。Ops Manager は、 不変のバックアップを有効にすると、バケットに書き込まれたスナップショットのみを オブジェクトロック で保護します。Ops Manager は既存のスナップショット オブジェクトにオブジェクト ロックを適用しません。
オブジェクト ロックの構成。Ops Manager は、オブジェクト ロックをサポートしていない S3 バケットに対して不変性を提供しません。バケットでオブジェクト ロックを個別に構成する必要があります。Ops Manager でオブジェクト ロック設定を構成するか、作成後にバケット設定を更新しても、バケットでオブジェクト ロックは有効になりません。
既存のデータの自動移行はありません。S3 ストア間のバックアップを移行する機能を使用すると、バックアップジョブが将来のスナップショットに使用する S3読み取りを変更できます。バケット間で既存のスナップショット データをコピーしたり移動したりすることはありません。
マネージド ストアの保持とオブジェクト ロック。バックアップジョブ保持ポリシーに従ってスナップショットが期限切れになると、Ops Manager はそのスナップショットの表示を停止し、関連するオブジェクトの削除を試みます。MongoDB Ops Manager は、オブジェクト ロック保持期間が終了した後にのみオブジェクトを削除できます。
インポートされたストアを保持します。 MongoDB Ops Manager は、インポート元の S3 バケットからデータを削除しません。 Ops Manager は、独自のアプリケーションデータベースにインポートされたメタデータを削除できます。保持は、Ops Manager でのメタデータの可視性のみに影響します。
遡及的なoplog の不変性はありません。オブジェクト ロックは、S3 oplogストアを作成するときにのみ有効にできます。設定を変更して、既存の S3 oplogストアでオブジェクト ロックを有効にすることはできません。代わりに新しいストアを作成する必要があります。
Oplog のバージョン固定はデフォルトでオフになっています。デフォルトでは 、Ops Manager3 は、不変のoplogストアからoplogスライスを読み取るときに記録された正確な S オブジェクトバージョンを使用しません。 アプリケーション設定のデフォルトは
brs.oplogStoreFallBackToLatestVersiontrueです。これにより、Ops Manager は記録されたバージョンではなく、オブジェクトの最新バージョンを常に取得します。 MongoDB Ops Manager が正確な記録バージョンを使用するように要求するには、グローバル管理者はbrs.oplogStoreFallBackToLatestVersionをfalseに設定する必要があります。oplog を追尾するための過半数がコミットするトポロジー要件。 Ops Manager は、Object-Lock が有効化されているoplogストアの過半数がコミットしたoplogエントリのみを追跡します。Object lock は Ops Manager がすでにストアに書き込まれたデータを元に戻したり変更したりすることはできないためです。セカンダリがダウンした PSAトポロジー、または PAAトポロジーでは、 oplog の追尾は過半数のコミットに達しないため、トポロジーが回復するまでテーリングは停止します。 MongoDB Ops Manager は、このような状況が発生した場合に原因と改善点を示すアラートを発生させます。
警告
Ops Manager は、スナップショット ストアまたはoplogストアのいずれについても、バケットの実際の保持モードまたは期間を読み取りません。 Ops Manager で設定した保持値が S3バケットで直接構成した保持設定と一致しない場合、バケットで保持が強制されると、バックアップが削除や変更に対して保護されない可能性があり、Ops Manager のクリーンアップ ジョブは失敗する可能性があります。 MongoDB Ops Manager は認識されていない
不変のスナップショット ストレージの構成
不変のスナップショットストレージを構成するには、次のタスクを実行します。
Ops Manager で不変のバックアップを有効にします。
Object-Lock 対応の S3バケットを準備します。
Ops Manager で新しい S3読み取りを構成します。
不変バックアップの有効化
アプリケーション設定は不変のバックアップを制御します。グローバル管理者は、Object lock を使用して S3読み取りを構成する前に、この設定を有効にする必要があります。
注意
管理UI を使用する代わりに、conf-mms.properties で brs.immutableBackupEnabled を true に設定することもできます。設定を両方の場所で設定すると、MongoDB Ops Manager は conf-mms.properties 値を使用します。
オブジェクトロックが有効化されている S3 バケットを準備する
（任意）バケットへの条件付き書込みを構成します。
Ops Manager は、デフォルトでバケットの条件書込みサポートを使用して、不変のスナップショットメタデータが使用するストレージ領域を削減します。条件付き書込みをサポートするようにバケットを構成します。
重要
条件付き書込みのサポートは必須ではありません。バケットが条件付き書込みをサポートしていない場合、Ops Manager は引き続き Object lock でスナップショットを保護しますが、バケットは予期しない速度で大きくなる可能性があります。
注意
Ops Manager では、既存の S3 スナップショット ストアの構成に対してオブジェクト ロックを有効にすることはできません。すでにバックアップに S3バケットを使用しているが不変のスナップショットが必要な場合は、プロバイダーが許可している場合はそのバケットで Object lock を有効にするか、Object lock がすでに有効になっている別のバケットに点、新しい S3 を構成します読み取り。
Ops Manager で新しい S3 スナップショット ストアを構成する
新しい S3読み取りを作成します。
「 S 互換スナップショット ストアを3 1 つ追加する 」の手順に従って、オブジェクト ロック対応バケットをポイントする新しい S3 読み取りを作成します。 S プロバイダーに必要なバケット名、エンドポイント、リージョン、認証情報を指定します。3
重要
新しい S3読み取りを作成する場合にのみ Object Lock Enabled を選択できます。ストアを保存した後、この設定を変更することはできません。 Object Retention Period (Days) と Object Retention Mode はいつでも変更できます。
この読み取りは、不変のスナップショットのターゲットとして機能します。Ops Manager は、この保存を使用するバックアップのスナップショット ブロックとメタデータの両方をバケットに書込みます。
注意
MongoDB Enterprise Kubernetes Operator を使用してMongoDB Ops Manager を管理する場合、対応するMongoDBOpsManager リソースのs3Stores エントリで、オブジェクト ロックも有効にする必要があります。spec.backup.s3Stores[].objectLockEnabled フィールドをtrue に設定します。それによりKubernetes 演算子 は、オブジェクト ロックを認識してMongoDB Ops Manager を調整します。
MongoDB Ops Manager 操作のメタデータストアとして機能するには、引き続きMongoDBインスタンスが必要です。
不変の oplog ストレージの構成
不変のoplogストレージを構成するには、次のタスクを実行します。
Ops Manager で不変のバックアップをまだ有効にしていない場合は、有効にします。
バージョン管理された、Object-Lock 対応の S3バケットを準備します。
Ops Manager で新しい S3 oplogストアを構成します。
既存のバックアップジョブを不変の S3 oplogストアに切り替えます。
不変バックアップの有効化
この手順では、 不変のスナップストレージと同じ Ops Managerアプリケーション設定を使用します。不変のスナップショットストレージの構成中に 不変のバックアップの有効化 をすでに完了している場合は、この手順をスキップします。
バージョン管理されたオブジェクトロック対応の S3 バケットを準備する
不変oplogストア用のバケットを準備します。
（任意）バケットへの条件付き書込みを構成します。
Ops Manager は、デフォルトでバケットの条件付き書込み (write) サポートを使用して、不変のバックアップメタデータが使用するストレージ領域を削減します。条件付き書込みをサポートするようにバケットを構成します。
重要
条件付き書込みのサポートは必須ではありません。バケットが条件付き書込みをサポートしていない場合、Ops Manager は引き続き Object lock を使用して oplog を保護しますが、バケットは予期しない速度で増加する可能性があります。
注意
Ops Manager では、既存の S3 oplogストアの構成に対してオブジェクト ロックを有効に できません 。すでにoplogストレージに S3バケットを使用しているが、不変の oplog が必要な場合は、プロバイダーが許可している場合はそのバケットでバージョン管理とオブジェクト ロックを有効にするか、両方がすでに有効になっている別のバケットを点、新しい S3 oplogストア。
Ops Manager で新しい S3 Oplog ストアを構成する
新しいバケットをS3 oplogストアとして設定します。
新しい S3 oplogストアを作成します。
3「 S 互換の3 Oplog ストアを 1 つ追加する 」の手順に従って、バージョン管理されたオブジェクトロック対応バケットをポイントする新しい S oplogストアを作成します。 S プロバイダーに必要なバケット名、エンドポイント、リージョン、認証情報を指定します。3
Object Retention Period (Days)を設定します。
Ops Manager が各oplogスライスのオブジェクトをオブジェクト ロックで保護する日数を入力します。この値は、バケットで直接構成した保持期間と一致する必要があります。このフィールドはS3バケット自体の保持設定は変更されず、Ops Manager はバケットの実際の保持期間の読み取りも検証も行われません。
重要
このフィールドはに設定することをお勧めします。これを空白のままにすると、MongoDB Ops Manager はバケットの保持期間が実際に期限切れになるときをレコードできません。 MongoDB Ops Manager は、独自のグルーミング ロジックでオブジェクトが適格と見なされるとすぐにオブジェクトを削除しようとしますが、S3 バケットは保持期間が終了するまでその削除を拒否します。 Ops Manager は、バケットが許可するまで削除を再試行します。
重要
新しい S3 oplogストアを作成するときにのみ Object Lock Enabled を選択できます。ストアを保存した後、この設定を変更することはできません。 Object Retention Period (Days) と Object Retention Mode はいつでも変更できます。
このoplogストアは、不変のoplogバックアップのターゲットとして機能します。 Ops Manager は、このストアを使用するバックアップのoplogスライスとメタデータの両方をバケットに書込みます。
既存のバックアップジョブを不変の S3 Oplog ストアに切り替える
既存のバックアップジョブを不変の S3 oplogストアに再割り当てするには、割り当てラベルを使用します。
不変の S3 oplogストアに ラベルを追加します。
「 1 つの既存の S 互換 Oplog33 ストアを編集 」の手順に従って、不変の S oplogストアにラベルを追加します。
重要
Ops Manager が再割り当て後に次のスナップショットを取得するまで、PIT 復元は使用できません。
不変を検証する
Ops Manager は、各スナップショットのデータと、それを保護する Object lockメタデータをS3バケットに自動的に書込みます。データを手動でエクスポートする必要はありません。次の手順を使用して、特定のスナップショットがオブジェクト ロックによって保護されていることを確認します。
S3 oplogストアでオブジェクト ロックが有効になっていることを確認するには、Oplog ストレージ ページに移動して、そのストアの 設定を確認します。
障害復旧のためのスナップショットのインポート
不変のスナップショットとバックアップメタデータを含む既存の S3バケットからデータを復元する必要がある場合は、それらのスナップショットを Ops Manager 配置にインポートできます。このワークフローは、Ops Manager を再構築した後のバックアップの復元など、障害復旧シナリオで使用します。
重要
インポートされたスナップショットは 1 回限りの復元操作でのみ使用されます。Ops Manager は、インポートされたスナップショットのライフサイクルを管理したり、アクティブなバックアップスケジュールに含めたりしません。
外部 S3バケットを選択または追加します。
既存のバケットを選択するか、Add S3 bucket を選択して新しいバケットを定義します。バケット名と S3 エンドポイントは、スナップショットの S3 ストアに構成されている値と一致する必要があります。
重要
フォームは、データストアAdd S3 bucket タイプやMongoDBホスト リストまたは URI など、1 つの S 3互換スナップショット ストアを追加する 手順と同じフィールドを要求します。これらのフィールドは、復元するMongoDBデプロイではなく、このバケット専用のメタデータストアを点必要があります。
インポートが完了すると、インポートされたスナップショットは、割り当てたプロジェクトの下の Continuous Backup ページに表示されます。 Ops Manager は、完全にインポートされたクラスターショットのみを表示します。
MongoDB Ops Manager は、インポート元の S3バケットからデータを削除したりグルームを作成したりしません。インポートされたスナップショット オブジェクトのライフサイクルはオブジェクトストレージレイヤーで制御します。 Ops Manager は、独自のアプリケーションデータベースにインポートされたメタデータを削除できます。
障害復旧のための Oplog のインポート
不変の oplog を含む既存の S3バケットからポイントインタイム復元データが必要な場合は、それらの oplog を Ops Manager 配置にインポートできます。対応するスナップショットを最初にインポートする必要があります。 Ops Manager は、インポートされたスナップショットがすでにインポートされているクラスターの oplog のみを検出できます。
重要
MongoDB Ops Manager がインポートしようとしたときに、バケットにリストされているメタデータファイルが欠落している場合、Ops Manager はそのファイルをスキップし、警告をログに記録し、インポートジョブを SUCCEEDED として報告します。これにより、復元可能な時間範囲に差が生じる可能性があり、その差でポイントインタイム復元を試みると、拒否として、後でのみ表示されるようになります。
oplog を含む S3バケットを選択または追加します。
Select an S3 bucket リストから既存のバケットを選択し、Next をクリックします。または、Add S3 bucket を選択して新しいバケットを登録し、次に Save をクリックしてバケットを登録して続行します。
重要
フォームは、データストア タイプやMongoDB Add S3 bucketURI など、1 つの S3 互換スナップショット ストアを追加する手順と同じフィールドを要求します。
また、Ops Manager がバケットを保存する前に、 MongoDB がS3 互換ストレージソリューションによって発生する問題をサポートしていないことを確認するチェックボックスを選択する必要があります。
インポートが完了すると、Ops Manager はその行に Manage Oplogsアクションを表示し、インポートされた oplog を表示または削除できます。
PITR との相互作用
PITR は、ベースライン スナップショットとoplogストアに保存されているoplogデータを組み合わせます。不変スナップショットは、ベースライン スナップショット コンポーネント のみ に影響します。
不変の S3 読み取りに切り替えても、PITR は既存のスナップショットとoplogデータを引き続き使用します。古いスナップショットは元のストアに残り、 oplogストアの構成は変更されません。
新しいストアで最初の完全な不変スナップショットが完了すると、PITR はそのスナップショットをベースラインとして使用し、構成されたoplogストアから oplog のテーリングを続行できます。
インポートされたスナップショットからの PITR は、対応する不変の oplog もインポートする場合にのみ使用できます。それ以外の場合、インポートされたスナップショットは、Ops Manager がスナップショットを作成した正確な点にのみ復元できます。
重要
完全に不変を保護するには、 Object-Lock 対応のoplogストア と Object-Lock 対応の読み取りを併用します。デフォルトでは 、Ops Manager はこのペアを強制しません。バックアップジョブでは、標準のoplogストアを持つ不変の読み取りを使用できますが、PITR はその組み合わせでも引き続き機能します。ペアリングを必要とするには、グローバル管理者は アプリケーション設定を有効にする必要があります。 MongoDB Ops Managermms.backup.enforceObjectLockOplogsOnObjectLockSnapshot はデフォルトでこの設定を無効にします。オブジェクトロック対応のoplogストアを作成するには、「 S3 互換の Oplog ストアを 1 つ追加する 」の手順に従います。
oplogストアでオブジェクト ロックを有効にすると、 MongoDB Agent はそのバックアップジョブ の過半数がコミットしたoplogエントリのみを追跡します。過半数がコミットされたエントリはロールバックされないため、この動作により、後でロールバックによって削除される可能性のあるoplogエントリを Ops Manager がバックアップするのを防止します。
障害シナリオとリカバリ
不変の S3 スナップショットでは、スナップショットストアを切り替えても、追加のデータ損失シナリオは発生しません。各スナップショットは 1 つのストアから復元されるため、復元ロジックには 1 つのスナップショットに対して複数のバケットのデータは必要ありません。
新しいストアの最初のスナップショットの前のクラッシュ
既存のすべてのスナップショットは元の S3 保存に残り、完全に復元可能です。
PITR は、最新の完了したスナップショットとoplogデータを対象に動作します。
新しいストアでの最初の完全なスナップショット中にクラッシュが発生
Ops Manager は、新しい保存先への進行中のスナップショットを失敗または不完全としてマークし、復元には使用されません。
元のストア内の最後の正常なスナップショットは、復元可能な最新のスナップショットのままになります。
Ops Manager とクラスターが回復すると、Ops Manager は次の スナップショットウィンドウで不変ストアに新しい完全なスナップショットをスケジュールします。
新しいストアの最初のスナップショットは常に完全なスナップショットであり、各スナップショットは単一のストアから復元されるため、復元ロジックは 1 つのスナップショットに複数の S3 バケットのデータを混在させることには依存しません。