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
, andpar-01
, which can restore backups only between each other. For example,par-01
backups can be restored to and betweeneu-de
andeu-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,
- Click in the corresponding row to expand the options for the backup that you want to restore.
- Click Restore.
- 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.
- The new instance is automatically named
- 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 fromeu-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 theeu-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.
- Set your
backup_id
. For more information, seebackup_id
. - Set your
version
in the version attribute. For more information, seeversion
.
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 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.