IBM Cloud Docs
Managing Cloud Databases backups

Managing Cloud Databases backups

An automatically scheduled backup is taken of your database every day. You can also do on-demand backups. Backups are encrypted either with an automatic key or your own key if you use Bring Your Own Key (BYOK). You can restore a backup to a new instance of Cloud Databases.

To access backups for Cloud Databases, go to your database instance's Dashboard, and see the Backups and restore tab.

Here is some additional general information about backups:

  • Automatic backups are performed daily and kept with a simple retention schedule of 30 days.
  • Backups cannot be deleted.
  • If you delete your instance, its backups are deleted automatically.
  • Daily backup scheduling is not configurable.
  • Backups are restorable to other regions, except for eu-de, eu-es, and par-01, which can restore backups only between each other. For example, par-01 backups can be restored to and between eu-de and eu-es.
  • Backup storage is encrypted. To manage the encryption keys, see Key Protect integration. Otherwise, backups are encrypted with a key that is automatically generated for your instance.
  • Backups are restorable across accounts, but only through the API and only if the user that is running the restore has access to both the source and destination accounts.
  • Cloud Databases backups are not downloadable. If you need a local backup, use the appropriate software. For example, pg_dump is an effective tool for managing PostgreSQL backups.

For information on taking an on-demand backup, see Taking an on-demand backup.

Backups in the UI

In the UI, navigate to the Backups and restore tab where you see a table with all available backups for your database.

The backup types can be either On-demand or Automatic. Each backup is listed with its type and when the backup was taken.

Click the backup to reveal information for that specific backup, including its full ID. A Restore button or a pre-formatted CLI command is there for restore options.

Backups in the CLI

You can access the list of backups and individual backup information from the Cloud Databases CLI plug-in and the Cloud Databases API.

Use the cdb deployment-backups-list command to view the list of all available backups for your instance. To get details about a specific backup, use the cdb backup-show command.

For example, to view the backups for an instance named "example-instance", use the following command:

ibmcloud cdb deployment-backups-list <INSTANCE_NAME_OR_CRN>

To see the details of one of the backups from the list, take the ID from the ID field of the deployment-backups-list response and use it with the backup-show command:

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

Backups in the Cloud Databases API

For backups information in the Cloud Databases API, use the /deployments/{id}/backups endpoint to list the instance's backups. To get information about a specific backup, use the /backups/{backup_id} endpoint.

Taking an on-demand backup in the UI

If you plan to make major changes to your instance, like scaling or removing databases, tables, collections, on-demand backups are useful. It can also be useful if you need to back up on a schedule. On-demand backups are kept for 30 days.

Instances come with backup storage equal to their total disk space at no cost. If your backup storage usage is greater than total disk space, each gigabyte is charged at an overage of $0.03/month. Backups are compressed, so even if you use on-demand backups, most instances do not exceed the allotted credit.

To create a manual backup in the UI, go to the Backups and restore tab of your instance then click Create backup. A message is displayed that a backup is in progress, and an on-demand backup is added to the list of available backups.

Taking an on-demand backup in the CLI

If you plan to make major changes to your instance, like scaling or removing databases, tables, collections, on-demand backups are useful. It can also be useful if you need to back up on a schedule. On-demand backups are kept for 30 days.

Instances come with backup storage equal to their total disk space at no cost. If your backup storage usage is greater than total disk space, each gigabyte is charged at an overage of $0.03/month. Backups are compressed, so even if you use on-demand backups, most instances do not exceed the allotted credit.

In the CLI, an on-demand backup is triggered with the cdb deployment-backup-now command.

ibmcloud cdb deployment-backup-now <INSTANCE_NAME_OR_CRN>

Taking an on-demand backup in the API

If you plan to make major changes to your instance, like scaling or removing databases, tables, collections, on-demand backups are useful. It can also be useful if you need to back up on a schedule. On-demand backups are kept for 30 days.

Instances come with backup storage equal to their total disk space at no cost. If your backup storage usage is greater than total disk space, each gigabyte is charged at an overage of $0.03/month. Backups are compressed, so even if you use on-demand backups, most instances do not exceed the allotted credit.

In the API, sending a POST to the /deployments/{id}/backups endpoint triggers an on-demand backup.

Restoring a backup

Backups are restored to a new instance. After the new instance finishes provisioning, your data in the backup file is restored into the new instance.

By default, the new instance is auto-sized to the same disk and memory allocation as the source instance at the time of the backup from which you are restoring. To adjust the resources that are allocated to the new instance, use the optional fields in the UI, CLI, or API to resize the new instance. Be sure to allocate enough for your data and workload; if the instance is not given enough resources, the restore fails.

Do not delete the source instance while the backup is restoring. Before you delete the old instance, wait until the new instance is provisioned and the backup is restored. Deleting an instance also deletes its backups.

Restoring a backup in the UI

To restore a backup to a new service instance,

  1. Click in the corresponding row to expand the options for the backup that you want to restore.
  2. Click Restore.
  3. On the Provisioning page, select from some available options.
    • The new instance is automatically named <name>-restore-[timestamp], but you can rename it.
    • You can also select the region where the new instance is located. Cross-region restores are supported, except for restoring into or out of the eu-de region.
    • You can choose the initial resource allocation, either to expand or shrink the resources on the new instance. You can also enable or disable dedicated cores. Note that if you decrease your resource amount, it may lead to provision failure or your database not functioning properly.
  4. Click Restore backup. A "restore from backup started" message appears. Clicking Your new instance is available now takes you to your Resources List.

