Managing independent backups

Automatic backup creation

When you provision a Gen 2 Cloud Databases instance, the system automatically creates independent backup instances for your daily scheduled backups. These backups:

• Are created daily according to your backup schedule
• Persist for 30 days by default
• Are managed automatically by the service
• Appear in your Resource List and Database Hub

On-demand backup creation

You can create on-demand independent backups at any time using the IBM Cloud Resource Controller. These backups:

• Are created immediately upon request
• Follow the same retention policies as automatic backups
• Can be manually deleted before expiration
• Are useful before major changes or migrations

Backup lifecycle

Independent backups follow this lifecycle:

1. Provisioning: Backup instance is created (automatically or on-demand)
2. Active: Backup is available for restore operations
3. Expiration: Backup reaches end of retention period (30 days default)
4. Deletion: Backup is automatically deleted or manually removed

Unlike coupled backups, independent backups can be manually deleted at any time through the Resource Controller, giving you greater control over your backup data and associated costs.

Configuring the database instance for independent backups

You can configure the following features on the database instance:

You can set the allowed configuration in the provision parameters of the database instance. For example, the following configuration sets the backups to be preserved even after the database is deleted:

ibmcloud resource service-instance-create \
  <DATABASE_INSTANCE_NAME> \
  <DATABASE_SERVICE_NAME> \
  <DATABASE_SERVICE_PLAN_NAME> \
  <REGION> \
  -g <RESOURCE_GROUP> \
  -p '{
    "dataservices": {
      "backups": {"preserve": true}
    }
  }'

Restoring from an independent backup

Independent backups can be restored to a new database instance even if the source instance no longer exists, providing greater flexibility for disaster recovery and data retention scenarios.

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 default disk size and same host size 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 or the backup contains more storage than the default disk size and a disk size is not specified, the restore fails.

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

You have immediate access to the restored database instance, but I/O performance is reduced until hydration completes. Backups cannot be created on the restored instance until hydration is complete. You can track hydration progress by using platform Activity Tracker events. For more information, see at-events.

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 mysql-restore-abc databases-for-mysql databases-for-mysql-gen2-standard ca-mon -p  '{"dataservices":{"restore_backup_id":"crn:v1:bluemix:public:databases-for-mysql: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>"
    }
  }'

Backup encryption

Independent backups are encrypted at rest with the same encryption as the database instance. If you use Key Protect to manage your encryption for the database, your backups are encrypted with the same key. For more information, see Key Protect integration.

When you restore a backup that was encrypted with a Key Protect key, you can use the same key or a different key. If you use a different key, the new instance is encrypted with the new key.

Cross-account restore

Independent backups can be restored across IBM Cloud accounts, enabling scenarios such as:

• Restoring production data to a development account for testing
• Migrating databases between organizational units
• Disaster recovery to a separate account

To restore a backup to a different account:

1. The source account must grant the target account access to the backup resource
2. Use the backup CRN when creating the new instance in the target account
3. Ensure the target account has appropriate IAM permissions

For more information about cross-account restore, see Cross-account restore.

MySQL

Databases for MySQL supports only independent backups from general availability. There are no coupled backups and no transition period for MySQL deployments.