バックアップの主な特徴

• ライフサイクル ：バックアップはデータベースインスタンスのライフサイクルに紐づいており、インスタンスが削除されるとバックアップも削除されます
• 保存期間 ：バックアップは30日間保存されます
• 暗号化 ：バックアップデータは、 AES-256 による保存時暗号化が適用されます
• 復元 ：バックアップは、作成されたのと同じリージョン内でのみ復元できます
• 種類 ：自動（毎日）バックアップとオンデマンド（手動）バックアップの両方が利用可能です

バックアップに関する重要事項

• バックアップ・ストレージは暗号化されます。 暗号化キーの管理については、「 IBM® Key Protect 」の連携機能 をご覧ください。 それ以外の場合、バックアップは、インスタンスごとに自動的に生成される鍵を使用して暗号化されます。
• バックアップは、復元を実行するユーザーが、そのバックアップへのアクセス権に加え、ソースアカウントとアカウントの両方へのアクセス権を持っている場合に限り、 アカウント。
• Cloud Databases バックアップはダウンロードできません。 ローカルバックアップが必要な場合は、適切なソフトウェアを使用してください。 たとえば、 pg_dump は、 PostgreSQL のバックアップを管理するための有効なツールです。

バックアップの削除は取り消し不能であり、元に戻すことはできません。 削除する前に、そのバックアップデータがもう必要ないことを確認してください。

オンデマンド・バックアップの実行

インスタンスに、スケーリングやデータベース、テーブル、コレクションの削除など、大幅な変更を加える予定がある場合は、オンデマンドバックアップが役立ちます。 また、スケジュールをバックアップする必要がある場合にも有益です。 オンデマンド・バックアップの保存期間は 30 日間です。

各インスタンスには、その総ディスク容量と同等のバックアップストレージが無料で提供されます。 バックアップストレージの使用量がディスク容量の合計を上回る場合、1ギガバイトごとに $0.095/month の超過料金が課金されます。 バックアップは圧縮されるため、オンデマンドバックアップを利用した場合でも、ほとんどのインスタンスでは割り当てられたクレジットを超過することはありません。

バックアップのリストア

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

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

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

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 postgresql-restore-abc databases-for-postgresql databases-for-postgresql-gen2-standard ca-mon -p  '{"dataservices":{"restore_backup_id":"crn:v1:bluemix:public:databases-for-postgresql:ca-mon:a/26b19aex04da4475b6e31205fa93248d:a1e247d8-01c2-3bbe-a5e6-fdb5eb872d2f:backup:f689275f-7da9-4e90-9055-70b02c575492"}}'

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

ハイドレーションが完了するまでは、IOパフォーマンスが低下した状態で、復元されたデータベースインスタンスに直ちにアクセスできるようになります。 復元されたインスタンスでは、ハイドレーションが完了するまでバックアップを作成することはできません。 プラットフォームのアクティビティ追跡イベントを使用して、水分補給の完了状況を追跡できます。 詳細については、「 プラットフォームイベントの一覧 」を参照してください。

アカウント復元

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

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

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

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

バックアップおよび復元に関する責任

• Cloud Databases 当社は、当該バックアップの復元、適時性、または有効性について責任を負いません。
• ユーザーとして実行するアクションが、現在割り振り中のメモリーやディスクなどの、バックアップの整合性を損なう場合があります。 ユーザーは、API を使用してバックアップが成功したことをモニターし、バックアップを定期的にリストアして、妥当性と保全性を確認することができます。 ユーザーは、 Cloud Databases リソースコントローラーのCLI および Cloud Databases リソースコントローラーのAPI から、直近にスケジュールされたバックアップの詳細を取得できます。
• 管理対象サービスとして、Cloud Databases はバックアップの状態をモニターし、可能な場合は修復を試みることができます。 復旧できない問題が発生した場合は、サポートまでご連絡ください。

事業継続性と災害復旧

Cloud Databases データを保護し、サービス機能を復旧するための仕組みを提供します。 詳細（ バックアップストレージリージョンを含む）については、 「 Cloud Databases の事業継続性と災害復旧について」 を参照してください。