自動バックアップの作成

Gen 2 Cloud Databases インスタンスをプロビジョニングすると、システムは毎日スケジュールされたバックアップ用に、独立したバックアップインスタンスを自動的に作成します。 これらのバックアップ：

• バックアップスケジュールに従って毎日作成されます
• デフォルトでは30日間保持されます
• 本サービスによって自動的に管理されます
• リソース一覧とデータベースハブに表示されます

オンデマンドでのバックアップ作成

IBM Cloud リソースコントローラーを使用すれば、いつでもオンデマンドで独立したバックアップを作成できます。 これらのバックアップ：

• リクエストがあるとすぐに作成されます
• 自動バックアップと同じ保持ポリシーに従う
• 有効期限が切れる前に手動で削除できます
• 大規模な変更や移行を行う前に役立ちます

バックアップのライフサイクル

独立したバックアップは、以下のライフサイクルに従います：

1. プロビジョニング ：バックアップインスタンスが作成されます（自動またはオンデマンド）
2. 有効 ：復元操作用にバックアップが利用可能です
3. 有効期限 ：バックアップの保存期間が終了する（デフォルトは30日間）
4. 削除 ：バックアップは自動的に削除されるか、手動で削除されます

結合されたバックアップとは異なり、独立したバックアップはリソースコントローラーを通じていつでも手動で削除できるため、バックアップデータや関連コストをより細かく管理することができます。

独立したバックアップを行うためのデータベースインスタンスの設定

データベースインスタンスでは、以下の機能を設定できます：

データベースインスタンスのプロビジョニングパラメータで、許可される構成を設定できます。 たとえば、次の設定では、データベースが削除された後もバックアップが保持されるように設定されます：

ibmcloud resource service-instance-create \
  <DATABASE_INSTANCE_NAME> \
  <DATABASE_SERVICE_NAME> \
  <DATABASE_SERVICE_PLAN_NAME> \
  <REGION> \
  -g <RESOURCE_GROUP> \
  -p '{
    "dataservices": {
      "backups": {"preserve": true}
    }
  }'

データベースインスタンスのプロビジョニングリクエストで、preserve オプションを設定できます。 次の例では、データベースインスタンスが削除された後もバックアップを保持するように、データベースインスタンスを設定しています

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "<DATABASE_INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<RESOURCE-GROUP>",
    "resource_plan_id": "<DATABASE_SERVICE_PLAN_NAME>",
    "parameters": {
      "dataservices": {
        "backups": {
          "preserve": true
        }
      }
    }
  }'

独立したバックアップからの復元

独立したバックアップは、ソースインスタンスがもはや存在しない場合でも、新しいデータベースインスタンスに復元できるため、災害復旧やデータ保持のシナリオにおいて、より高い柔軟性が確保されます。

バックアップは新しいインスタンスに復元されます。 新しいインスタンスのプロビジョニングが完了すると、バックアップファイル内のデータが新しいインスタンスに復元されます。

デフォルトでは、新しいインスタンスのサイズは、復元元のバックアップが作成された時点でのソースインスタンスのデフォルトのディスクサイズおよびホストサイズに合わせて自動的に設定されます。 新しいインスタンスに割り当てられるリソースを調整するには、UI、CLI、またはAPIのオプションフィールドを使用して、新しいインスタンスのサイズを変更してください。 データやワークロードに応じて十分なリソースを割り当てるようにしてください。インスタンスに十分なリソースが割り当てられていない場合、またはバックアップに含まれるストレージ容量がデフォルトのディスクサイズを上回っているにもかかわらずディスクサイズが指定されていない場合、復元は失敗します。

バックアップの復元中は、そのバックアップを削除しないでください。 バックアップを削除する前に、新しいインスタンスのプロビジョニングが完了し、バックアップが復元されるまでお待ちください。 デフォルトでは、データベースインスタンスを削除すると、そのバックアップも削除されます。

