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