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)」というメッセージが表示されます。 Your new instance is available now をクリックすると、 _リソース・リストに_移動します。
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 指定してください。
インスタンスのダッシュボードの 「Backups and restore(バックアップとリストア) 」タブにあるバックアップの詳細表示で、特定のバックアップ用にあらかじめフォーマットされたコマンドが利用できます。
デフォルトでは、バックアップからのリストアは、リストア元のインスタンスのバージョンではなく、データベース・タイプの優先バージョンを持つインスタンスを規定します。 次の例のように、パラメータ・オブジェクトにバージョンを追加することでバージョンを指定することができる。
`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 (boolean)- デフォルト: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 (boolean)- デフォルト: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(boolean)- デフォルト: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をご覧ください。