スナップショットからレプリカセットを復元

MongoDB Cloud MongoDB Cloud ManagerManagerで、プロジェクトのGo {0 ページにGoします。Continuous Backup

1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

3. サイドバーの Continuous Backup をクリックします。

   [継続的なバックアップ ]ページが表示されます。

[Overview] タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

1. バックアップを復元するポイントを選択します。

   復元タイプ	説明	アクション
   Snapshot	保存されたスナップショットを 1 つ選択できます。	復元する既存のスナップショットを選択します。
   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に対してクエリを実行し、目的のタイムスタンプを見つけます。

2. [Next] をクリックします。

を選択して、ファイルを別のクラスターに復元します。

1. [Choose Cluster to Restore to] をクリックします。

2. 次のフィールドを入力します。

   フィールド	アクション
   Project	スナップショット を復元する プロジェクト を選択します。
   Cluster to Restore to	スナップショットを復元するクラスターを選択します。 Cloud Manager は、ターゲット レプリカセットを管理する必要があります。 警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。 既存のクラスターのすべてのバックアップ データとスナップショットが保持されます。

2. [Restore] をクリックします。

   Cloud Manager は、復元に必要なストレージ容量の量を示します。

[Restore] をクリックします。

MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

3. サイドバーの Continuous Backup をクリックします。

   [継続的なバックアップ ]ページが表示されます。

[Overview] タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

1. バックアップを復元するポイントを選択します。

   復元タイプ	説明	アクション
   Snapshot	保存されたスナップショットを 1 つ選択できます。	復元する既存のスナップショットを選択します。
   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に対してクエリを実行し、目的のタイムスタンプを見つけます。

2. [Next] をクリックします。

Downloadファイルを手動で復元するには、 をクリックします。

スナップショットのダウンロードを構成します。

1. 次のダウンロード オプションを設定します。

   Pull Restore Usage Limit	リンクを使用できる回数を選択します。 No Limitを選択した場合、リンクは有効期限が切れるまで再利用可能です。
   Restore Link Expiration (in hours)	リンクの有効期限が切れるまでの時間数を選択します。 デフォルト値は1です。 最大値は、選択したスナップショットの有効期限が切れるまでの時間数です。

2. [Finalize Request] をクリックします。

3. 2 FAを使用する場合、Cloud Manager は2 FA コードの入力を要求します。 2 FA コードを入力し、 Finalize Requestをクリックします。

MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

3. サイドバーの Continuous Backup をクリックします。

   [継続的なバックアップ ]ページが表示されます。

Retrieve the Snapshots.

Cloud Manager はスナップショットへのリンクを作成します。 デフォルトでは、これらのリンクは 1 時間利用でき、使用できるのは 1 回だけです。

スナップショットをダウンロードするには:

1. [Restore History] をクリックします。

2. 復元ジョブが完了したら、表示されるレプリカセットごとに [ (get link) ] をクリックします。

3. クリック:

   • 後で使用するためにリンクをコピーするための、リンクの右側のコピーボタン、または

   • Download スナップショットをすぐにダウンロードする

ターゲット レプリカセットの管理を解除します。

データの手動復元を試みる前に、オートメーションからレプリカセットを削除します。

Unmanage this item in Ops Managers but continue to monitorオプションを選択します。

ターゲット レプリカセットを停止します。

パスによっては、 mongoshへのパスを指定する必要がある場合があります。 実行:

mongosh --port <port> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

ターゲット レプリカセットでハードウェアとソフトウェアの要件を確認します。

詳細については、「インストール 」を参照してください。

スナップショット データファイルをターゲット ホストに移動します。

スナップショットのデータファイルをターゲット ホストに移動する前に、ターゲット ホストに既存のファイルが含まれているかどうかを確認し、 automation-mongod.confファイルを除くすべてのファイルを削除します。

スナップショット ファイルを解凍し、ターゲット ホストに移動するには、次のようにします。

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> </path/to/datafiles>

エフェメラル ポートで一時スタンドアロン インスタンスを起動します。

一時的な測定値として、 mongodプロセスをスタンドアロン モードで開始します。 これにより、後続のステップでsystem.replsetコレクションに新しい構成パラメータを追加できるようになります。

この手順のすべてのステップで、一時的なスタンドアロンのmongodプロセスに<ephemeralPort>を使用します。 このポートは、ソースおよびターゲットのホスト ポートとは異なる必要があります。

次のようにmongodプロセスを実行します。 パスによっては、 mongodバイナリへのパスを指定する必要がある場合があります。

mongod  --dbpath </path/to/datafiles> \
        --port <ephemeralPort> \

名前空間でフィルタリングされたスナップショットから復元する場合は、 --restoreオプションを使用します。

mongod --dbpath </path/to/datafiles> \
       --port <ephemeralPort> \
       --restore

mongodプロセスが接続を受け入れ始めたら、続行します。

を使用して一時スタンドアロンmongosh インスタンスに接続します。

このmongodプロセスを実行しているホストから、 mongoshを開始します。 パスによっては、 mongoshへのパスを指定する必要がある場合があります。

前のステップで指定された同じ<ephemeralPort> でローカルホストをリッスンしているmongodに接続するには、次のコマンドを実行します。

mongosh  --port <ephemeralPort>

mongoshがmongodに接続した後、続行します。

レプリカセット関連のコレクションをlocal データベースから削除する。

手動復元を実行するには、Cloud Manager でバックアップ管理者ロールが必要です。

次のコマンドを実行して、以前のレプリカセット構成とその他の oplog 以外のレプリケーション関連のコレクションを削除します。

db.getSiblingDB("local").replset.minvalid.drop()
db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop()
db.getSiblingDB("local").replset.election.drop()
db.getSiblingDB("local").system.replset.remove({})

成功した応答は次のようになります。

> db.getSiblingDB("local").replset.minvalid.drop()
true
> db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop()
true
> db.getSiblingDB("local").replset.election.drop()
true
> db.getSiblingDB("local").system.replset.remove({})
WriteResult({ "nRemoved" : 1 })

新しいレプリカセット構成の追加。

次のドキュメントをlocalデータベースのsystem.replsetコレクションに挿入します。 次の変数を変更します。

• <replaceMeWithTheReplicaSetName> に、レプリカセットの名前を設定します。 この名前は古い名前と同じである必要はありません。

• <host> このレプリカセット ノードを提供するホストに渡す追加オプション。

• <ephemeralPortNewReplicaSet> 使用して、新しいレプリカセットのエフェメラル ポートに接続します。 これは、この手順のステップ11で指定した<ephemeralPort>とは異なるポートである必要があります。

1
db.getSiblingDB("local").system.replset.insertOne({
2
  "_id" : "<replaceMeWithTheReplicaSetName>",
3
  "version" : NumberInt(1),
4
  "protocolVersion" : NumberInt(1),
5
  "members" : [
6
    {
7
      "_id" : NumberInt(0),
8
      "host" : "<host>:<ephemeralPortNewReplicaSet>"
9
    }
10
  ],
11
  "settings" : {
12
13
  }
14
})

成功した応答は次のようになります。

{ "acknowledged" : true, "insertedId" : "<yourReplicaSetName>" }

最小有効タイムスタンプを挿入します。

次のコマンドを発行します:

db.getSiblingDB("local").replset.minvalid.insertOne({
  "_id" : ObjectId(),
  "t" : NumberLong(-1),
  "ts" : Timestamp(0,1)
})

成功した応答は次のようになります。

{ "acknowledged" : true, "insertedId" : ObjectId("<yourObjectId>") }

復元ポイントを からRestore Timestamp restoreInfo.txtの値に設定します。

restoreInfo.txtファイルのRestore Timestampフィールドに指定されている値にoplogTruncateAfterPointドキュメントを設定します。

そのファイルのRestore Timestampフィールドには 2 つの値が含まれています。 次の例では、最初の値は タイムスタンプ で、2 番目の値は増分です。

1
...
2
Restore timestamp:  (1609947369, 2)
3
Last Oplog Applied: Wed Jan 06 15:36:09 GMT 2021 (1609947369, 1)
4
MongoDB Version: 4.2.11
5
...

次のサンプル コードでは、前の例のタイムスタンプ値と増分値を使用します。

truncateAfterPoint = Timestamp(1609947369,2)
db.getSiblingDB("local").replset.oplogTruncateAfterPoint.insertOne({
   "_id": "oplogTruncateAfterPoint",
   "oplogTruncateAfterPoint": truncateAfterPoint
})

成功した応答は次のようになります。

WriteResult({ "nInserted" : 1 })

一時スタンドアロン インスタンスを停止します。

パスによっては、 mongoshへのパスを指定する必要がある場合があります。 実行:

mongosh --port <ephemeralPort> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

oplog を回復するには、 インスタンスを再起動します。

次のコマンドを使用してmongodを起動し、これらのパラメータを指定します。

• <bind_ip> この手順のステップ14で指定した、このレプリカセット ノードを提供するホストに接続します。

• <port> に、この手順のステップ<ephemeralPort> で指定した11 を設定します。

mongodは oplog をRestore timestampまで再生します。

mongod  --dbpath </path/to/datafiles> \
        --port <ephemeralPort> \
        --bind_ip <host-serving-this-replica-set-member> \
        --replSet <replaceMeWithTheReplicaSetName>

エフェメラル ポートの一時インスタンスを停止します。

パスによっては、 mongoshへのパスを指定する必要がある場合があります。 実行:

mongosh --port <ephemeralPort> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

（ポイントインタイム復元のみ） MongoDB バックアップ復元ユーティリティを実行します。

この手順は任意です。 ポイントインタイム復元が必要な場合は、それを実行します。 この手順が必要な場合は、それを完了してから、ステップ21と22を実行します。 この手順が必要ない場合は、ステップ23に進みます。 この手順では、レプリカセットのターゲット インスタンスで MongoDB バックアップ復元ユーティリティをダウンロードして実行し、 インスタンスを停止します。

1. MongoDB バックアップ復元ユーティリティをホストにダウンロードします。

   復元パネルを閉じた場合は、 Continuous Backup in Deployment 、 More 、 Download MongoDB Backup Restore Utilityの順にクリックします。

2. 抽出したスナップショット ディレクトリをデータディレクトリとして使用し、認証を有効にせずにmongodインスタンスを起動します。 パスによっては、 mongodバイナリへのパスを指定する必要がある場合があります。

   mongod  --port <ephemeralPort> \
           --dbpath </path/to/datafiles> \
           --setParameter ttlMonitorEnabled=false

   警告

   MongoDB バックアップ復元ユーティリティは認証をサポートしていないため、認証を使用してこの一時データベースを起動することはできません。

3. ターゲット ホストで MongoDB バックアップ復元ユーティリティを実行します。 レプリカセットに対してそれを 1 回実行します。

   重要

   事前構成された mongodb-backup-restore-tools コマンド

   Cloud Manager は、mongodb-backup-restore-util の下の復元パネルで、復元に適切なオプションを含むRun Binary with PIT Options を提供します。

   Cloud Manager に提供されるmongodb-backup-restore-utilコマンドをコピーする必要があります。

   ./mongodb-backup-restore-util --https --host <targetHost> \
      --port <targetPort> \
      --opStart <opLogStartTimeStamp> \
      --opEnd <opLogEndTimeStamp> \
      --logFile <logPath> \
      --apiKey <apiKey> \
      --groupId <groupId> \
      --rsId <rsId> \
      --accessList <database1.collection1, database2, etc.> \
      --denyList <database1.collection1, database2, etc.> \
      --seedReplSetMember \
      --oplogSizeMB <size> \
      --seedTargetPort <port> \
      --ssl \
      --sslCAFile </path/to/ca.pem> \
      --sslPEMKeyFile </path/to/pemkey.pem>
      --sslClientCertificateSubject <distinguishedName> \
      --sslRequireValidServerCertificates <true|false> \
      --sslServerClientCertificate </path/to/client.pem> \
      --sslServerClientCertificatePassword <password> \
      --sslRequireValidMMSBackupServerCertificate <true|false> \
      --sslTrustedMMSBackupServerCertificate </path/to/mms-certs.pem> \
      --httpProxy <proxyURL>

   mongodb-backup-restore-utilコマンドは、次のオプションを使用します。

   オプション	必要性	説明
   --host	必須	oplog を適用する mongod を提供するホストのホスト名、 FQDN 、 IPv4 アドレス、または IPv6 アドレスを指定します。Cloud Manager で提供されるmongodb-backup-restore-utilコマンドをコピーした場合、このフィールドは事前構成されています。
   --port	必須	mongodoplog を適用する を提供するホストのポートを指定します。
   --opStart	必須	復元に含める最初の oplog エントリの BSON タイムスタンプ を指定します。この情報は、ダウンロードされたスナップショットを含む restoreInfo.txt ファイルの「Last oplog Applied」エントリに表示されます。 この値は--opEnd値以下である必要があります。
   --opEnd	必須	復元に含める最後の oplog エントリの BSON タイムスタンプ を指定します。 この値は、oplog の終了よりも大きくすることはできません。
   --logFile	任意	MBRUログが書き込まれるファイル名を含むパスを指定します。
   --oplogSourceAddr	必須	Cloud Manager リソース エンドポイントへのURLを指定します。
   --apiKey	必須	Cloud Manager エージェントAPI キーを提供します。
   --groupId	必須	グループID を指定します。
   --rsId	必須	レプリカセットID を指定します。
   --accessList	任意	復元を制限するデータベースやコレクションのリストを指定します。
   --denyList	任意	復元対象から除外するデータベースやコレクションのリストを提供します。
   --seedReplSetMember	任意	oplogコレクションを再作成し、正しいタイムスタンプでシードするためにレプリカセット ノードが必要な場合は、 を使用します。 --oplogSizeMBと--seedTargetPortが必要です。
   --oplogSizeMB	条件付き	oplogサイズを MB 単位で指定します。 --seedReplSetMemberが設定されている場合は必須です。
   --seedTargetPort	条件付き	レプリカセットのプライマリのポートを指定します。これは、使用されるエフェメラル ポートとは異なる場合があります。 --seedReplSetMemberが設定されている場合は必須です。
   --ssl	条件付き	oplog を に適用するために TLSmongod / SSL が必要な場合は、 を使用します。 --sslCAFileと--sslPEMKeyFileが必要です。
   --sslCAFile	条件付き	証明機関ファイルへのパスを指定します。 --sslが設定されている場合は必須です。
   --sslPEMKeyFile	条件付き	PEM証明書ファイルへのパスを指定します。 --sslが設定されている場合は必須です。
   --sslPEMKeyFilePwd	条件付き	--sslPEMKeyFileで指定されたPEM証明書ファイルのパスワードを入力します。 --sslが設定され、かつPEMキー ファイルが暗号化されている場合は必須です。
   --sslClientCertificateSubject		ターゲット MongoDB プロセスのクライアント証明書サブジェクトまたは識別名（DN）を指定します。
   --sslRequireValidServerCertificates	任意	ターゲット MongoDB プロセスが提示する証明書をツールが検証する必要があるかどうかを示すフラグを設定します。
   --sslServerClientCertificate	任意	Cloud Manager ホストへの接続に使用するクライアント証明書ファイルへの絶対パスを指定します。
   --sslServerClientCertificatePassword	条件付き	Cloud Manager ホストへの接続に使用するクライアント証明書ファイル パスワードへの絶対パスを指定します。 --sslServerClientCertificateが設定され、その証明書が暗号化されている場合は必須です。
   --sslRequireValidMMSBackupServerCertificate	任意	Cloud Manager ホストに接続するときに有効な証明書が必要かどうかを示すフラグを設定します。 デフォルト値はtrueです。
   --sslTrustedMMSBackupServerCertificate	任意	Cloud Manager ホストのPEM形式で、信頼できる証明機関証明書への絶対パスを指定します。 このフラグが提供されない場合は、システムの認証局が使用されます。
   --httpProxy	任意	ツールが使用できる HTTP プロキシ サーバーの URL を指定します。

   は、Cloud Manager に提供されるmongodb-backup-restore-utilコマンドをコピーした場合、このフィールドが事前構成されているということを意味します。

4. インスタンスでmongodを停止します。 パスによっては、 mongoshへのパスを指定する必要がある場合があります。 実行:

   mongosh --port <ephemeralPort> \
         --eval "db.getSiblingDB('admin').shutdownServer()"

（ポイントインタイム復元のみ） oplog を回復するには、 インスタンスを再起動します。

この手順は、ステップ20を実行した場合にのみ必要です。 ステップ20を実行する必要がなかった場合は、ステップ23に進みます。 次のコマンドを使用してmongodを起動します。 mongodは oplog をRestore timestampまで再生します。 パスによっては、 mongodバイナリへのパスを指定する必要がある場合があります。

mongod  --dbpath </path/to/datafiles> \
        --port <ephemeralPort> \
        --replSet <replaceMeWithTheReplicaSetName>

この手順を完了すると、実際の復元プロセスが完了します。 次の手順では、レプリカセットの構成を復元し、再インポートします。

（ポイントインタイム復元のみ） エフェメラル ポートで インスタンスを停止します。

この手順は、ステップ20を実行した場合にのみ必要です。 ステップ20を実行する必要がなかった場合は、ステップ23に進みます。

パスによっては、 mongoshへのパスを指定する必要がある場合があります。 実行:

mongosh--port <ephemeralPort> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

レプリカセットをスタンドアロン インスタンスとして再起動します。

次のコマンドを使用して、 mongodプロセスをスタンドアロン インスタンスとして開始します。 <port>には、レプリカセット内のこのノードが実行される実際のポートを使用します。 パスによっては、 mongodバイナリへのパスを指定する必要がある場合があります。

mongod  --dbpath </path/to/datafiles> \
        --port <port>

mongodプロセスが接続を受け入れ始めたら、続行します。

一時レプリカセット構成を削除します。

次のコマンドを実行します:

mongosh --port <port> \
      --eval db.getSiblingDB("local").system.replset.remove({})

スタンドアロン インスタンスを停止します。

パスによっては、 mongoshへのパスを指定する必要がある場合があります。 実行:

mongosh --port <port> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

レプリカセット内の各ノードに対してステップ10から25を繰り返します。

レプリカセット内のすべてのノードを再起動します。

この時点で、レプリカセット内のデータファイルは一貫した状態ですが、各ノードが相互を認識できるようにレプリカセットの構成を更新する必要があります。

次のコマンドを実行します:

sudo -u mongod <path/to/target_mongod_binary> -f /path/to/datafiles/automation-mongod.conf

次の例では、バージョン4.4.12のすべてのノードを再起動します。 データ パス/data6/node3を持つエンタープライズ :

sudo -u mongod /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-4.4.12-ent/bin/mongod -f /data6/node3/automation-mongod.conf

レプリカセットの構成を設定します。

ノードの 1 つにログインし、次のコマンドを実行します。

rs.initiate()
rs.add( { host: "<host2>:<port>" } )
rs.add( { host: "<host3>:<port>" } )

MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

3. Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。

   配置ページが表示されます。

レプリカセットを再インポートします。

オートメーションでレプリカセットを再度管理するには、レプリカセットを Cloud Manager に再度インポートします。

[ Addをクリックし、 Existing MongoDB Deploymentを選択して、クラスターへのAutomationの追加に進みます。

MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

3. サイドバーの Continuous Backup をクリックします。

   [継続的なバックアップ ]ページが表示されます。

[Overview] タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

1. バックアップを復元するポイントを選択します。

   復元タイプ	説明	アクション
   Snapshot	保存されたスナップショットを 1 つ選択できます。	復元する既存のスナップショットを選択します。
   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に対してクエリを実行し、目的のタイムスタンプを見つけます。

2. [Next] をクリックします。

最新のoplogエントリを見つけるには、 mongoshで次のクエリを実行します。

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()

成功した結果は次のようになります。

{
  "ts": Timestamp(1537559320, 1),
  "h": NumberLong("-2447431566377702740"),
  "v": 2,
  "op": "n",
  "ns": "",
  "wall": ISODate("2018-09-21T19:48:40.708Z"),
  "o": {
    "msg": "initiating set"
  }
}

ts値の部分は、Timestamp ボックスとIncrement ボックスに必要な値に対応します。

を選択して、ファイルを別のクラスターに復元します。

1. [Choose Cluster to Restore to] をクリックします。

2. 次のフィールドを入力します。

   フィールド	アクション
   Project	スナップショット を復元する プロジェクト を選択します。
   Cluster to Restore to	スナップショットを復元するクラスターを選択します。 Cloud Manager は、ターゲット レプリカセットを管理する必要があります。 警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。 既存のクラスターのすべてのバックアップ データとスナップショットが保持されます。

2. [Restore] をクリックします。

   Cloud Manager は、復元に必要なストレージ容量の量を示します。

[Restore] をクリックします。

MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

3. サイドバーの Continuous Backup をクリックします。

   [継続的なバックアップ ]ページが表示されます。

[Overview] タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

1. バックアップを復元するポイントを選択します。

   復元タイプ	説明	アクション
   Snapshot	保存されたスナップショットを 1 つ選択できます。	復元する既存のスナップショットを選択します。
   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に対してクエリを実行し、目的のタイムスタンプを見つけます。

2. [Next] をクリックします。

最新のoplogエントリを見つけるには、 mongoshで次のクエリを実行します。

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()

成功した結果は次のようになります。

{
  "ts": Timestamp(1537559320, 1),
  "h": NumberLong("-2447431566377702740"),
  "v": 2,
  "op": "n",
  "ns": "",
  "wall": ISODate("2018-09-21T19:48:40.708Z"),
  "o": {
    "msg": "initiating set"
  }
}

ts値の部分は、Timestamp ボックスとIncrement ボックスに必要な値に対応します。

Downloadファイルを手動で復元するには、 をクリックします。

スナップショットのダウンロードを構成します。

1. 次のダウンロード オプションを設定します。

   Pull Restore Usage Limit	リンクを使用できる回数を選択します。 No Limitを選択した場合、リンクは有効期限が切れるまで再利用可能です。
   Restore Link Expiration (in hours)	リンクの有効期限が切れるまでの時間数を選択します。 デフォルト値は1です。 最大値は、選択したスナップショットの有効期限が切れるまでの時間数です。

2. [Finalize Request] をクリックします。

3. 2 FAを使用する場合、Cloud Manager は2 FA コードの入力を要求します。 2 FA コードを入力し、 Finalize Requestをクリックします。

MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

3. サイドバーの Continuous Backup をクリックします。

   [継続的なバックアップ ]ページが表示されます。

Retrieve the snapshots.

Cloud Manager はスナップショットへのリンクを作成します。 デフォルトでは、これらのリンクは 1 時間利用可能で、使用は 1 回だけです。

スナップショットをダウンロードするには:

1. [Restore History] をクリックします。

2. 復元ジョブが完了したら、表示される各レプリカセットの [ (get link) ] をクリックします。

3. クリック:

   • 後で使用するためにリンクをコピーするための、リンクの右側のコピーボタン、または

   • Download スナップショットをすぐにダウンロードする

スナップショット データファイルを宛先ホストに復元します。

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> <temp-database-path>

MongoDB バックアップ復元ユーティリティ（ポイントインタイム復元のみ）を実行します。

1. MongoDB バックアップ復元ユーティリティをホストにダウンロードします。

   注意

   復元パネルを閉じた場合:

   1. MongoDB Cloud Managerで、プロジェクトの Continuous Backup ページにGoします。

      1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

      2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

      3. サイドバーの Continuous Backup をクリックします。

      [継続的なバックアップ ]ページが表示されます。

   2. MoreDownload MongoDB Backup Restore Utilityをクリックし、 をクリックします。

2. 抽出したスナップショット ディレクトリをデータディレクトリとして使用し、認証を有効にせずにmongodインスタンスを起動します。

   例

   mongod --port <port number> \
     --dbpath <temp-database-path> \
     --setParameter ttlMonitorEnabled=false

   警告

   MongoDB バックアップ復元ユーティリティは認証をサポートしていないため、認証を使用してこの一時データベースを起動することはできません。

3. 宛先ホストで MongoDB バックアップ復元ユーティリティを実行します。 レプリカセットに対してそれを 1 回実行します。

   重要

   事前構成された mongodb-backup-restore-tools コマンド

   Cloud Manager は、mongodb-backup-restore-util の下の復元パネルで、復元に適切なオプションを含むRun Binary with PIT Options を提供します。

   Cloud Manager に提供されるmongodb-backup-restore-utilコマンドをコピーする必要があります。

   ./mongodb-backup-restore-util --https --host <targetHost> \
      --port <targetPort> \
      --opStart <opLogStartTimeStamp> \
      --opEnd <opLogEndTimeStamp> \
      --logFile <logPath> \
      --apiKey <apiKey> \
      --groupId <groupId> \
      --rsId <rsId> \
      --accessList <database1.collection1, database2, etc.> \
      --denyList <database1.collection1, database2, etc.> \
      --seedReplSetMember \
      --oplogSizeMB <size> \
      --seedTargetPort <port> \
      --ssl \
      --sslCAFile </path/to/ca.pem> \
      --sslPEMKeyFile </path/to/pemkey.pem>
      --sslClientCertificateSubject <distinguishedName> \
      --sslRequireValidServerCertificates <true|false> \
      --sslServerClientCertificate </path/to/client.pem> \
      --sslServerClientCertificatePassword <password> \
      --sslRequireValidMMSBackupServerCertificate <true|false> \
      --sslTrustedMMSBackupServerCertificate </path/to/mms-certs.pem> \
      --httpProxy <proxyURL>

   mongodb-backup-restore-utilコマンドは、次のオプションを使用します。

   オプション	必要性	説明
   --host	必須	oplog を適用する mongod を提供するホストのホスト名、 FQDN 、 IPv4 アドレス、または IPv6 アドレスを指定します。Cloud Manager で提供されるmongodb-backup-restore-utilコマンドをコピーした場合、このフィールドは事前構成されています。
   --port	必須	mongodoplog を適用する を提供するホストのポートを指定します。
   --opStart	必須	復元に含める最初の oplog エントリの BSON タイムスタンプ を指定します。この情報は、ダウンロードされたスナップショットを含む restoreInfo.txt ファイルの「Last oplog Applied」エントリに表示されます。 この値は--opEnd値以下である必要があります。
   --opEnd	必須	復元に含める最後の oplog エントリの BSON タイムスタンプ を指定します。 この値は、oplog の終了よりも大きくすることはできません。
   --logFile	任意	MBRUログが書き込まれるファイル名を含むパスを指定します。
   --oplogSourceAddr	必須	Cloud Manager リソース エンドポイントへのURLを指定します。
   --apiKey	必須	Cloud Manager エージェントAPI キーを提供します。
   --groupId	必須	グループID を指定します。
   --rsId	必須	レプリカセットID を指定します。
   --accessList	任意	復元を制限するデータベースやコレクションのリストを指定します。
   --denyList	任意	復元対象から除外するデータベースやコレクションのリストを提供します。
   --seedReplSetMember	任意	oplogコレクションを再作成し、正しいタイムスタンプでシードするためにレプリカセット ノードが必要な場合は、 を使用します。 --oplogSizeMBと--seedTargetPortが必要です。
   --oplogSizeMB	条件付き	oplogサイズを MB 単位で指定します。 --seedReplSetMemberが設定されている場合は必須です。
   --seedTargetPort	条件付き	レプリカセットのプライマリのポートを指定します。これは、使用されるエフェメラル ポートとは異なる場合があります。 --seedReplSetMemberが設定されている場合は必須です。
   --ssl	条件付き	oplog を に適用するために TLSmongod / SSL が必要な場合は、 を使用します。 --sslCAFileと--sslPEMKeyFileが必要です。
   --sslCAFile	条件付き	証明機関ファイルへのパスを指定します。 --sslが設定されている場合は必須です。
   --sslPEMKeyFile	条件付き	PEM証明書ファイルへのパスを指定します。 --sslが設定されている場合は必須です。
   --sslPEMKeyFilePwd	条件付き	--sslPEMKeyFileで指定されたPEM証明書ファイルのパスワードを入力します。 --sslが設定され、かつPEMキー ファイルが暗号化されている場合は必須です。
   --sslClientCertificateSubject		ターゲット MongoDB プロセスのクライアント証明書サブジェクトまたは識別名（DN）を指定します。
   --sslRequireValidServerCertificates	任意	ターゲット MongoDB プロセスが提示する証明書をツールが検証する必要があるかどうかを示すフラグを設定します。
   --sslServerClientCertificate	任意	Cloud Manager ホストへの接続に使用するクライアント証明書ファイルへの絶対パスを指定します。
   --sslServerClientCertificatePassword	条件付き	Cloud Manager ホストへの接続に使用するクライアント証明書ファイル パスワードへの絶対パスを指定します。 --sslServerClientCertificateが設定され、その証明書が暗号化されている場合は必須です。
   --sslRequireValidMMSBackupServerCertificate	任意	Cloud Manager ホストに接続するときに有効な証明書が必要かどうかを示すフラグを設定します。 デフォルト値はtrueです。
   --sslTrustedMMSBackupServerCertificate	任意	Cloud Manager ホストのPEM形式で、信頼できる証明機関証明書への絶対パスを指定します。 このフラグが提供されない場合は、システムの認証局が使用されます。
   --httpProxy	任意	ツールが使用できる HTTP プロキシ サーバーの URL を指定します。

   は、Cloud Manager に提供されるmongodb-backup-restore-utilコマンドをコピーした場合、このフィールドが事前構成されているということを意味します。

レプリカセットの管理を解除します。

データの手動復元を試みる前に、オートメーションからレプリカセットを削除します。

レプリカセットの手動復元。

MongoDB マニュアルのチュートリアルに従ってレプリカセットを復元します。

レプリカセットを再インポートします。

オートメーションでレプリカセットを再度管理するには、レプリカセットを Cloud Manager に再度インポートします。