IBM Cloud Docs
ポイント・イン・タイム・リカバリ(PITR)

ポイント・イン・タイム・リカバリ(PITR)

IBM Cloud® Databases for MongoDB Enterprise Edition は、使用可能な最も古いリカバリー・ポイントより大きいタイム・スタンプを使用して PITR を提供します。 API を使用して最も古いリカバリー・ポイントをディスカバーするには、 point-in-time-recovery タイム・スタンプ・エンドポイント を使用します。

新しいホスティング・モデルの場合、PITR は現在 CLI、API、および Terraform を介して使用可能です。

最後のトランザクションの後のリストア時間を使用して、過去 7 日以内の特定のポイントにリストアすると、リストアは失敗し、メッセージ recovery ended before configured recovery target is reached が表示されます。 この理由でリストアが失敗した場合は、使用可能な最後のポイントにリストアするか、過去 7 日間の特定のポイントにリストアするために以前の日時を選択してください。

{
    "point_in_time_recovery_data": {
        "earliest_point_in_time_recovery_time": "2019-09-09T23:16:00Z"
    }
}

このフェーズでは、ポイント・イン・タイム・リカバリーのタイム・スタンプ・エンドポイントは、常に current time- 約 1 週間を返します。

回復

バックアップは新規デプロイメントにリストアされます。 新規デプロイメントがプロビジョニングを終了すると、バックアップ・ファイル内のデータが新規デプロイメントにリストアされます。 バックアップは、アカウント間でリストアすることもできますが、API を使用している場合で、かつ、リストアを実行するユーザーがソース・アカウントと宛先アカウントの両方へのアクセス権限を持っている場合に限られます。

新しい配置は、リストア元のバックアップ時のソース配置と同じディスクと メモリ割り当てに自動的にサイズ調整されます。 特にPITRでは、それが現在の配備規模ではないかもしれない。 新規デプロイメントに割り振るリソース量を調整する必要がある場合は、UI、CLI、または API のフィールドを使用して新しいデプロイメントのサイズを変更します。 デプロイメントに十分なリソースが指定されていない場合、リストアは失敗するため、データとワークロードに十分なリソースを割り振ってください。

ストレージとメモリーはソース・デプロイメントと同じにリストアされますが、新規インスタンスの固有のインスタンス構成は自動設定されません。 この場合は、リストア後の構成の再実行が必要になることがあります。 リストア完了後のインスタンスの正確な設定を確実にするために、リストアを実行する前にインスタンスの変更(shared_buffers, max_connections, deadlock_timeout, archive_timeout のようなパラメータ)をメモしておきます。

バックアップのリストア中は、ソース・デプロイメントを削除しないでください。 古いデプロイメントを削除する前に、新規デプロイメントがプロビジョンされ、バックアップがリストアされるまで待機する必要があります。 デプロイメントを削除すると、そのバックアップも削除されます。 そのため、リストアが失敗するだけでなく、バックアップをリカバリーできない場合もあります。

UI によるリカバリー

デプロイメントの最初のバックアップが完了すると、ポイント・イン・タイム・リカバリー・オプションが UI に表示されます。 PITR を開始するには、復元先の時刻を協定世界時で入力します。

ポイント・イン・タイム・リカバリーのタイム・スタンプは、 %Y-%m-%dT%H:%M:%SZ のようにフォーマット設定する必要があります。

利用可能な最新の時間に復元するには、そのオプションを選択します。 **「リストア (Restore)」**をクリックすると、リカバリーのオプションが表示されます。 新規デプロイメントの名前を入力し、バージョン、リージョン、およびリソースの割り振り量を選択します。 **「リカバリー」**をクリックして、プロセスを開始します。

Key Protectを使用し、キーを持っている場合は、CLIを使用して回復する必要があります。

CLI を使用したリカバリー

リソース・コントローラーはデータベース・デプロイメントのプロビジョニングをサポートしており、プロビジョニングとリストアはリソース・コントローラーの CLI で実行します。 resource service-instance-create コマンドを使用します。

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE_ID> <SERVICE_PLAN_NAME> <REGION> -p '{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP", "version":""}'