Restoring a backup in the CLI

The Resource Controller supports provisioning of database instances, and provisioning and restoring are the responsibility of the Resource Controller CLI. Use the resource service-instance-create command.

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE-ID> standard <REGION> -p '{"backup_id":"BACKUP_ID"}'
  • Change the value of instance_name to the name that you want for your new instance.
  • The service-id is the type of instance, such as databases-for-postgresql or messages-for-rabbitmq.
  • The region is where you want the new instance to be located, which can be a different region from the source instance. Cross-region restores are supported, except for restoring to or from eu-de by using another region.
  • backup_id is the backup that you want to restore.

The previous command will restore a backup to a machine of the same configuration and on the same hosting model as your original deployment.

Optional parameters

Optional parameters are available through the CLI. Use them if you need to customize resources, change the hosting model, or use a Key Protect key for BYOK encryption on the new instance. See the following example:

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"}'

The members_host_flavor value can be either "multitenant" or an appropriate-sized Isolated Compute host (see the list of available values). Only specify members_memory_allocation_mb or members_cpu_allocation_count if you use "multitenant" hosting.

A pre-formatted command for a specific backup is available in detailed view of the backup on the Backups and restore tab of your instance's dashboard.

By default, restoring from a backup provisions an instance with the preferred version of the database type, not the version of the instance you restore from. You can specify a version by adding the version in the parameters object, as in the following example.

`ibmcloud resource service-instance-create <INSTANCE_NAME> databases-for-mysql standard us-south -p '{"backup_id":"<BACKUP_ID>", "version": "<VERSION>"}'

To see a list of versions available, run ibmcloud cdb deployables.

Restoring a backup through the API

The Resource Controller API supports provisioning and restoring database instances. The create request is a POST to the /resource_instances endpoint.

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>"
    }
  }'

The parameters name, target, resource_group, and resource_plan_id are all required, and backup_id is the backup that you want to restore.

  • Change the value of name to the name that you want for your new instance.
  • The resource_plan_id is the type of instance, such as databases-for-postgresql or messages-for-rabbitmq.
  • The target is the region where you want the new instance to be located, which can be a different region from the source instance. Cross-region restores are supported, except for restoring into or out of the eu-de region.
  • backup_id is the backup that you want to restore.

The above command will restore a backup to a machine of the same configuration and on the same hosting model as your original deployment.

Optional parameters

Optional parameters are available through the API. Use them if you need to customize resources, change the hosting model, deploy to a specific version, or use a Key Protect key for BYOK encryption on the new instance.

If you need to adjust resources, add any of the optional parameters key_protect_key, members_disk_allocation_mb, members_host_flavor, members_memory_allocation_mb, members_cpu_allocation_count, or version and their preferred values to the body of the request. See the following example:

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>"
    }
  }'

The members_host_flavor value can be either "multitenant" or an appropriate-sized Isolated Compute host (see the list of available values). Only specify members_memory_allocation_mb or members_cpu_allocation_count if you use "multitenant" hosting.

By default, restoring from a backup provisions an instance with the preferred version of the database type, not the version of the instance you restore from. You can specify a version by adding a version value in the parameters object.

Restoring a backup through Terraform

Use Terraform to restore to a backup from an older version to a new version.

  1. Set your backup_id. For more information, see backup_id.
  2. Set your version in the version attribute. For more information, see version.

The code looks like:

resource "ibm_database" "<your-instance>" {
  name                                 = "<your_database_name>"
  service                              = "<service>"
  plan                                 = "<plan>"
  location                             = "<region>"
  version                              = "<version>"
  backup_id                            = "<backup_id>"
}

For more information, see the Cloud Databases Terraform Registry.

Backups and restoration

  • Cloud Databases are not responsible for restoration, timeliness, or validity of said backups.
  • Actions that you take as a user can compromise the integrity of backups, such as under-allocating memory and disk. Users can monitor that backups are successful by using the API, and periodically restore a backup to ensure validity and integrity. Users can retrieve the most recent-scheduled backup details from the Cloud Databases CLI plug-in and the Cloud Databases API.
  • As a managed service, Cloud Databases monitors the state of your backups and can attempt to remediate when possible. If you encounter issues from which you cannot recover, contact support for more help.

Backup locations

Backup location differs per database region. Ensure that the backup region location matches your data location requirements.

Instance and backup regions
Instance region Backup region
Dallas US cross regional Object Storage
Washington D.C. US cross regional Object Storage
London EU cross regional Object Storage
Frankfurt EU cross regional Object Storage
Tokyo AP cross regional Object Storage
Osaka AP cross regional Object Storage
Sydney AP cross regional Object Storage
Toronto Montreal Object Storage
Chennai Chennai Object Storage
Sao Paolo Sao Paolo Object Storage
Madrid EU cross regional Object Storage

For more details about Cloud Databases Object Storage locations, review the location's documentation.

Business continuity and disaster recovery

Cloud Databases provides mechanisms to protect your data and restore service functions. For more information (including Backup Storage Regions), see Understanding business continuity and disaster recovery for Cloud Databases.

Point-in-Time Recovery

With Point-in-Time Recovery (PITR), the instance continuously backs up incrementally and can replay transactions to bring a new instance that is restored from a backup to any point in the last 7 days. Cloud Databases offers Point-In-Time Recovery (PITR) for the following services:

Backups FAQ

For frequently asked questions about backups, see the Backups FAQ.