独立したバックアップの管理
Gen 2
現在、独立したバックアップは、 Databases for PostgreSQL、 Databases for MongoDB、 Databases for Redis、 Databases for Elasticsearch、および Databases for MySQL でのみ利用可能です。
独立したバックアップは、 Cloud Databases Gen 2 におけるバックアップデータの管理方法に根本的な変化をもたらしています。 データベース・インスタンスのライフサイクルと密接に結びついている従来のバックアップとは異なり、独立したバックアップは、独自のライフサイクルを持つ個別のプロビジョニング可能なサービス・インスタンスとして存在するため、ソースとなるデータベース・インスタンスが削除された後もバックアップデータを保持し続けることができます。 独立したバックアップは、個別のサービスインスタンスとして課金されます。 詳細については、「 独立したバックアップの課金 」をご覧ください。
独立したバックアップとは何ですか?
独立バックアップとは、データベースサービスインスタンスとは独立して動作するバックアップインスタンスのことです。 個々の独立したバックアップは、それぞれ独自の以下の要素を備えた、フルマネージドサービスのリソースです:
- サービス名およびクラウドリソース名(CRN)
- IBM Cloud リソースコントローラーによるライフサイクル管理
- 請求およびリソースの追跡
- アクセス制御と権限
このアーキテクチャにより、バックアップデータの管理においてより高い柔軟性が確保され、長期的なデータ保存、コンプライアンス要件への対応、およびソースデータベースがもはや存在しない可能性のある災害復旧シナリオといったユースケースに対応できるようになります。
結合バックアップとの主な違い
| 特長 | 結合バックアップ | 独立したバックアップ |
|---|---|---|
| ライフサイクル | データベースインスタンスに関連付けられている | データベース・インスタンスに依存しない |
| 永続性 | インスタンスが削除されると削除される | インスタンスの削除後も永続化可能 |
| 管理 | UIのみ | IBM Cloud リソースコントローラ |
| 表示設定 | インスタンスUIのみ | データベースハブ、リソース一覧、インスタンスUI |
| 削除 | 自動のみ(30日間) | 手動と自動 |
| 地域をまたぐコピー | サポートされていません | PostgreSQL のみ |
| プロビジョニング | 自動およびオンデマンド | 自動およびオンデマンド |
| 課金 | インスタンスに含まれるもの | サービスの個別請求 |
独立したバックアップの仕組み
自動バックアップの作成
Gen 2 Cloud Databases インスタンスをプロビジョニングすると、システムは毎日スケジュールされたバックアップ用に、独立したバックアップインスタンスを自動的に作成します。 これらのバックアップ:
- バックアップスケジュールに従って毎日作成されます
- デフォルトでは30日間保持されます
- 本サービスによって自動的に管理されます
- リソース一覧とデータベースハブに表示されます
オンデマンドでのバックアップ作成
IBM Cloud リソースコントローラーを使用すれば、いつでもオンデマンドで独立したバックアップを作成できます。 これらのバックアップ:
- リクエストがあるとすぐに作成されます
- 自動バックアップと同じ保持ポリシーに従う
- 有効期限が切れる前に手動で削除できます
- 大規模な変更や移行を行う前に役立ちます
バックアップのライフサイクル
独立したバックアップは、以下のライフサイクルに従います:
- プロビジョニング :バックアップインスタンスが作成されます(自動またはオンデマンド)
- 有効 :復元操作用にバックアップが利用可能です
- 有効期限 :バックアップの保存期間が終了する(デフォルトは30日間)
- 削除 :バックアップは自動的に削除されるか、手動で削除されます
結合されたバックアップとは異なり、独立したバックアップはリソースコントローラーを通じていつでも手動で削除できるため、バックアップデータや関連コストをより細かく管理することができます。
前提条件
独立したバックアップを使用する前に、以下の操作について、サービス間認証が設定されていることを確認してください
- データベースインスタンスのプロビジョニング
- データベースインスタンスの更新
- preserve: false と設定されているデータベースインスタンスのプロビジョニングを解除する
- 独立したバックアップのプロビジョニング
データベースインスタンスの設定で preserve: false が指定されている場合、そのデータベースインスタンスが完全に削除されると、そのインスタンスの独立したバックアップも削除されます。
詳細については、「 サービス間認証 」を参照してください。
バックアップへのアクセス
複数の場所にある独立したバックアップにアクセスできます:
- インスタンスのUI :データベースインスタンスのダッシュボードに移動し、「 バックアップと復元 」タブを確認してください。
- データベースハブ : アカウント全体のすべてのバックアップを一元的に確認できます。
- リソース一覧 :独立したバックアップは、個別のサービスインスタンスとして表示されます。
第2世代の Cloud Databases バックアップは、作成されたのと同じリージョン内でのみ復元できます。
独立したバックアップの表示
独立したバックアップは、複数の場所で確認できます:
データベース・ハブ
IBM Cloud コンソールでは、 アカウント全体のすべてのバックアップを一元的に確認できます:
- IBM Cloud コンソールにアクセスし、「 リソース一覧 」>「 データベース 」の順に選択します。
- データベースインスタンスと、それに関連付けられたバックアップを表示します。
- 独立したバックアップは、リソース一覧に個別のサービスインスタンスとして表示されます。
これにより、整理や長期保存が必要なバックアップを特定するのに役立ちます。
リソース・リスト
独立したバックアップは、 IBM Cloud のリソース一覧に個別のサービスインスタンスとして表示されます:
- リソース一覧 に移動してください。
- サービスタイプでフィルタリングして、バックアップインスタンスを表示します。
- バックアップインスタンスをクリックすると、詳細を確認したり、そのライフサイクルを管理したりできます。
インスタンスのバックアップと「復元」タブ
UIで 「バックアップと復元 」タブに移動すると、結合バックアップと独立バックアップの両方を含む、データベースの利用可能なすべてのバックアップが一覧表示された表が表示されます。
バックアップの種類は、「 オンデマンド 」または「 自動 」のいずれかを選択できます。 各バックアップには、その種類、バックアップが実行された日時、および結合バックアップか独立バックアップかが表示されます。
バックアップをクリックすると、その特定のバックアップに関する情報(完全なIDやCRNなど)が表示されます。 復元オプションとして、 復元ボタンまたはあらかじめフォーマットされた CLI コマンドが用意されています。
PostgreSQL,、 MongoDB,、 Elasticsearch、および Redis については、30日間の移行期間中、このビューに結合されたバックアップと独立したバックアップの両方が表示される場合があります。 リンクされたバックアップは、30日後に自動的に削除されます。
独立したバックアップの管理
独立したバックアップを行うためのデータベースインスタンスの設定
データベースインスタンスでは、以下の機能を設定できます:
| 特長 | 独立したバックアップ | 構成 |
|---|---|---|
| 保持期間 | バックアップをいつ削除できるかを決定します。 自動バックアップは、保存期間が満了すると自動的に削除されます。 オンデマンドバックアップは、保存期間が満了した後、手動で削除することができます。 | 期間は30日間と固定されており、設定を変更することはできません。 |
| バックアップを保存する | データベースインスタンスが削除された場合に、バックアップ(自動バックアップ、オンデマンドバックアップ、およびバックアップコピー)を保持するかどうかを指定します。 | デフォルトで false に設定されます。 オンデマンドのバックアップコピーを除き、独立したバックアップは、データベースインスタンスが完全に削除されると保持されなくなります。 このオプションはデータベースインスタンスで有効にできますが、一度有効にすると無効にすることはできません。 Databases for MySQL では、preserve はデフォルトで無効になっており、有効にすることはできません。 |
| 開始時刻 | データベースインスタンス上で自動バックアップが開始される、1時間のウィンドウの開始時刻を指定します。 自動バックアップは毎日実行されます。 | データベースインスタンスのプロビジョニング時にデフォルト値が設定され、設定を変更することはできません。 |
データベースインスタンスのプロビジョニングパラメータで、許可される構成を設定できます。 たとえば、次の設定では、データベースが削除された後もバックアップが保持されるように設定されます:
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
}
}
}
}'
以下の Terraform リクエストを使用して、自動バックアップの設定を行うことができます:
次に例を示します。
data "ibm_resource_group" "rg" {
name = var.resource_group_name
}
resource "ibm_database" "backup_configuration_test" {
name = "<DATABASE_INSTANCE_NAME>"
resource_group_id = data.ibm_resource_group.rg.id
service = "<DATABASE_SERVICE_NAME>"
plan = "<DATABASE_SERVICE_PLAN_ID>"
location = "<GEN2-REGION>"
service_endpoints = "private"
backups {
retention = 30
preserve = true
automatic_backups {
copy {
enabled = true
target = [
{
region = "<TARGET-GEN2-REGION>"
}
]
}
}
}
}
UI でのオンデマンドバックアップの実行
インスタンスにスケーリングやデータベース、テーブル、コレクションの削除など、大幅な変更を加える予定がある場合は、オンデマンドバックアップが役立ちます。 また、スケジュールをバックアップする必要がある場合にも有益です。 オンデマンド・バックアップの保存期間は 30 日間です。
UIで手動バックアップを作成するには、インスタンスの「 バックアップと復元 」タブに移動し、「 バックアップの作成 」をクリックします。 バックアップが進行中であることを示すメッセージが表示され、使用可能なバックアップのリストにこのオンデマンド・バックアップが追加されます。
バックアップのプロビジョニングが完了すると、バックアップ CRN、関連付けられているデータベースインスタンスとそのバージョン、リージョン、ステータス、サイズなど、バックアップの詳細を確認できます。
CLI を使用した独立したバックアップの作成
IBM Cloud CLI を使用して、オンデマンドの独立したバックアップを作成するには:
ibmcloud resource service-instance-create \
<BACKUP_INSTANCE_NAME> \
<BACKUP_SERVICE_NAME> \
<BACKUP_SERVICE_PLAN_NAME> \
<REGION> \
-g <RESOURCE_GROUP> \
-p '{
"dataservices": {
"source_dataservice_crn": "<DATABASE_INSTANCE_CRN>"
}
}'
次に例を示します。
ibmcloud resource service-instance-create \
my-mysql-backup-20260429 \
databases-independent-backups \
databases-independent-backups-gen2-standard \
us-east \
-g Default \
-p '{
"dataservices": {
"source_dataservice_crn": "crn:v1:bluemix:public:databases-for-mysql:us-east:a/1234567890:abcd-1234-efgh-5678::"
}
}'
プロビジョニングが完了すると、バックアップインスタンスの「 リソースコントローラー拡張機能 」フィールドで、関連するデータベースインスタンスやバージョン、リージョン、ステータス、サイズなどのバックアップの詳細を確認できます。
以下はコマンドの実行結果の例です:
ibmcloud resource service-instance --output JSON crn:v1:staging:public:databases-independent-backups:ca-mon:a/cf8d4161fa0243b9a2a5494cd7ff66b7:4be73b7d-a395-4613-83dd-315a6e573e00:: | jq '.[0].extensions'
{
"dataservices": {
"backup": {
"can_be_deleted_after": "<timestamp after which retention duration expires>",
"size_gb": <size of the backup in GB>,
"source_data_service_crn": "<CRN of the database provided at the time of provisioning the backup>",
"type": "<type of the backup, value is either on_demand or automatic>",
"version": "major version of the database"
}
}
}
API を使用した独立したバックアップの作成
オンデマンドの独立したバックアップを作成するには、バックアップ作成エンドポイントにリクエストを送信します:
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": {
"source_dataservice_crn": "<DATABASE_INSTANCE_CRN>"
}
}
}'
次に例を示します。
curl -X POST \
https://resource-controller.cloud.ibm.com/v2/resource_instances \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{
"name": "my-mysql-backup-20260429",
"target": "us-east",
"resource_group": "b67d9228670d473097259e2b343de464",
"resource_plan_id": "databases-independent-backups-gen2-standard",
"parameters": {
"dataservices": {
"source_dataservice_crn": "crn:v1:bluemix:public:databases-for-mysql:us-east:a/1234567890:abcd-1234-efgh-5678::"
}
}
}'
独立したバックアップからの復元
独立したバックアップは、ソースインスタンスがもはや存在しない場合でも、新しいデータベースインスタンスに復元できるため、災害復旧やデータ保持のシナリオにおいて、より高い柔軟性が確保されます。
バックアップは新しいインスタンスに復元されます。 新しいインスタンスのプロビジョニングが完了すると、バックアップファイル内のデータが新しいインスタンスに復元されます。
デフォルトでは、新しいインスタンスのサイズは、復元元のバックアップが作成された時点でのソースインスタンスのデフォルトのディスクサイズおよびホストサイズに合わせて自動的に設定されます。 新しいインスタンスに割り当てられるリソースを調整するには、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::"
}
}
}'
UI でのバックアップのリストア
新規サービス・インスタンスにバックアップをリストアするには、以下のようにします。
- 対応する行をクリックして、リストアしようとしているバックアップのオプションを展開します。
- **「復元」**をクリックします。
- 「 プロビジョニング 」ページで、利用可能なオプションから選択してください。
- 新しいサービスインスタンスの名前を指定してください。
- 初期のリソース割り当てを選択することも、新しいインスタンスでリソースを拡張することもできます。 リソースの量を減らすと、プロビジョニングに失敗したり、データベースが正常に動作しなくなったりする可能性があることにご注意ください。
- 「 バックアップを復元 」をクリックします。 「バックアップからのリストアを開始しました (restore from backup started)」というメッセージが表示されます。 新しいインスタンスが利用可能になりましたをクリックすると、 _リソース一覧_が表示されます。
CLI でのバックアップのリストア
リソース・コントローラーはデータベース・インスタンスのプロビジョニングをサポートしており、プロビジョニングと復元はリソース・コントローラー CLI の役割です。 resource service-instance-create コマンドを使用します。
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::"}}'
- の値を、新しいインスタンスに付けたい名
instance_name前に変更してください。 service-idはインスタンスの種類です(例: databases-for-postgresql、 databases-for-mongodb、 databases-for-mysql )。- は、新しいインスタンスを配置したい場所を指します
region。これは、ソースインスタンスとは異なるリージョンであっても構いません。 - この は、復元したいバックアップ
restore_backup_idです。
上記のコマンドを実行すると、元のデプロイメントと同じ構成で、同じホスティングモデルを採用しているマシンにバックアップが復元されます。
CLI のオプションパラメータ
オプション・パラメーターは CLI を介して使用できます。 リソースのカスタマイズ、ホスティングモデルの変更、または新しいインスタンスでのBYOK暗号化に Key Protect キーを使用する必要がある場合は、これらを参照してください。 以下の例を参照してください。
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>"}'
host_flavor は、適切なサイズのホストであるべきです。 詳細については、 利用可能な値の一覧を 参照してください。
特定のバックアップ用の事前フォーマット済みコマンドは、インスタンスのダッシュボードにある [ バックアップと復元] タブの、そのバックアップの詳細ビューで確認できます。
デフォルトでは、バックアップからの復元時には、復元元のインスタンスのバージョンではなく、データベースタイプの推奨バージョンに基づいてインスタンスがプロビジョニングされます。 Gen 2 Cloud Databases は現在、データベースごとに 1 つのバージョンのみに対応しています。 今後、新しいバージョンがリリースされることになりますが、新しいバージョンが利用可能になった際には、バックアップからの復元を行うことで、そのバージョンに移行することができます。
API でのバックアップのリストア
リソースコントローラー API は、データベースインスタンスのプロビジョニングと復元をサポートしています。 createリクエストは、 POST への /resource_instances エンドポイントへのxml-ph-0000@deepl.internalです。
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>"
}
}'
パラメータ name、 target、 resource_group、およびはすべて必須 resource_plan_id であり、は復元したいバックアップ restore_backup_id です。
- の値を、新しいインスタンスに付けたい名
name前に変更してください。 resource_plan_idはインスタンスの種類です(例: databases-for-postgresql、 databases-for-mongodb、 databases-for-mysql )。targetは、新しいインスタンスを配置したいリージョンを指し、Gen 2 リージョンである必要があります。- この は、復元したいバックアップ
restore_backup_idです。
上記のコマンドを実行すると、元のデプロイメントと同じ構成で、同じホスティングモデルを採用しているマシンにバックアップが復元されます。
API のオプションパラメータ
オプションのパラメータは、リソースコントローラーAPIを通じて利用可能です。 リソースのカスタマイズ、ホストサイズの変更、特定のバージョンへのデプロイ、または新しいインスタンスでのBYOK暗号化に Key Protect キーを使用する必要がある場合は、これらをご利用ください。
リソースを調整する必要がある場合は、オプションのパラメータ key_protect_key、 storage_gb、 host_flavor 、または version のいずれかと、それぞれの推奨値をリクエスト本文に追加してください。
バックアップの暗号化
独立したバックアップは、データベースインスタンスと同じ暗号化方式を用いて、保存時に暗号化されます。 Key Protect を使用してデータベースの暗号化を管理している場合、バックアップも同じ鍵で暗号化されます。 詳細については、「 Key Protect との連携 」を参照してください。
Key Protect キーで暗号化されたバックアップを復元する場合、同じキーを使用することも、別のキーを使用することもできます。 別の鍵を使用した場合、新しいインスタンスはその新しい鍵で暗号化されます。
事業継続性と災害復旧
独立したバックアップは、事業継続および災害復旧戦略において極めて重要な要素です。 これらはソースデータベースインスタンスとは独立して存続するため、以下の脅威に対する保護機能を提供します:
- データベースの誤削除
- データ破損
- リージョン間の障害(バックアップが異なるリージョンに保存されている場合)
Cloud Databases における事業継続および災害復旧に関する詳細については、以下を参照してください
地域間のコピー
リージョン間コピー機能を使用すると、災害復旧や事業継続の目的で、独立したバックアップのコピーを、サポートされている別の IBM Cloud リージョンに作成することができます。
地域をまたぐコピーの利用可能性
| データベース | サポートされる地域 |
|---|---|
| PostgreSQL | ca-mon, in-che, in-mum |
| MongoDB エンタープライズ | ca-mon, in-che, in-mum |
| MongoDB シャーディング | ca-mon, in-che, in-mum |
| Elasticsearch エンタープライズ | ca-mon, in-che, in-mum |
| Redis | ca-mon, in-che, in-mum |
バックアップは、「 アクティブ 」状態にある場合にのみコピーできます。 対象領域は、ソース領域とは異なる必要があります。
コピーされたバックアップは、対象リージョン内に独立したバックアップインスタンスとして作成され、そのリージョン内でのみ復元が可能です。 たとえば、 ca-mon にバックアップが存在し、それを in-che に復元したい場合は、まず in-che にそのバックアップのコピーを作成し、そのコピーから復元する必要があります。
データベースインスタンスに対して、リージョン間の自動バックアップコピーを設定できます。 バックアップコピー用に設定できるターゲットリージョンは1つだけであり、そのリージョンはデータベースインスタンスのリージョンとは異なる必要があります。 対象地域として、サポートされている地域ならどれでも選択できます。
また、UI、API、またはCLIを使用して、データベースインスタンスの設定から設定済みのターゲットリージョンを削除することで、リージョン間の自動バックアップコピーを無効にすることもできます。
ターゲットリージョンが指定されておらず、自動バックアップが有効になっている場合、データベースインスタンスには以下のデフォルトのターゲットリージョンが適用されます。
| ソース・リージョン | デフォルトのターゲット地域 |
|---|---|
| ca-mon | なし |
| in-che | in-mum |
| in-mum | in-che |
CLI を使用して独立したバックアップコピーをプロビジョニングする
オンデマンドで独立したバックアップコピーをプロビジョニングするには、次のコマンドを使用します
ibmcloud resource service-instance-create \
<BACKUP_INSTANCE_NAME> \
<BACKUP_SERVICE_NAME> \
<BACKUP_SERVICE_PLAN_NAME> \
<REGION> \
-g <RESOURCE_GROUP> \
-p '{
"dataservices": {
"source_backup_crn": "<BACKUP_CRN>"
}
}'
次に例を示します。
ibmcloud resource service-instance-create \
my-backup-copy \
databases-independent-backups \
databases-independent-backups-gen2-standard \
ca-mon \
-g Default \
-p '{
"dataservices": {
"source_backup_crn": "crn:v1:bluemix:public:databases-independent-backups:ca-mon:a/23b09aee04da4545b6e32805fa93249d:c97d1ca8-bfb8-4bcb-a46f-85c6374901ac::"
}
}'
API を使用して独立したバックアップコピーをプロビジョニングする
オンデマンドで独立したバックアップコピーをプロビジョニングするには、次のコマンドを使用します
curl -X POST \
https://resource-controller.cloud.ibm.com/v2/resource_instances \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{
"name": "<BACKUP_INSTANCE_NAME>",
"target": "<REGION>",
"resource_group": "<RESOURCE-GROUP>",
"resource_plan_id": "databases-independent-backups-gen2-standard",
"parameters": {
"dataservices": {
"source_backup_crn": "<BACKUP_CRN>"
}
}
}'
次に例を示します。
curl -X POST \
https://resource-controller.cloud.ibm.com/v2/resource_instances \
-H 'Authorization: Bearer <>' \
-H 'Content-Type: application/json' \
-d '{
"name": "my-backup-copy",
"target": "<REGION>",
"resource_group": "b67d9228670d473097259e2b343de464",
"resource_plan_id": "databases-independent-backups-gen2-standard",
"parameters": {
"dataservices": {
"source_backup_crn": "crn:v1:bluemix:public:databases-independent-backups:ca-mon:a/23b09aee04da4545b6e32805fa93249d:c97d1ca8-bfb8-4bcb-a46f-85c6374901ac::"
}
}
}'
Databases for MySQL リージョン間のコピーには対応していません。
API を使用した独立したバックアップの削除
有効期限が切れる前に独立したバックアップを削除するには、次のコマンドを実行してください
curl -X DELETE \
https://resource-controller.cloud.ibm.com/v2/resource_instances/${INDEPENDENT_BACKUP_ID} \
-H 'Authorization: Bearer <>'
次に例を示します。
curl -X DELETE \
https://resource-controller.cloud.ibm.com/v2/resource_instances/793b4f27-7733-4803-917f-de8e055e2deb \
-H 'Authorization: Bearer <>'
CLI を使用した独立したバックアップの削除
有効期限が切れる前に独立したバックアップを削除するには、次のコマンドを実行してください
ibmcloud resource service-instance-delete <BACKUP_CRN> --force
次に例を示します。
ibmcloud resource service-instance-delete e318275d-f860-4e4e-a63b-271fb4400c26 --force
バックアップには、インフラストラクチャレベルの増分ボリュームスナップショットが使用されます。 その結果、バックアップを削除すると、残りのバックアップの容量が増える可能性があります。
バックアップの削除は取り消し不能であり、元に戻すことはできません。 削除する前に、そのバックアップデータがもう必要ないことを確認してください。
次のステップ
- バックアップの料金 についてご確認ください。
- バックアップに関するよくある質問(FAQ) を確認してください。
- バックアップ管理における 自身の責任 を理解してください。
結合バックアップからの移行
結合バックアップから独立バックアップへの移行方法は、データベースサービスによって異なります:
独立したバックアップ機能を備えたデータベース
| データベース | リージョン |
|---|---|
| PostgreSQL | au-syd, ca-mon, eu-de, eu-es, in-che, in-mum, us-east, us-south, eu-gb, br-sao, jp-osa, jp-tok,
ca-tor |
| MongoDB エンタープライズ | au-syd, ca-mon, eu-de, eu-es, in-che, in-mum, us-east, us-south, eu-gb, br-sao, jp-osa, jp-tok,
ca-tor |
| MongoDB シャーディング | au-syd, ca-mon, eu-de, eu-es, in-che, in-mum, us-east, us-south, eu-gb, br-sao, jp-osa, jp-tok,
ca-tor |
| Redis | au-syd, ca-mon, eu-de, eu-es, in-che, in-mum, us-east, us-south, eu-gb, br-sao, jp-osa, jp-tok,
ca-tor |
| Elasticsearch | au-syd, ca-mon, eu-de, eu-es, in-che, in-mum, us-east, us-south, eu-gb, br-sao, jp-osa, jp-tok,
ca-tor |
| Elasticsearch 標準 | au-syd, ca-mon, eu-de, eu-es, in-che, in-mum, us-east, us-south, eu-gb, br-sao, jp-osa, jp-tok,
ca-tor |
表に記載されているデータベースは、指定されたリージョンにおいて、結合バックアップから独立バックアップへの移行が進められています。
対象となるデータベースおよびリージョンについては、段階的に独立したバックアップ機能が有効化されます。
30日間の移行期間中は:
- 結合バックアップと独立バックアップが共存しています。
- 新しいバックアップはすべて、独立したバックアップとして作成されます。
- 既存の連携バックアップは引き続き機能し、30日後に自動的に削除されます。
- UIには、両方のバックアップタイプが表示されます。
- アクションは不要です。 この移行は自動的に行われます。
- 30日間の移行期間が終了すると、独立したバックアップのみが残ります。
MySQL
Databases for MySQL 一般提供時点では、独立したバックアップのみをサポートしています。 MySQL の導入においては、連動したバックアップも移行期間も存在しません。
独立したバックアップの請求
独立したバックアップは、個別のサービスインスタンスとして課金されます:
- 無料割り当て :データベース展開のプロビジョニングされたディスク容量の合計に相当する、無料のバックアップストレージが提供されます。
- 超過料金 :無料枠を超える利用分については、別途料金が課金されます。
- 請求明細の表示 :バックアップ費用は、請求明細書上で個別の明細項目として表示されます。
バックアップコピーは全額課金対象となり、無料枠の対象にはなりません。
価格の詳細については、「 価格 」をご覧ください。
セキュリティーおよびコンプライアンス
独立したバックアップは、データベースインスタンスと同じセキュリティ基準を維持します:
- 保存時の暗号化 :すべてのバックアップは、 IBM が管理する鍵、または Key Protect を通じてお客様ご自身の鍵のいずれかを使用して暗号化されます。
- 転送中の暗号化 :バックアップの作成および復元処理中に、データは暗号化されます。
- アクセス制御 :IAMポリシーにより、バックアップの作成、表示、復元ができるユーザーを制御します。 詳細については、「 独立したバックアップの IAM 権限 」を参照してください。
制限および制約事項
以下の制限に注意してください。
- 一括操作(一括コピー、一括削除)はサポートされていません。
- 独立したバックアップはダウンロードできません。ローカルバックアップには、データベース固有のツール(例:
mysqldump)を使用してください。 - バックアップの保存期間は、現時点では設定できません(デフォルトは30日間)。
- データベースインスタンスごとに、最大50件のオンデマンドバックアップを作成できます。
- MySQL では、オンデマンドバックアップはサポートされていません。