利用可能なパラメータは以下の通り:

  • instance_name(必須):例えば new-mongo のように、デプロイされる新しいインスタンスの人間が読める名前。
  • service_id(必須):この文脈では databases-for-mongodb です。
  • service_plan_name(必須):standard または enterprise
  • region(必須):例えば、eu-gb のように、新しいデータベースが配置されるIBM Cloud®リージョン。
  • point_in_time_recovery_deployment_id(必須):ソース配備の ID (CRN とも呼ばれる)。
  • point_in_time_recovery_time: バックアップを復元する時点。形式は %Y-%m-%dT%H:%M:%SZ、 例えば、2024-05-10T08:15:00Z。 最新の復元可能なポイントを取得するには、このフィールドを空白のままにします。
  • version: データベースのバージョン。例: "6.0 「」。 最新の優先バージョンを使用するには、このフィールドを空白のままにしておきます。
  • key_protect_key: ID (CRN)Key Protect使用されたリソース。 このフィールドは、BYOK (Bring Your Own Key) 暗号化の場合、オプションです。
  • members_host_flavor: デプロイするインスタンス ホストのサイズ。 指定しない場合は、ソースインスタンスと同じ RAM と CPU を使用して新しいインスタンスが作成されます。 利用可能な値については、この テーブル を参照のこと。

ibmcloud resource service-instance-create big-mongo-restore databases-for-mongodb enterprise eu-gb -p '{"point_in_time_recovery_deployment_id":"crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::", "members_host_flavor":"b3c.4x16.encrypted", "point_in_time_recovery_time":"", "version":""}'

API を使用したリカバリー

リソース・コントローラーはデータベース・デプロイメントのプロビジョニングをサポートしており、プロビジョニングとリストアはリソース・コントローラー API で実行します。 リソース・コントローラー API を使用してバックアップからリストアする前に、リソース・コントローラー API を使用するために必要なステップを完了する必要があります。

すべての情報が揃ったら、作成リクエストは /resource_instances エンドポイントへの POST となります。

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "<SERVICE_INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<YOUR-RESOURCE-GROUP>",
    "resource_plan_id": "<SERVICE-ID>",
    "parameters": {
      "point_in_time_recovery_time":"<TIMESTAMP>",
      "point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>"
    }
  }'

以下のフィールドはすべて必須です:

  • name: デプロイする新しいインスタンスの人間が読める名前、例:new-mongo
  • resource_group: リソースグループのID、例:5c49eabc12fgt65
  • resource_plan_id: この文脈ではこれは databases-for-mongodb-enterprise
  • target: のIBM Cloud新しいデータベースがデプロイされるリージョン、例:eu-gbeu-de バックアップを別のリージョンにリストアする場合を除き、リージョンをまたいだリストアがサポートされています。

さらに、parameters オブジェクトには次のフィールドを指定できます。

  • point_in_time_recovery_deployment_id: ソース デプロイメントの ID (CRN とも呼ばれます)。
  • point_in_time_recovery_time: バックアップを復元する時点。形式は %Y-%m-%dT%H:%M:%SZ、 例えば、2024-05-10T08:15:00Z。 最新の復元可能なポイントを取得するには、このフィールドを空白のままにします。
  • version: データベースのバージョン。例: "6.0 「」。 最新の優先バージョンを使用するには、このフィールドを空白のままにしておきます。
  • key_protect_key: ID (CRN)Key Protect使用されたリソース。 このフィールドは、BYOK (Bring Your Own Key) 暗号化の場合、オプションです。
  • members_host_flavor: デプロイするインスタンス ホストのサイズ。 指定しない場合は、ソースインスタンスと同じ RAM と CPU を使用して新しいインスタンスが作成されます。 を参照してください テーブル 使用可能な値。

ポイント・イン・タイム・リカバリーのタイム・スタンプは、 %Y-%m-%dT%H:%M:%SZ のようにフォーマット設定する必要があります。

Terraform を使用したバックアップのリストア

リストアする前に、 point_in_time_recovery_time が 1 週間を経過していないことを確認してください。 タイム・スタンプが 7 日以上経過している場合、2 回目までは検証が失敗します。

ibm_database_point_in_time_recovery データ・ソースを使用して、 point_in_time_recoveryでデータベース・インスタンスをリストアします。

ポイント・イン・タイム・リカバリーのタイム・スタンプは、 %Y-%m-%dT%H:%M:%SZ のようにフォーマット設定する必要があります。

Terraform スクリプトは以下のようになります。

terraform {
  required_providers {
     ibm = {
       version = "1.44.3"
       source  = "IBM-Cloud/ibm"
    }
  }
}

variable "ibmcloud_api_key" {
  description = "<Enter your IBM Cloud API Key>"
}

provider "ibm" {
  region = "us-south"
  ibmcloud_api_key = var.ibmcloud_api_key
}

data "ibm_resource_group" "default_group" {
  is_default = true
}

