IBM Cloud Docs
Managing Cloud Databases backups

Managing Cloud Databases backups

Backups for Cloud Databases instances are accessible from the Backups tab of your instance's dashboard. 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.
  • IBM Cloud® Databases for DataStax does not support reenablement. After an instance is disabled, that instance must be restored from a backup.

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

Backups in the UI

The backup types have their respective tabs, either On-demand or Automatic. Each backup is listed with its type and when the backup was taken. Click the timestamp to change its format between elapsed time, local time, and Coordinated Universal Time.

List of backups on the Backups tab
Figure 1. List of backups on the Backups tab

Click the backup to reveal information for that specific backup, including its full ID. A Restore button, or 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 example-instance

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

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 tab of your instance then click Back up now. A message is displayed that a backup is in progress, and an on-demand backup is added to the list of available backups.

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

ibmcloud cdb deployment-backup-now example-deployment

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. Use the dialog box to 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.
  4. Click Restore. 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 <SERVICE_INSTANCE_NAME> <service-id> standard <region> -p '{"backup_id":"BACKUP_ID"}'

Change the value of SERVICE_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.

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

ibmcloud resource service-instance-create <SERVICE_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_memory_allocation_mb":"DESIRED_MEMORY_IN_MB", "members_cpu_allocation_count":"NUMBER_OF_CORES"}'

A pre-formatted command for a specific backup is available in detailed view of the backup on the Backups 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 SERVICE_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": "<SERVICE_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.

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.

If you need to adjust resources or use a Key Protect key, add any of the optional parameters key_protect_key, members_disk_allocation_mb, members_memory_allocation_mb, and members_cpu_allocation_count, and their preferred values to the body of the request.

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 SERVICE_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 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.

Table 1. 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

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, check out Backups FAQ.