バックアップからレプリカセットを復元すると、Cloud Manager は選択した復元ポイントの復元ファイルを提供します。 復元プロセスの詳細については、「復元の概要 」を参照してください。
Considerations
BinData BSON サブタイプへの変更を検討する
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スナップショットの取得時にデータベースで使用されたスタートアップオプション
バックアップに関する考慮事項
すべてのFCVデータベースは適切なバックアップに関する考慮事項を満たしている必要があります。
前提条件
手動復元を実行するには、Cloud Manager でバックアップ管理者ロールが必要です。
復元中のクライアントリクエスト
復元中に MongoDB 配置がクライアント リクエストを受信しないことを確認する必要があります。 次のいずれかを行う必要があります。
新しいホスト名を持つ新しいシステムに復元し、新しい配置が実行中以降にアプリケーション コードを再構成する。または、
データの復元中に MongoDB 配置がクライアント リクエストを受信しないことを確認します。
スナップショットの復元
機能の互換性バージョンと復元の種類を選択して、適切な手順を表示します。
重要
AES256-GCM で暗号化されたスナップショット復元後のマスター キー ローテーション
Cloud Manager が AES256-GCM を使用して暗号化したスナップショットを復元する場合は、復元の完了後にマスターキーをローテーションします 。