resource "ibm_database" "mongodb_enterprise" {
  resource_group_id = data.ibm_resource_group.default_group.id
  name              = "testing-mongodb-pitr"
  service           = "databases-for-mongodb"
  plan              = "enterprise"
  location          = "us-south"

  point_in_time_recovery_deployment_id = "<crn>"
  point_in_time_recovery_time = "2022-09-14T14:47:45Z"

}

上記は、ソースと同じホスト サイズとディスク サイズを持つ新しいデータベースに復元します。 デプロイメントのホストサイズまたはディスクサイズを変更する場合は、 Terraform ドキュメント 正しい書式設定のため。

ポイント・イン・タイム・リカバリ(PITR)オフライン・リストア

IBM Cloud® Databases for MongoDB Enterprise Edition では、リストアを開始するために 2 つのプロセスが必要です。 最初に、 Ops Manager AppDBのスナップショットが作成されます。 このスナップショットは PITR バックアップとして機能し、データベースのリストアに使用できます。

いくつかの 災害からの回復サービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。 これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。 その影響は、高可用性設計の処理能力を超えている。シナリオによっては、PITR プロセスが失敗する可能性があります。 そのような場合Databases for MongoDBEnterprise Editionポイントインタイムリカバリ (PITR) オフライン復元を使用して、利用可能な最新のスナップショットに復元できます。 オフライン・リストア・オプションは、スナップショット方式が期待どおりに機能しない場合に、データの可用性とシステム回復力を確保します。

UIによるポイント・イン・タイム・リカバリ(PITR)オフライン・リストア

標準 PITR の場合と同様に、 IBM Cloud ダッシュボードを使用してオフライン・リストアを開始します。 3 番目のポイント・イン・タイム・リカバリー・オプションを選択します。

CLIによるポイント・イン・タイム・リカバリ(PITR)オフライン・リストア

次のようなコマンドを使用して、 IBM Cloud CLI からオフライン・リストアを開始します。

ibmcloud resource service-instance-create big-mongo-restore databases-for-mongodb enterprise eu-gb -p '{"point_in_time_recovery_deployment_id":"crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::", "members_host_flavor":"b3c.4x16.encrypted", "point_in_time_recovery_time":"", "version":"", "offline_restore": true}'

以下のパラメーターを指定します。

  • point_in_time_recovery_deployment_id-これはソース CRN です。
  • point_in_time_recovery_time- 空白のまま、""
  • offline_restore- この値を true にします。

コマンドの出力は次のようになる:

Creating service instance <INSTANCE_NAME> in resource group Default of account <ACCOUNT> as <USER>...
OK
Service instance <INSTANCE_NAME> was created.

Name:                <INSTANCE_NAME>
ID:                  crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::
GUID:                3c647ad1-b9a8-2233-a47e-668d8b83e79f
Location:            <LOCATION>
State:               provisioning
Type:                service_instance
Sub Type:            Public
Service Endpoints:   public
Allow Cleanup:       false
Locked:              false
Created at:          2023-08-03T09:36:37Z
Updated at:          2023-08-03T09:36:41Z
Last Operation:
                     Status    create in progress
                     Message   Started create instance operation

ポイント・イン・タイム・リカバリーのタイム・スタンプは、 %Y-%m-%dT%H:%M:%SZ のようにフォーマット設定する必要があります。

ポイント・イン・タイム・リカバリ(PITR)APIによるオフライン・リストア

リソース・コントローラーはデータベース・デプロイメントのプロビジョニングをサポートしており、プロビジョニングとリストアはリソース・コントローラー API で実行します。 リソース・コントローラー API を使用してバックアップからリストアする前に、 リソース・コントローラー API を使用するために必要なステップ を実行します。

すべての情報を取得すると、作成要求は /resource_instances に対する POST となり、以下のようになります。

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
    -d '{
    "name": "<SERVICE_INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<YOUR-RESOURCE-GROUP-ID>",
    "resource_plan_id": "<SERVICE-ID>",
    "parameters": {
      "point_in_time_recovery_time":"<TIMESTAMP>",
      "point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>",
      "offline_restore": true
    }
  }'

以下のパラメーターを指定します。

  • point_in_time_recovery_deployment_id-これはソース CRN です。
  • point_in_time_recovery_time- 空白のまま、""
  • offline_restore- この値を true にします。

ポイント・イン・タイム・リカバリーのタイム・スタンプは、 %Y-%m-%dT%H:%M:%SZ のようにフォーマット設定する必要があります。