--- name: databases-for-redis-howto-manage-backups title: Managing Cloud Databases backups description: An automatically scheduled backup is taken of your database every day. You can also trigger on-demand backups at any time. 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. last-updated: 2026-07-28 --- > ## Documentation Index > The table of contents for this documentation set is at https://cloud.ibm.com/docs/databases-for-redis?format=markdown > The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt > Use these files to discover more information as needed. # Managing Cloud Databases backups {: #dashboard-backups} An automatically scheduled backup is taken of your database every day. You can also trigger on-demand backups at any time. 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. 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](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-key-protect&format=markdown#byok-for-backups). 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](https://www.postgresql.org/docs/9.6/static/backup-dump.html){: .external} is an effective tool for managing PostgreSQL backups. And for MySQL, you can use [mysqldump](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html). For information on taking an on-demand backup, see [Taking an on-demand backup](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-dashboard-backups&interface=ui&format=markdown#ondemand-backup-ui). {: ui} For information on taking an on-demand backup, see [Taking an on-demand backup](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-dashboard-backups&interface=cli&format=markdown#ondemand-backup-cli). {: cli} For information on taking an on-demand backup, see [Taking an on-demand backup](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-dashboard-backups&interface=api&format=markdown#ondemand-backup-api). {: api} ## Backups in the UI {: #backup-ui} {: 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. ### Taking an on-demand backup in the UI {: #ondemand-backup-ui} {: 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. {: .tip} 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. ## Backups in the CLI {: #backup-ui-cli} {: 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`](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-cdb-reference&format=markdown#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`](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-cdb-reference&format=markdown#backup-show) command. For example, to view the backups for an instance named "example-instance", use the following command: ```sh ibmcloud cdb deployment-backups-list ``` {: .pre} 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: ```sh 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 ``` {: .pre} ### Taking an on-demand backup in the CLI {: #ondemand-backup-cli} {: 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. {: .tip} In the CLI, an on-demand backup is triggered with the [`cdb deployment-backup-now`](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-cdb-reference&format=markdown#deployment-backup-now) command. To check the backup status, use the `ibmcloud cdb backup-show` command. For example: ```sh ibmcloud cdb deployment-backup-now ibmcloud cdb backup-show ``` {: .pre} ## Backups in the Cloud Databases API {: #backup-ui-api} {: api} For backups information in the Cloud Databases API, use the [`/deployments/{id}/backups`](https://cloud.ibm.com/apidocs/cloud-databases-api/cloud-databases-api-v5#listdeploymentbackups) endpoint to list the instance's backups. To get information about a specific backup, use the [`/backups/{backup_id}`](https://cloud.ibm.com/apidocs/cloud-databases-api/cloud-databases-api-v5#getbackupinfo) endpoint. ### Taking an on-demand backup in the API {: #ondemand-backup-api} {: 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. {: .tip} In the API, sending a POST to the [`/deployments/{id}/backups`](https://cloud.ibm.com/apidocs/cloud-databases-api/cloud-databases-api-v5#startondemandbackup) endpoint triggers an on-demand backup. ## Restoring a backup {: #restore-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. {: .tip} ### Restoring a backup in the UI {: #restore-backup-ui} {: 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 `-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 {: #restore-backup-cli} {: 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`](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resource&format=markdown#ibmcloud_resource_service_instance_create) command. ```sh ibmcloud resource service-instance-create standard --service-endpoints -p '{"backup_id":"BACKUP_ID"}' ``` {: .pre} * 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](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-for-mongodb-hosting-models&interface=cli&format=markdown) as your original deployment. #### Optional parameters {: #hosting-model-cli} {: cli} 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: ```sh ibmcloud resource service-instance-create standard -p '{"backup_id":"BACKUP_ID","key_protect_key":"KEY_PROTECT_KEY_CRN", "members_disk_allocation_mb":"DESIRED_DISK_IN_MB", "members_host_flavor": "", "members_memory_allocation_mb":"DESIRED_MEMORY_IN_MB", "members_cpu_allocation_count":"NUMBER_OF_CORES"}' ``` {: .pre} The `members_host_flavor` value can be either "multitenant" or an appropriate-sized Isolated Compute host (see [the list of available values](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-for-mongodb-hosting-models&interface=cli&format=markdown#hosting-models-iso-compute-sizing-cli)). Only specify `members_memory_allocation_mb` or `members_cpu_allocation_count` if you use "multitenant" hosting. {: note} 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. {: .tip} 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. ```sh `ibmcloud resource service-instance-create databases-for-mysql standard us-south -p '{"backup_id":"", "version": ""}' ``` To see a list of versions available, run `ibmcloud cdb deployables`. ### Add `async_restore` parameter (new) - PostgreSQL only {: #async_restore-pg} {: cli} A new optional parameter, `async_restore` was added to the restore `parameters` block. `async_restore` (boolean) — default: false. When set to true, the restore is initiated as an asynchronous operation, which helps to reduce end-to-end restore time. ```sh `ibmcloud resource service-instance-create databases-for-postgresql standard us-south -p '{"point_in_time_recovery_deployment_id":"", "point_in_time_recovery_time":"", version": "", "async_restore": true }' ``` {: .pre} Example: ```sh `ibmcloud resource service-instance-create 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 }' ``` {: .pre} An asynchronous restore can only be requested when the source and target PostgreSQL databases are running the same major version. Restores across different major versions are not supported. If the `async_restore` parameter is not specified, the service defaults to performing the restore synchronously, which is the current behavior. ### Restoring a backup through the API {: #restore-backup-api} {: api} The [Resource Controller API](https://cloud.ibm.com/apidocs/resource-controller/resource-controller){: external} supports provisioning and restoring database instances. The create request is a `POST` to the [`/resource_instances`](https://cloud.ibm.com/apidocs/resource-controller/resource-controller#create-resource-instance) endpoint. ```sh curl -X POST \ https://resource-controller.cloud.ibm.com/v2/resource_instances \ -H 'Authorization: Bearer <>' \ -H 'Content-Type: application/json' \ -d '{ "name": "", "target": "", "resource_group": "", "resource_plan_id": "", "parameters":{ "backup_id": "" } }' ``` {: .pre} The parameters `name`, `target`, `resource_group`, and `resource_plan_id` are all required, and `backup_id` is the backup that you want to restore. {: important} * 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 previous command restores a backup to a machine of the same configuration and on the same [hosting model](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-for-mongodb-hosting-models&interface=cli&format=markdown) as your original deployment. #### Optional parameters {: #hosting-model-api} {: api} 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: ```sh curl -X POST \ https://resource-controller.cloud.ibm.com/v2/resource_instances \ -H 'Authorization: Bearer <>' \ -H 'Content-Type: application/json' \ -d '{ "name": "", "target": "", "resource_group": "", "resource_plan_id": "", "parameters":{ "backup_id": "", "members_host_flavor": "", "version": "" } }' ``` {: .pre} The `members_host_flavor` value can be either "multitenant" or an appropriate-sized Isolated Compute host (see [the list of available values](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-for-mongodb-hosting-models&interface=cli&format=markdown#hosting-models-iso-compute-sizing-cli)). Only specify `members_memory_allocation_mb` or `members_cpu_allocation_count` if you use "multitenant" hosting. {: note} 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. {: note} ### Add async_restore parameter (new) - PostgreSQL only {: #async_restore} {: api} A new optional parameter, `async_restore` was added to the restore `parameters` block. `async_restore` (boolean) — default: false. When set to true, the restore is initiated as an asynchronous operation, which helps to reduce end-to-end restore time. ```sh curl -X POST \ https://resource-controller.cloud.ibm.com/v2/resource_instances \ -H 'Authorization: Bearer <>' \ -H 'Content-Type: application/json' \ -d '{ "name": "", "target": "", "resource_group": "", "resource_plan_id": "", "parameters":{ "point_in_time_recovery_deployment_id": "", "point_in_time_recovery_time": "", "version": "", "async_restore": true } }' ``` {: .pre} An asynchronous restore can only be requested when the source and target PostgreSQL databases are running the same major version. Restores across different major versions are not supported. If the `async_restore` parameter is not specified, the service defaults to performing the restore synchronously, which is the current behavior. ### Restoring a backup through Terraform {: #restore-backup-tf} {: 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`](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/database#backup_id){: external}. 1. Set your `version` in the version attribute. For more information, see [`version`](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/database#version){: external}. The code looks like: ```tf resource "ibm_database" "" { name = "" service = "" plan = "" location = "" version = "" backup_id = "" } ``` {: codeblock} For more information, see the [Cloud Databases Terraform Registry](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/database_backups){: external}. ### Fast PG Restore(async_restore) through Terraform - PostgreSQL only {: #async_restore_terraform} {: terraform} 1. A new optional parameter, `async_restore` was added to the block. 2. `async_restore` (boolean) — default: false. When set to true, the restore is initiated as an asynchronous operation, which helps to reduce end-to-end restore time. 3. This parameter is only applicable when restoring a PostgreSQL instance. The code looks like the following: ```tf data "ibm_resource_group" "group" { name = "" } resource "ibm_database" "" { name = "" location = "" 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 = "" point_in_time_recovery_deployment_id = "" version = "" } ``` {: codeblock} An asynchronous restore can only be requested when the source and target PostgreSQL databases are running the same major version. Restores across different major versions are not supported. If the `async_restore` parameter is not specified, the service defaults to performing the restore synchronously, which is the current behavior. ## Backups and restoration {: #backup-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](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-cdb-reference&format=markdown#backup-show) and the [Cloud Databases API](https://cloud.ibm.com/apidocs/cloud-databases-api/cloud-databases-api-v5#getbackupinfo). * 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-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 | {: caption="Instance and backup regions" caption-side="bottom"} For more details about Cloud Databases Object Storage locations, review the location's [documentation](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpoints&format=markdown#endpoints-geo). ## Business continuity and disaster recovery {: #backup-locations} Cloud Databases provides mechanisms to protect your data and restore service functions. For more information (including [Backup Storage Regions](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-bc-dr&format=markdown#bc-dr-single-region-backups){: external}), see [Understanding business continuity and disaster recovery for Cloud Databases](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-bc-dr&format=markdown){: external}. ## Point-in-Time Recovery {: #pitr-recovery-options} 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: - [IBM Cloud® Databases for PostgreSQL](https://cloud.ibm.com/docs/databases-for-postgresql?topic=databases-for-postgresql-pitr&format=markdown) - [IBM Cloud® Databases for MongoDB](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-for-mongodb-pitr&interface=ui&format=markdown) - [IBM Cloud® Databases for MySQL](https://cloud.ibm.com/docs/databases-for-mysql?topic=databases-for-mysql-pitr&format=markdown) ## Backups FAQ {: #backup-faq-reference} For frequently asked questions about backups, see the [Backups FAQ](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-faq-backups&format=markdown){: external}.