| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2025-11-03 |
bucket, vault, management |
cloud-object-storage |
{{site.data.keyword.attribute-definition-list}}
{: #bvm-overview}
{{site.data.keyword.cos_full}} Backup gives users the ability to create point-in-time consistent backups of {{site.data.keyword.cos_full_notm}} buckets that are resilient to attackers, accidental deletion or modification. It is a policy-driven service that allows for cross-account and cross-region backup of {{site.data.keyword.cos_full_notm}} buckets.
Central to {{site.data.keyword.cos_full_notm}} Backup is a new user-managed {{site.data.keyword.cos_full_notm}} resource called a BackupVault. Backup vaults store backup data in a secure, unmodifiable manner that provides a high degree of data integrity. Backup vaults are provisioned within a {{site.data.keyword.cos_full_notm}} instance alongside buckets, but are managed and behave differently than buckets.
Backups are generated by setting a BackupPolicy on an {{site.data.keyword.cos_full_notm}} bucket that targets a BackupVault as a backup storage destination. When this policy is set {{site.data.keyword.cos_full_notm}} will immediately begin syncing existing data from the bucket to the BackupVault. Any new data written to the bucket will continuously be synced to the BackupVault. Data sync occurs as long as the policy exists and is in an active state. This continuous backup approach allows users to restore objects from any point in time. IBM targets up to one hour for objects to sync to backup, which translates to a Recovery Point Objectives (RPO) of one hour or less.
When a BackupPolicy becomes active, a resulting RecoveryRange is created in the target BackupVault. The initial creation of a RecoveryRange requires that all the existing data on the source bucket is synced to the BackupVault. The time it takes for the RecoveryRange to be created depends on the amount of data stored in the source bucket. {{site.data.keyword.cos_full_notm}} reports the status and % progress of the BackupPolicy while this initialization is in progress. Note that the resulting RecoveryRange is not visible until after it has been fully initialized.
Backup data in a BackupVault is represented as a list of recovery ranges. Each RecoveryRange defines a range in time for which point-in-time consistent backup coverage exists for a specific {{site.data.keyword.cos_full_notm}} bucket. This range in time is reported as start and end times that are continuously updated as new data is backed up and old data is expired. The end time moves forward as new data is synced to the RecoveryRange by the source bucket's backup policy. The start time moves forward as the recovery range's retention configuration causes old data to be deleted.
When created, the RecoveryRange's lifespan is entirely dictated by its retention configuration and the status of the BackupPolicy A RecoveryRange is only fully deleted when the BackupPolicy is removed and the retention configuration on the RecoveryRange has deleted all the data, causing the start time to become equal to the end time.
The data in a recovery range can be written to a {{site.data.keyword.cos_full_notm}} bucket through a Restore operation. When performing a restore, the point-in-time to restore-to must be specified, and must exist between the start and end times reported for the recovery range. This operation triggers {{site.data.keyword.cos_full_notm}} to write data from the BackupVault to a destination bucket.
The time it takes for a restore operation to complete depends on the amount of data that must be transferred from the BackupVault to the target bucket. {{site.data.keyword.cos_full_notm}} reports the status and % progress of the restore operation while it is in progress.
The objects restored represent the object versions that were current on the source bucket at the requested restore point-in-time. Only the current versions at the point-in-time are restored. No noncurrent versions are restored.
| Term | Description |
|---|---|
BackupVault |
A new {{site.data.keyword.cos_full_notm}} resource that stores backup data represented as RecoveryRanges. |
| Source bucket | The {{site.data.keyword.cos_full_notm}} bucket for which backup coverage is wanted. |
BackupPolicy |
A policy is set on the source bucket that triggers a new RecoveryRange to be created on the destination BackupVault. |
RecoveryRange |
A range in time for which backup coverage exists for a source bucket. This range extends forward in time as new data is written to the BackupVault. |
| Restore | A user-initiated operation by which a point in time within a RecoveryRange is written to a destination target bucket. |
| Target bucket | A {{site.data.keyword.cos_full_notm}} bucket that receives the recovery data from a Restore operation. |
{: #bvm-recovery}
Whereas periodic backup solutions take individual "snapshots" of data for a given point-in-time, {{site.data.keyword.cos_full_notm}} produces backup coverage of a bucket over a range of time, providing users the ability to restore to any specific point in time contained within a RecoveryRange. This more granular approach provides more flexibility for users, and the ability to achieve lower Recovery Point Objectives that are not limited by the amount of time it takes to scan a bucket for changes since the last backup.
RecoveryRanges are created within a BackupVault whenever a new BackupPolicy targeting the BackupVault is set on a {{site.data.keyword.cos_full_notm}} bucket. RecoveryRanges receives new data as long as the associated BackupPolicy is enabled and active. For details on creating and monitoring a BackupPolicy, see Configuring backups.
Users can list the RecoveryRanges present within a BackupVault using the following commands:
Example request
GET /backup_vaults/myBackupVault/recovery_ranges HTTP/1.1
Authorization: Bearer {token}
Content-Type: application/json
Host: config.cloud-object-storage.cloud.ibm.com{: codeblock}
Example response
{
"next": {
"token": "SWYwNTZMflFmZUgheGNcNHMuIm9OMTFz",
"href": "config.cloud-object-storage.cloud.ibm.com/v1/backup_vaults/mybackupvault/recovery_ranges?token=1znNRhmyheG-pm6mlMKFsoxcKXFnW1hgBb2_6ZReqHduL3rivfeBWHeyL-OaJvtfVZjKrgRVmODtOdVeQEXkKCxDWpA5hRWuv9WgTPR2eLIN9fbEaTxqdNO4dp0sQeHh4HO-13nTgRV_1QGiR1QFzREHX3wzquLn9o_1DZZAEP-vAY2V8d6BCA1z2krhpMfswKJ8r6UynUc0W5JHSH4auwJ6jC-h8sc8NEcQpHUx2Ep4oxebmtJMaycQSjLA3J2fdcYuysKq3YIcszDnPte0zwr25x5_GmBrxlgd2oesjfyTaLHfIg1g4TD0uH9m9aEAv"
},
"recovery_ranges": [
{
"recovery_range_id": "44d3dd41-d616-4d25-911a-9ef7fbf28aef",
"source_resource_crn": "crn:v1:bluemix:public:cloud-object-storage:global:a1229395:8dfbcba4e6a740e3866020847e525436:bucket:sourcebucket",
"backup_policy_name": "myBackupPolicy",
"range_start_time": "2024-06-02T12:00:00.000Z",
"range_end_time": "2024-06-03T12:00:00.000Z",
"range_create_time": "2024-06-02T12:00:00.000Z",
"retention": {
"delete_after_days": 100
}
},
{
"recovery_range_id": "6ff0d31c-7583-4463-8ae5-208752f5769c",
"source_resource_crn": "crn:v1:bluemix:public:cloud-object-storage:global:a1229395:8dfbcba4e6a740e3866020847e525436:bucket:sourcebucket",
"backup_policy_name": "myBackupPolicy",
"range_start_time": "2024-06-04T12:00:00.000Z",
"range_end_time": "2024-06-05T12:00:00.000Z",
"range_create_time": "2024-06-04T12:00:00.000Z",
"retention": {
"delete_after_days": 100
}
}
]
}{: #bvm-recovery-range-retention}
RecoveryRanges have a mandatory retention configuration that is set initially by using the BackupPolicy, and can be updated afterward on the BackupVault. The retention configuration consists of a DeleteAfterDays value, which controls the number of days to retain backup coverage. It effectively limits the number of days into the past that the RecoveryRange’s startTime can extend to. Data that falls past the RecoveryRanges start time is deleted in the background. Full deletion of a RecoveryRange occurs when the associated BackupPolicy is deleted and all data in the RecoveryRange is deleted by using its retention configuration.
Example request
GET /backup_vaults/myBackupVault/recovery_ranges/44d3dd41-d616-4d25-911a-9ef7fbf28aef HTTP/1.1
Authorization: Bearer {token}
Content-Type: application/json
Host: config.cloud-object-storage.cloud.ibm.com{: codeblock}
Example response
{
"recovery_range_id": "6ff0d31c-7583-4463-8ae5-208752f5769c",
"source_resource_crn": "crn:v1:bluemix:public:cloud-object-storage:global:a1229395:8dfbcba4e6a740e3866020847e525436:bucket:sourcebucket",
"backup_policy_name": "myBackupPolicy",
"range_start_time": "2024-06-04T12:00:00.000Z",
"range_end_time": "2024-06-05T12:00:00.000Z",
"range_create_time": "2024-06-04T12:00:00.000Z",
"retention": {
"delete_after_days": 100
}
}{: #bvm-access-control}
Actions within a BackupVault are controlled in the same manner as other resources within {{site.data.keyword.cos_full_notm}}.
See Getting Started with IAM, IAM overview and Service credentials for general details on how IAM works with {{site.data.keyword.cos_full_notm}}. IAM actions on BackupVaults are distinct from IAM actions on {{site.data.keyword.cos_full_notm}} buckets. The actions specific to BackupVaults are contained within the BackupReader and BackupManager roles.
{: #bvm-access-control-permission-backup}
For a BackupPolicy on a source bucket to write backup data into a BackupVault, the source bucket must have permission to perform the cloud-object-storage.backup-vault.sync action on the BackupVault. It is done by granting the source bucket’s service-instance permission to perform this action against the BackupVaults service-instance. The action is included within the Manager, Backup Manager and Backup Reader roles. This permission must always be present for a BackupPolicy to operate correctly. If this permission is revoked, then the BackupPolicy reports an error.
{: #bvm-access-control-permission-restore}
In order for a Restore operation to write objects to the target bucket, the BackupVault must have permission to perform the cloud-object-storage.bucket.restore_sync operation on the target bucket. It is done by granting the source BackupVault’s service-instance permission to perform this action against the target bucket’s service-instance. The permission is included within the Manager and Writer roles.