復元されたデータベースインスタンスにはすぐにアクセスできますが、ハイドレーションが完了するまではI/Oパフォーマンスが低下します。 ハイドレーションが完了するまでは、復元されたインスタンス上でバックアップを作成することはできません。 Activity Tracker のイベント機能を利用することで、水分補給の進捗状況を追跡できます。 詳細については、 at-events をご覧ください。

curl -X POST \
  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "<DATABASE_INSTANCE_NAME>",
    "target": "<REGION>",
    "resource_group": "<RESOURCE-GROUP>",
    "resource_plan_id": "<DATABASE_SERVICE_PLAN_NAME>",
    "parameters": {
      "dataservices": {
        "restore_backup_id": "<BACKUP_CRN>"
      }
    }
  }'

次に例を示します。

  https://resource-controller.cloud.ibm.com/v2/resource_instances \
  -H 'Authorization: Bearer <>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "mysql-restore-abc",
    "target": "us-east",
    "resource_group": "b67d9228670d473097259e2b343de464",
    "resource_plan_id": "databases-for-mysql-gen2-standard",
    "parameters": {
      "dataservices": {
        "restore_backup_id": "crn:v1:bluemix:public:databases-independent-backups:us-east:a/26b19aex04da4475b6e31205fa93248d:793b4f27-7733-4803-917f-de8e055e2deb::"
      }
    }
  }'

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID>-gen2-<PLAN NAME> <REGION> -p  '{"dataservices":{"restore_backup_id":"<BACKUP_CRN>"}}'

ibmcloud resource service-instance-create mysql-restore-abc databases-for-mysql databases-for-mysql-gen2-standard us-east -p  '{"dataservices":{"restore_backup_id":"crn:v1:bluemix:public:databases-independent-backups:us-east:a/26b19aex04da4475b6e31205fa93248d:793b4f27-7733-4803-917f-de8e055e2deb::"}}'

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID> gen2-<PLAN NAME> <REGION> -p
'{"restore_backup_id":"BACKUP_ID","key_protect_key":"KEY_PROTECT_KEY_CRN", "storage_gb":"DESIRED_DISK_IN_GB", "host_flavor": "<VALUE>"}'

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

バックアップの暗号化

独立したバックアップは、データベースインスタンスと同じ暗号化方式を用いて、保存時に暗号化されます。 Key Protect を使用してデータベースの暗号化を管理している場合、バックアップも同じ鍵で暗号化されます。 詳細については、「 Key Protect との連携 」を参照してください。

Key Protect キーで暗号化されたバックアップを復元する場合、同じキーを使用することも、別のキーを使用することもできます。 別の鍵を使用した場合、新しいインスタンスはその新しい鍵で暗号化されます。

アカウント復元

個別のバックアップは、 IBM Cloud アカウント間で復元できるため、次のようなシナリオが可能になります：

• テストのために、 アカウント復元する
• 組織単位間のデータベースの移行
• 別のアカウントへの災害復旧

別のアカウントにバックアップを復元するには：

1. ソースアカウントは、ターゲットアカウントに対してバックアップリソースへのアクセス権を付与する必要があります
2. 対象アカウントで新しいインスタンスを作成する際は、バックアップCRNを使用してください
3. 対象アカウントに適切なIAM権限が設定されていることを確認してください

アカウント復元に関する詳細については、 アカウント復元 を参照してください。

独立したバックアップ機能を備えたデータベース

対象となるデータベースおよびリージョンについては、段階的に独立したバックアップ機能が有効化されます。

30日間の移行期間中は：

• 結合バックアップと独立バックアップが共存しています。
• 新しいバックアップはすべて、独立したバックアップとして作成されます。
• 既存の連携バックアップは引き続き機能し、30日後に自動的に削除されます。
• UIには、両方のバックアップタイプが表示されます。
• アクションは不要です。 この移行は自動的に行われます。
• 30日間の移行期間が終了すると、独立したバックアップのみが残ります。

MySQL

Databases for MySQL 一般提供時点では、独立したバックアップのみをサポートしています。 MySQL の導入においては、連動したバックアップも移行期間も存在しません。