Cloud Databasesバックアップの管理
毎日、データベースのバックアップが自動的にスケジュールされます。 オンデマンドバックアップはいつでも実行できます。 バックアップは、自動キーまたはBYOK(Bring Your Own Key)を使用する場合は独自のキーで暗号化されます。 Cloud Databasesの新しいインスタンスにバックアップをリストアできます。
Cloud Databasesのバックアップにアクセスするには、データベース・インスタンスのダッシュボードに移動し、[バックアップとリストア]タブを参照してください。
バックアップに関するその他の一般的な情報:
- 自動バックアップは毎日実行され、30日間のシンプルな保存スケジュールで保存されます。
- バックアップは削除できません。
- インスタンスを削除すると、そのバックアップは自動的に削除されます。
- 毎日のバックアップスケジュールは設定できません。
eu-de、eu-es、par-01を除き、バックアップは他のリージョンに復元可能である。これらのリージョンは、相互間でのみバックアップを復元できる。 例えば、par-01のバックアップはeu-deとeu-esの間にリストアできる。- バックアップ・ストレージは暗号化されます。 暗号化キーを管理するには、Key Protectの統合 を参照してください。 それ以外の場合、バックアップは、インスタンス用に自動的に生成された鍵を使用して暗号化されます。
- バックアップアカウント復元可能ですが、API 経由でのみ可能であり、かつ復元を実行するユーザーがソースアカウントとアカウントの両方へのアクセス権を持っている場合に限られます。
- Cloud Databases バックアップはダウンロードできない。 ローカルバックアップが必要な場合は、適切なソフトウェアを使用してください。 例えば、 pg_dumpは PostgreSQL のバックアップを管理するための効果的なツールです。 また、 MySQL,、 mysqldumpを 使うことができる。
オンデマンド・バックアップの取得については、オンデマンド・バックアップの取得 を参照してください。
オンデマンド・バックアップの取得については、オンデマンド・バックアップの取得 を参照してください。
オンデマンド・バックアップの取得については、オンデマンド・バックアップの取得 を参照してください。
UI でのバックアップ
UIで*「Backups and restore(バックアップとリストア)*」タブに移動すると、データベースの利用可能なバックアップがすべて表示されます。
バックアップの種類は、_オンデマンド_または_自動_のいずれかを選択できます。 バックアップはバックアップが実行されたときに 1 つずつ、そのタイプと共にリストされます。
バックアップをクリックすると、完全な ID を含めたその特定のバックアップの情報が表示されます。 復元オプションとして、「 復元 」ボタンまたはあらかじめフォーマットされたCLIコマンドが用意されています。
UIでオンデマンドバックアップを取る
データベース、テーブル、コレクションの拡張や削除など、インスタンスに大きな変更を加える予定がある場合は、オンデマンド・バックアップが便利です。 また、スケジュールをバックアップする必要がある場合にも有益です。 オンデマンド・バックアップの保存期間は 30 日間です。
各インスタンスには、その総ディスク容量と同等のバックアップストレージが無料で提供されます。 バックアップストレージの使用量がディスク容量の合計を上回る場合、1ギガバイトごとに $0.03/month の超過料金が課金されます。 バックアップは圧縮されるため、オンデマンドバックアップを利用した場合でも、ほとんどのインスタンスでは割り当てられたクレジット枠を超過することはありません。
UIで手動バックアップを作成するには、インスタンスの_[Backups and restore]_タブに移動し、[Create backup]をクリックします。 バックアップが進行中であることを示すメッセージが表示され、使用可能なバックアップのリストにこのオンデマンド・バックアップが追加されます。
CLI でのバックアップ
バックアップの一覧や個々のバックアップ情報には、 Cloud Databases のCLIプラグインおよび Cloud Databases のAPIからアクセスできます。
cdb deployment-backups-list コマンドを使用して、インスタンスで利用可能なすべてのバックアップの一覧を表示します。 特定のバックアップの詳細を取得するには、cdb backup-show コマンドを使用します。
たとえば、「example-instance」という名前のインスタンスのバックアップを表示するには、次のコマンドを実行します
ibmcloud cdb deployment-backups-list <INSTANCE_NAME_OR_CRN>
リストにあるバックアップの1つの詳細を確認するには、 deployment-backups-list のレスポンスにある「 ID 」フィールドからIDを取得し、それを backup-show コマンドで使用します:
ibmcloud cdb backup-show crn:v1:staging:public:cloud-databases:us-south:a/6284014dd5b487c87a716f48aeeaf99f:3b4537bf-a585-4594-8262-2b1e24e2701e:backup:a3364821-d061-413f-a0df-6ba0e2951566
CLIでオンデマンド・バックアップを取る
データベース、テーブル、コレクションの拡張や削除など、インスタンスに大きな変更を加える予定がある場合は、オンデマンド・バックアップが便利です。 また、スケジュールをバックアップする必要がある場合にも有益です。 オンデマンド・バックアップの保存期間は 30 日間です。
各インスタンスには、その総ディスク容量と同等のバックアップストレージが無料で提供されます。 バックアップストレージの使用量がディスク容量の合計を上回る場合、1ギガバイトごとに $0.03/month の超過料金が課金されます。 バックアップは圧縮されるため、オンデマンドバックアップを利用した場合でも、ほとんどのインスタンスでは割り当てられたクレジット枠を超過することはありません。
CLIでは、オンデマンド・バックアップは cdb deployment-backup-now コマンドでトリガーされます。 バックアップの状態を確認するには、 ibmcloud cdb backup-show コマンドを使用します。 以下に例を示します。
ibmcloud cdb deployment-backup-now <INSTANCE_NAME_OR_CRN>
ibmcloud cdb backup-show <INSTANCE_NAME_OR_CRN>
Cloud Databases API におけるバックアップ
Cloud Databases API におけるバックアップ情報については、 /deployments/{id}/backups エンドポイントを使用して、インスタンスのバックアップ一覧を取得します。 特定のバックアップに関する情報を取得するには、/backups/{backup_id} エンドポイントを使用します。
APIでオンデマンドバックアップを取る
データベース、テーブル、コレクションの拡張や削除など、インスタンスに大きな変更を加える予定がある場合は、オンデマンド・バックアップが便利です。 また、スケジュールをバックアップする必要がある場合にも有益です。 オンデマンド・バックアップの保存期間は 30 日間です。
各インスタンスには、その総ディスク容量と同等のバックアップストレージが無料で提供されます。 バックアップストレージの使用量がディスク容量の合計を上回る場合、1ギガバイトごとに $0.03/month の超過料金が課金されます。 バックアップは圧縮されるため、オンデマンドバックアップを利用した場合でも、ほとんどのインスタンスでは割り当てられたクレジット枠を超過することはありません。
API では、POST を /deployments/{id}/backups エンドポイントに送信すると、オンデマンド・バックアップがトリガーされます。
バックアップのリストア
バックアップは新しいインスタンスに復元されます。 新しいインスタンスのプロビジョニングが完了すると、バックアップファイル内のデータが新しいインスタンスに復元されます。
デフォルトでは、新しいインスタンスのディスク容量とメモリ容量は、復元元のバックアップが作成された時点のソースインスタンスと同じサイズに自動的に設定されます。 新しいインスタンスに割り当てられるリソースを調整するには、UI、CLI、またはAPIのオプションフィールドを使用して、新しいインスタンスのサイズを変更してください。 データとワークロードに応じて、十分なリソースを割り当てるようにしてください。インスタンスに十分なリソースが割り当てられていない場合、復元は失敗します。
バックアップの復元中は、ソースインスタンスを削除しないでください。 古いインスタンスを削除する前に、新しいインスタンスのプロビジョニングが完了し、バックアップが復元されるまでお待ちください。 インスタンスを削除すると、そのバックアップも削除されます。
UI でのバックアップのリストア
新規サービス・インスタンスにバックアップをリストアするには、以下のようにします。
- 対応する行をクリックして、リストアしようとしているバックアップのオプションを展開します。
- **「復元」**をクリックします。
- Provisioning(プロビジョニング) ページで、利用可能なオプションから選択します。
- 新しいインスタンスには自動的に「
<name>-restore-[timestamp]」という名前が付けられますが、名前を変更することもできます。 - また、新しいインスタンスを設置する地域を選択することもできます。 リージョンを超えたリストアもサポートされていますが、
eu-deリージョンから、または eu-de リージョンへのリストアは例外です。 - 新しいインスタンスのリソースを拡張するか縮小するか、初期のリソース割り当てを選択できます。 さらに専用コアを有効または無効にすることもできます。 リソース量を減らすと、プロビジョニングに失敗したり、データベースが正しく機能しなくなる可能性があることに注意してください。
- 新しいインスタンスには自動的に「
- バックアップの復元をクリックします。 「バックアップからのリストアを開始しました (restore from backup started)」というメッセージが表示されます。 「 新しいインスタンスが利用可能になりました 」をクリックすると、 _リソース一覧_が表示されます。
CLI でのバックアップのリストア
リソースコントローラーはデータベースインスタンスのプロビジョニングをサポートしており、プロビジョニングと復元はリソースコントローラーのCLIが担当します。 resource service-instance-create コマンドを使用します。
ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID> standard <REGION> --service-endpoints <ENDPOINT-TYPE> -p '{"backup_id":"BACKUP_ID"}'
instance_nameの値を、新しいインスタンスに付けたい名前に変更してください。service-idは、 databases-for-postgresql や messages-for-rabbitmq といったインスタンスのタイプです。regionは、新しいインスタンスを配置したい場所を指します。これは、ソースインスタンスとは異なるリージョンでも構いません。 別のリージョンを使用するクロスリージョン・リストアがサポートされます (ただし、eu-deへのリストア、または eu-de からのリストアは除きます)。backup_idは、リストアしようとしているバックアップです。
前のコマンドは、元の配置と同じ構成で同じ ホスティングモデル 上のマシンにバックアップをリストアします。
オプション・パラメーター
オプション・パラメーターは CLI を介して使用できます。 リソースのカスタマイズ、ホスティングモデルの変更、または新しいインスタンスでのBYOK暗号化に Key Protect キーを使用する必要がある場合は、これらをご利用ください。 以下の例を参照してください。
ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID> standard <REGION> -p
'{"backup_id":"BACKUP_ID","key_protect_key":"KEY_PROTECT_KEY_CRN", "members_disk_allocation_mb":"DESIRED_DISK_IN_MB", "members_host_flavor": "<VALUE>", "members_memory_allocation_mb":"DESIRED_MEMORY_IN_MB", "members_cpu_allocation_count":"NUMBER_OF_CORES"}'
members_host_flavor の値は、"multitenant "または適切な大きさのIsolated Computeホストのいずれかになります(使用可能な値のリスト を参照してください)。 マルチテナント」ホスティングを使用する場合は、「members_memory_allocation_mb または「members_cpu_allocation_count 指定してください。
特定のバックアップ用の定型コマンドは、インスタンスのダッシュボードにある 「バックアップと復元 」タブの、そのバックアップの詳細ビューで確認できます。
デフォルトでは、バックアップからのリストアは、リストア元のインスタンスのバージョンではなく、データベース・タイプの優先バージョンを持つインスタンスを規定します。 次の例のように、パラメータ・オブジェクトにバージョンを追加することでバージョンを指定することができる。
`ibmcloud resource service-instance-create <INSTANCE_NAME> databases-for-mysql standard us-south -p '{"backup_id":"<BACKUP_ID>", "version": "<VERSION>"}'
利用可能なバージョンのリストを見るには、ibmcloud cdb deployables.
パラメータの async_restore 追加(新規) - PostgreSQL のみ
restore parameters ブロックに新しいオプションパラメータが追加されました async_restore。
async_restore (ブール値) — デフォルト: false。 trueに設定すると、復元は非同期操作として開始され、エンドツーエンドの復元時間の短縮に役立ちます。
`ibmcloud resource service-instance-create <INSTANCE_NAME> databases-for-postgresql standard us-south -p '{"point_in_time_recovery_deployment_id":"<SOURCE_CRN>", "point_in_time_recovery_time":"<PITR_TIME>", version": "<VERSION>", "async_restore": true }'
次に例を示します。
`ibmcloud resource service-instance-create <INSTANCE_NAME> databases-for-postgresql standard us-south -p '{"point_in_time_recovery_deployment_id":"test_crn", "point_in_time_recovery_time":"2025-12-08T17:08:32Z", version": "17", "async_restore": true }'
非同期復元は、ソースデータベースとターゲット PostgreSQL データベースが同じメジャーバージョンを実行している場合にのみ要求できます。 異なるメジャーバージョン間の復元はサポートされていません。 パラメータ async_restore が指定されていない場合、サービスはデフォルトで復元を同期的に実行します。これが現在の動作です。
API でのバックアップのリストア
リソースコントローラAPIは、データベースインスタンスのプロビジョニングとリストアをサポートします。 createリクエストは /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": "<INSTANCE_NAME>",
"target": "<REGION>",
"resource_group": "<YOUR-RESOURCE-GROUP>",
"resource_plan_id": "<SERVICE-ID>",
"parameters":{
"backup_id": "<BACKUP_ID>"
}
}'
パラメーター、name、target、resource_group、resource_plan_id はすべて、必須パラメーターです。また、backup_id はリストアするバックアップです。
nameの値を、新しいインスタンスに付けたい名前に変更してください。resource_plan_idは、 databases-for-postgresql や messages-for-rabbitmq といったインスタンスのタイプです。targetとは、新しいインスタンスを配置したいリージョンのことで、ソースインスタンスとは異なるリージョンでも構いません。 リージョンを超えたリストアもサポートされていますが、eu-deリージョンから、または eu-de リージョンへのリストアは例外です。backup_idは、リストアしようとしているバックアップです。
前のコマンドは、元のデプロイメントと同じ構成で、同じ ホスティングモデル を採用しているマシンにバックアップを復元します。
オプション・パラメーター
API を通じて、オプションのパラメータを利用できます。 リソースのカスタマイズ、ホスティング・モデルの変更、特定のバージョンへのデプロイ、新しいインスタンスでの BYOK 暗号化にKey Protectキーを使用する必要がある場合に使用します。
リソースを調整する必要がある場合は、オプションのパラメータ「key_protect_key、「members_disk_allocation_mb、「members_host_flavor、「members_memory_allocation_mb、「members_cpu_allocation_count、「version いずれかと、それらの望ましい値をリクエスト本体に追加する。 以下の例を参照してください。
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":{
"backup_id": "<BACKUP_ID>",
"members_host_flavor": "<members_host_flavor_value>",
"version": "<VERSION_NUMBER>"
}
}'
members_host_flavor の値は、"multitenant "または適切な大きさのIsolated Computeホストのいずれかになります(使用可能な値のリスト を参照してください)。 マルチテナント」ホスティングを使用する場合は、「members_memory_allocation_mb または「members_cpu_allocation_count 指定してください。
デフォルトでは、バックアップからのリストアは、リストア元のインスタンスのバージョンではなく、データベース・タイプの優先バージョンを持つインスタンスを規定します。 parametersオブジェクトに'version 値を追加することで、バージョンを指定することができる。
async_restore パラメータを追加(新規) - PostgreSQL のみ
restore parameters ブロックに新しいオプションパラメータが追加されました async_restore。
async_restore (ブール値) — デフォルト: false。 trueに設定すると、復元は非同期操作として開始され、エンドツーエンドの復元時間の短縮に役立ちます。
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":{
"point_in_time_recovery_deployment_id": "<SOURCE_CRN>",
"point_in_time_recovery_time": "<PITR_TIME>",
"version": "<VERSION_NUMBER>",
"async_restore": true
}
}'
非同期復元は、ソースデータベースとターゲット PostgreSQL データベースが同じメジャーバージョンを実行している場合にのみ要求できます。 異なるメジャーバージョン間の復元はサポートされていません。 パラメータ async_restore が指定されていない場合、サービスはデフォルトで復元を同期的に実行します。これが現在の動作です。
Terraformでバックアップをリストアする
Terraformを使って、古いバージョンから新しいバージョンへのバックアップにリストアする。
コードは次のようになる:
resource "ibm_database" "<your-instance>" {
name = "<your_database_name>"
service = "<service>"
plan = "<plan>"
location = "<region>"
version = "<version>"
backup_id = "<backup_id>"
}
詳しくは、Cloud Databases Terraform Registryを参照のこと。
Terraformによる高速PGリストア(async_restore)- PostgreSQL のみ
-
新しいオプション・パラメーター、
async_restoreがブロックに追加された。 -
async_restore(ブール値) — デフォルト: false。 trueに設定すると、復元は非同期操作として開始され、エンドツーエンドの復元時間の短縮に役立ちます。 -
このパラメータは、 PostgreSQL インスタンスをリストアする場合にのみ適用される。
コードは以下のようになる:
data "ibm_resource_group" "group" {
name = "<your_group>"
}
resource "ibm_database" "<your-instance>" {
name = "<your_database_name>"
location = "<region>"
plan = "<plan>"
service = "databases-for-postgresql"
resource_group_id = data.ibm_resource_group.group.id
service_endpoints = "private"
async_restore = true
point_in_time_recovery_time = "<PITR_TIME>"
point_in_time_recovery_deployment_id = "<SOURCE_CRN>"
version = "<VERSION_NUMBER>"
}
非同期復元は、ソースデータベースとターゲット PostgreSQL データベースが同じメジャーバージョンを実行している場合にのみ要求できます。 異なるメジャーバージョン間の復元はサポートされていません。 パラメータ async_restore が指定されていない場合、サービスはデフォルトで復元を同期的に実行します。これが現在の動作です。
バックアップとリストア
- Cloud Databases 当社は、当該バックアップの復元、適時性、または有効性について責任を負いません。
- ユーザーとして実行するアクションが、現在割り振り中のメモリーやディスクなどの、バックアップの整合性を損なう場合があります。 ユーザーは、API を使用してバックアップが成功したことをモニターし、バックアップを定期的にリストアして、妥当性と保全性を確認することができます。 ユーザーは Cloud Databases CLI plug-in と Cloud Databases API から直近にスケジュールされたバックアップの詳細を取り出すことができる。
- 管理対象サービスとして、Cloud Databases はバックアップの状態をモニターし、可能な場合は修復を試みることができます。 回復できない問題が発生した場合は、サポートにお問い合わせください。
バックアップ・ロケーション
バックアップ・ロケーションは、データベース・リージョンごとに異なります。 バックアップ・リージョンの場所がデータ・ロケーションの要件と一致していることを確認します。
| インスタンスのリージョン | バックアップ領域 |
|---|---|
| ダラス | US クロス・リージョナル Object Storage |
| ワシントン D.C. | US クロス・リージョナル Object Storage |
| ロンドン | EU クロス・リージョナル Object Storage |
| フランクフルト | EU クロス・リージョナル Object Storage |
| 東京 | AP クロス・リージョナル Object Storage |
| 大阪 | AP クロス・リージョナル Object Storage |
| シドニー | AP クロス・リージョナル Object Storage |
| トロント | モントリオール Object Storage |
| チェンナイ | チェンナイ Object Storage |
| サンパウロ | サオ・パオロ Object Storage |
| マドリッド | EU クロス・リージョナル Object Storage |
Cloud Databases Object Storage のロケーションについて詳しくは、ロケーションの資料を確認してください。
事業継続性と災害復旧
Cloud Databases データを保護し、サービス機能を復旧するための仕組みを提供します。 詳細(バックアップストレージリージョンを含む)については、Cloud Databasesの事業継続と災害復旧についてを参照してください。
ポイント・イン・タイム・リカバリー
ポイント・イン・タイム・リカバリ(PITR)では、インスタンスは継続的にインクリメンタルにバックアップされ、トランザクションを再生して、バックアップからリストアされた新しいインスタンスを過去7日間の任意の時点に戻すことができます。Cloud Databasesは以下のサービスでポイントインタイムリカバリ(PITR)を提供しています:
バックアップ FAQ
バックアップに関するよくある質問については、バックアップFAQをご覧ください。