スナップショットからクラスターを復元すると、Cloud Manager は選択した復元ポイントの復元ファイルを提供します。
復元プロセスの詳細については、「 復元の概要 」を参照してください。
Considerations
BinDataBSONサブタイプへの変更を確認する
BSON仕様 によってBSONバイナリ データ型（BinData）のデフォルトのサブタイプが 2 から 0 に変更されました。スナップショットに保存される一部のバイナリ データは、BinData サブタイプ 2 である場合があります。バックアップは、BinData サブタイプ 2 のスナップショット データを自動的に検出し、BinData サブタイプ 0 に変換します。アプリケーションコードで BinData サブタイプ 2 が想定されている場合は、アプリケーションコードを更新して BinData サブタイプ 0 で動作するようにする必要があります。
Tip
BSON仕様のメモは、この変更の具体的な内容を説明しています。
次で指定された設定を使用して復元します: restoreInfo.txt
バックアップ復元ファイルには、 restoreInfo.txtという名前のメタデータ ファイルが含まれています。 このファイルは、スナップショットの取得時にデータベースが使用したオプションをキャプチャします。 データベースは、復元した後、リストされているオプションで実行する必要があります。 このファイルには、次のものが含まれています。
groupName
ReplicaSetName
クラスター ID （該当する場合）
スナップショット タイムスタンプ（UTC のタイムスタンプ）
タイムスタンプの復元（UTC の BSON タイムスタンプとして）
最後に適用された oplog （UTC の BSON タイムスタンプとして）
MongoDB バージョン
ストレージ エンジンの種類
mongodスナップショットの取得時にデータベースで使用されたスタートアップオプション
エージェントがバランサーを停止できない場合のスナップショット
Cloud Manager は、バランサーが有効になっている間に取得されたクラスター スナップショットの横に警告を表示します。 このようなスナップショットから復元すると、データが失われる、または孤立するリスクがあります。 詳細については、「エージェントがバランサーを停止できない場合のスナップショット 」を参照してください。
バックアップに関する考慮事項
すべての FCVデータベースは、適切なバックアップに関する考慮事項を満たしている必要があります。
暗号化に関する考慮事項
復元中の MongoDB へのクライアントリクエストの無効化
復元中に MongoDB 配置がクライアント リクエストを受信しないことを確認する必要があります。 次のいずれかを行う必要があります。
新しいホスト名を持つ新しいシステムに復元し、新しい配置が実行中以降にアプリケーション コードを再構成する。または、
データの復元中に MongoDB 配置がクライアント リクエストを受信しないことを確認します。
スナップショットの復元
Cloud Manager がスナップショットを自動的に復元するようにするには、次の手順に従います。
MongoDB Cloud MongoDB Cloud ManagerManagerで、プロジェクトのGo {0 ページにGoします。Continuous Backup
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。
復元ポイントを選択します。
バックアップを復元するポイントを選択します。
復元タイプ説明アクションSnapshot
復元する既存のスナップショットを選択します。
Point In Time
選択した時間までのすべての操作を含むカスタム スナップショットを作成します（選択した時間は含みません）。 デフォルトでは、 oplogストアは 24 時間のデータを保存します。
たとえば、
12:00を選択した場合、復元の最後の操作は11:59:59またはそれ以前のバージョンになります。重要: FCV 4.0では、最新のバックアップ再同期の前の時間をカバーするPIT復元は実行できません。 再同期を引き起こす条件については、「バックアップの再同期 」を参照してください。 この注は FCV 4.2以降には適用されません。
DateとTimeを選択します。
Oplog Timestamp
入力されたoplogのタイムスタンプまでのすべての操作を含むカスタム スナップショットを作成します。 oplogタイムスタンプには次の 2 つのフィールドが含まれています。
Timestamp
UNIXエポック からの経過秒数におけるタイムスタンプ
Increment
その秒に適用される操作の順序を 32 ビット序数として表します。
oplog Timestamp と Increment を入力します。
レプリカセットで
local.oplog.rsに対してクエリを実行し、目的のタイムスタンプを見つけます。[Next] をクリックします。
を選択して、ファイルを別のクラスターに復元します。
[Choose Cluster to Restore to] をクリックします。
次のフィールドを入力します。
フィールドアクションProject
スナップショット を復元する プロジェクト を選択します。
Cluster to Restore to
スナップショットを復元するクラスターを選択します。
Cloud Manager は、ターゲットのシャーディングされたクラスターを管理する必要があります。
警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。 既存のクラスターのすべてのバックアップ データとスナップショットが保持されます。
[Restore] をクリックします。
Cloud Manager は、復元に必要なストレージ容量を UI で示します。
重要
AES256-GCM で暗号化されたスナップショット復元後のマスター キー ローテーション
Cloud Manager が AES256-GCM を使用して暗号化したスナップショットを復元する場合は、復元の完了後にマスターキーをローテーションします 。
手動復元プロセスでは、次のことを前提としています。
ターゲット ホストには、データがありません。
2 要素認証を有効にしていません。
警告
自動復元を実行できない場合にのみ、スナップショットを手動で復元します。 手動復元を使用する必要があると判断された場合は、 MongoDB サポート にお問い合わせください。 このセクションでは、手動復元手順のステージの概要について説明します。
手動復元プロセスには、MongoDB サポートの支援を受けて実行する次の高レベルのステージがあります。
レガシーの
mongoshell またはmongoshを使用して、各レプリカセットとコンフィギュレーションサーバー レプリカセット（CSRS）に接続します。（任意） 各レプリカセットと CSRS の構成ファイルを確認します。 復元プロセスが完了したら、保存された構成ファイルを使用して復元されたレプリカセットの構成を再構築できます。
完全な手動復元手順については、 MongoDB Server 4.2のドキュメントを参照してください。 MongoDB 4.4以降の配置については、対応するバージョンのマニュアルを参照してください。
Cloud Manager がスナップショットを自動的に復元するようにするには、次の手順に従います。
MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。
復元ポイントを選択します。
バックアップを復元するポイントを選択します。
復元タイプ説明アクションSnapshot
復元する既存のスナップショットを選択します。
Point In Time
スナップショットの復元時間目的として日付と時刻を選択できます。 デフォルトでは、 oplogストアは 24 時間のデータを保存します。
たとえば、
12:00を選択した場合、復元の最後の操作は11:59:59またはそれ以前のバージョンになります。重要:
FCV4.0またはそれ以前のバージョンを実行するシャーディングされたシャーディングされたクラスターを復元する場合は、 シャーディングされたシャーディングされたクラスターで PIT 復元を実行するためにクラスター チェックポイントを有効にする必要があります。日付と時刻を含むチェックポイントが利用できない場合、 Cloud Managerはchoose another point in time を要求します。重要:最新のバックアップ再同期の前の時間をカバーするPIT復元は実行できません。 再同期を引き起こす条件については、「バックアップの再同期 」を参照してください。
DateとTimeを選択します。
[Next] をクリックします。
またはそれ以前のバージョンを実行するシャーディングされたシャーディングされたクラスターを復元し、
FCV4.0 Point In Timeを選択した場合:選択した時間に最も近いCheckpointsのリストが表示されます。
ポイントインタイム復元を開始するには、以下の手順を実行します。
リストされているチェックポイントのいずれかを選択するか、
[ Choose another point in timeをクリックしてチェックポイントのリストを削除し、メニューから別の日付と時刻を選択します。
を選択して、ファイルを別のクラスターに復元します。
[Choose Cluster to Restore to] をクリックします。
次のフィールドを入力します。
フィールドアクションProject
スナップショット を復元する プロジェクト を選択します。
Cluster to Restore to
スナップショットを復元するクラスターを選択します。
Cloud Manager は、ターゲットのシャーディングされたクラスターを管理する必要があります。
警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。 既存のクラスターのすべてのバックアップ データとスナップショットが保持されます。
[Restore] をクリックします。
Cloud Manager は、コンソールで復元に必要なストレージ領域の量を示します。
重要
AES256-GCM で暗号化されたスナップショット復元後のマスター キー ローテーション
Cloud Manager が AES256-GCM を使用して暗号化したスナップショットを復元する場合は、復元の完了後にマスターキーをローテーションします 。
手動復元プロセスでは、次のことを前提としています。
ターゲット ホストには、データがありません。
2 要素認証を有効にしていません。
警告
自動復元を実行できない場合にのみ、スナップショットを手動で復元します。 手動復元を使用する必要があると判断された場合は、 MongoDB サポート にお問い合わせください。 このセクションでは、手動復元手順のステージの概要について説明します。
手動復元プロセスには、MongoDB サポートの支援を受けて実行する次の高レベルのステージがあります。
レガシーの
mongoshell またはmongoshを使用して、各レプリカセットとコンフィギュレーションサーバー レプリカセット（CSRS）に接続します。（任意） 各レプリカセットと CSRS の構成ファイルを確認します。 復元プロセスが完了したら、保存された構成ファイルを使用して復元されたレプリカセットの構成を再構築できます。
手動復元の完全な手順については、 MongoDB Server のドキュメント を参照してください。