Overview of Block Volume Backups

The backups feature of the Oracle Cloud Infrastructure Block Volume service lets you make a point-in-time snapshot of the data on a block volume. You can make a backup of a volume when it is attached to an instance or while it is detached. These backups can then be restored to new volumes either immediately after a backup or at a later time that you choose.

Backups are encrypted and stored in Oracle Cloud Infrastructure Object Storage, and can be restored as new volumes to any availability domain within the same region they are stored. This capability provides you with a spare copy of a volume and gives you the ability to successfully complete disaster recovery within the same region.

There are two ways you can initiate a backup, either by manually starting the backup, or by assigning a policy which defines a set backup schedule.

Manual Backups

These are on-demand one-off backups that you can launch immediately by following the steps described in Creating a Manual Backup for a Block Volume. When launching a manual backup, you can specify whether an incremental or a full backup should be performed. See Volume Backup Types for more information about backup types.

Manual backups do not expire, they are maintained until you delete them.

Policy-Based Backups

These are automated scheduled backups as defined by the backup policy assigned to the volume.

There are two kinds of backup policies:

See Policy-Based Backups for more information.


When a volume backup is created, the source volume's tags are automatically included in the volume backup. This also includes volumes with custom backup policies applied to create backups on a schedule. Source volume tags are automatically assigned to all backups when they are created. You can also apply additional tags to volume backups as needed.

When a volume backup is copied to a new region, tags are also automatically copied with the volume backup. When the volume is restored from a backup, the volume is restored with the source volume's tags.

Volume Backup Types

There are two backup types available in the Block Volume service:

  • Incremental: This backup type includes only the changes since the last backup.
  • Full: This backup type includes all changes since the volume was created.

For data recovery purposes, there is no functional difference between an incremental backup and a full backup. You can restore a volume from any of your incremental or full volume backups. Both backup types enable you to restore the full volume contents to the point-in-time snapshot of the volume when the backup was taken. You don't need to keep the initial full backup or subsequent incremental backups in the backup chain and restore them in sequence, you only need to keep the backups taken for the times you care about.

Backup Details

For incremental backups, they are a record of all the changes since the last backup. If the first backup on a volume is created as incremental, it is effectively a full backup. For full backups, they are a record of all the changes since the volume was created.

For example, in a scenario where you create a 16 TB block volume, modify 40 GB on the volume, and then launch a full backup of the volume, upon completion, the volume backup size is 40 GB. If you then modify an additional 4 GB and create an incremental backup, the unique size of the incremental backup will be 4 GB. If the full backup is deleted, the incremental backup will retain the full 44 GB necessary to restore the volume contents. In this example, if there was a third incremental backup of non-overlapping blocks, with a size of 1 GB, created after the second incremental backup, and then the full backup is deleted, the third backup would stay at a 1 GB size, and the second incremental backup size would be updated to 44 GB. The blocks are accounted for in the earliest backup that references them.


After a volume has been resized, the first backup on the resized volume will be a full backup. See Resizing a Volume for more information about volume resizing.

Planning Your Backup

The primary use of backups is to support business continuity, disaster recovery, and long-term archiving requirements. When determining a backup schedule, your backup plan and goals should consider the following:

  • Frequency: How often you want to back up your data.
  • Recovery time: How long you can wait for a backup to be restored and accessible to the applications that use it. The time for a backup to complete varies on several factors, but it will generally take a few minutes or longer, depending on the size of the data being backed up and the amount of data that has changed since your last backup.
  • Number of stored backups: How many backups you need to keep available and the deletion schedule for those you no longer need. You can only create one backup at a time, so if a backup is underway, it will need to complete before you can create another one. For details about the number of backups you can store, see Block Volume Capabilities and Limits.

The common use cases for using backups are:

  • Needing to create multiple copies of the same volume. Backups are highly useful in cases where you need to create many instances with many volumes that need to have the same data formation.

  • Taking a snapshot of your work that you can restore to a new volume at a later time.
  • Ensuring you have a spare copy of your volume in case something goes wrong with your primary copy.

Volume Backup Size

Volume backup size may be larger than the current volume usage. Some of the reasons for this could include the following:

  • Any part of a volume that has been written to is considered initialized, so will always be part of a volume backup.

  • Many operating systems write or zero out the content, which results in these blocks marked as used. The Block Volume service considers these blocks updated and includes them in the volume backup.

  • Volume backups also include metadata, which can be up to 1 GB in additional data. For example, in a full backup of a 256 GB Windows boot disk, you may see a backup size of 257 GB, which includes an additional 1 GB of metadata.

Copying Block Volume Backups Across Regions

You can copy block volume backups between regions using the Console, command line interface (CLI), SDKs, or REST APIs. For steps, see Copying a Volume Backup Between Regions. This capability enhances the following scenarios:

  • Disaster recovery and business continuity: By copying block volume backups to another region at regular intervals, it makes it easier for you to rebuild applications and data in the destination region if a region-wide disaster occurs in the source region.
  • Migration and expansion: You can easily migrate and expand your applications to another region.

You can also enable scheduled cross-region automated backups with user defined policies, see Scheduling Volume Backup Copies Across Regions.

To copy volume backups between regions, you must have permission to read and copy volume backups in the source region, and permission to create volume backups in the destination region. For more information see Required IAM Policy.

Once you have copied the volume backup to the new region you can then restore from that backup by creating a new volume from the backup using the steps described in Restoring a Backup to a New Volume.

Volume Backup Encryption

The Oracle Cloud Infrastructure Block Volume service always encrypts all block volumes, boot volumes, and volume backups at rest by using the Advanced Encryption Standard (AES) algorithm with 256-bit encryption.

The Oracle Cloud Infrastructure Vault service enables you to bring and manage your own keys to use for encrypting volumes and their backups. When you create a volume backup, the encryption key used for the volume is also used for the volume backup.

You can change the encrption key for the volume backup to another Vault encryption key, or to an Oracle-managed key. See Changing the Encryption Key for a Volume Backup for more information.

When you restore the backup to create a new volume you configure a new key, see Restoring a Backup to a New Volume. See also Vault.


By default, volumes restored from a volume backup or a volume group backup are configured to use Oracle-provided keys for encryption. For volumes restored from a volume backup, you can specify a customer-managed key for the new volume during the restore process. This option is not available for volumes restored from volume group backups, so the new volumes are restored with Oracle-provided keys. You can update the encryption keys for these volumes after they are restored, see Editing a Key to a Block Volume.

If you don't configure a volume to use the Vault service, the Block Volume service uses the Oracle-provided encryption key instead. This applies to both encryption at-rest and in-transit encryption.

Required IAM Policy for Volume Backups

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don't have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  to work in.

For administrators: The policy in Let volume admins manage block volumes, backups, and volume groups lets the specified group do everything with block volumes and backups. The policy in Let boot volume backup admins manage only backups further restricts access to just creating and managing backups.


When users create a backup from a volume or restore a volume from a backup, the volume and backup don't have to be in the same compartment . However, users must have access to both compartments.
If you're new to policies, see Getting Started with Policies and Common Policies. For reference material about writing policies for instances, cloud networks, or other Core Services API resources, see Details for the Core Services.

Best Practices When Creating Block Volume Backups

When creating and restoring from backups, keep in mind the following:

  • Before creating a backup, you should ensure that the data is consistent: Sync the file system, unmount the file system if possible, and save your application data. Only the data on the disk will be backed up. When creating a backup, after the backup state changes from REQUEST_RECEIVED to CREATING, you can return to writing data to the volume. While a backup is in progress, the volume that is being backed up cannot be deleted.
  • If you want to attach a restored volume that has the original volume attached, be aware that some operating systems do not allow you to restore identical volumes. To resolve this, you should change the partition IDs before restoring the volume. The steps to change an operating system's partition ID vary by operating system. For instructions, see your operating system's documentation.

See Creating a Manual Backup for a Block Volume and Restoring a Backup to a New Volume for more information.

Reducing Volume Backup Sizes with SCSI UNMAP

Oracle Cloud Infrastructure Block Volume supports SCSI UNMAP commands for both boot volumes and block volumes to reclaim unused space. Use these commands to reduce your backup sizes, resulting in faster backup restore times. See Support for SCSI UNMAP for more information.

Differences Between Block Volume Backups and Clones

Consider the following criteria when you decide whether to create a backup or a clone of a volume.

  Volume Backup Volume Clone
Description Creates a point-in-time backup of data on a volume. You can restore multiple new volumes from the backup later in the future. Creates a single point-in-time copy of a volume without having to go through the backup and restore process.
Use case

Retain a backup of the data in a volume, so that you can duplicate an environment later or preserve the data for future use.

Meet compliance and regulatory requirements, because the data in a backup remains unchanged over time.

Support business continuity requirements.

Reduce the risk of outages or data mutation over time.

Rapidly duplicate an existing environment. For example, you can use a clone to test configuration changes without impacting your production environment.

Speed Slower (minutes or hours) Faster (seconds)
Cost Lower cost Higher cost
Storage location Object Storage Block Volume
Retention policy Policy-based backups expire, manual backups do not expire No expiration
Volume groups Supported. You can back up a volume group. Supported. You can clone a volume group.

For background information and steps to clone a block volume, see Cloning a Block Volume.

Using the CLI or REST APIs to Customize and Manage the Lifecycle of Volume Backups

You can use the CLI, REST APIs, or the SDKs to automate, script, and manage volume backups and their lifecycle.

Using the CLI

This section provides basic sample CLI commands that you can use in a script, such as a cron job run by the cron utility on Linux-based operating systems, to perform automatic backups at specific times. For information about using the CLI, see Command Line Interface (CLI).

To create a manual backup of the specified block volume

Open a command prompt and run:

oci bv backup create --volume-id <block_volume_OCID> --display-name <Name> --type <FULL|INCREMENTAL>

For example:

oci bv backup create --volume-id  ocid1.volume.oc1..<unique_ID> --display-name "backup display name" --type FULL
To delete a block volume backup

Open a command prompt and run:

oci bv backup delete --volume-backup-id <volume_backup_OCID>

For example:

oci bv backup delete --volume-backup-id ocid1.volume.oc1..<unique_ID>
To create a manual backup of the specified boot volume

Open a command prompt and run:

oci bv boot-volume-backup create --volume-id <boot_volume_OCID> --display-name <Name> --type <FULL|INCREMENTAL>

For example:

oci bv boot-volume-backup create --volume-id  ocid1.volume.oc1..<unique_ID> --display-name "backup display name" --type FULL
To delete a boot volume backup

Open a command prompt and run:

oci bv backup delete --boot-volume-backup-id <boot_volume__backup_OCID>

For example:

oci bv backup delete --boot-volume-backup-id ocid1.volume.oc1..<unique_ID>
To list the Oracle-defined backup policies

Open a command prompt and run:

oci bv volume-backup-policy list
To assign an Oracle-defined backup policy to a boot or block volume

Open a command prompt and run:

oci bv volume-backup-policy-assignment create --asset-id <volume_OCID> --policy-id <policy_OCID>

For example:

oci bv volume-backup-policy-assignment create --asset-id  ocid1.volume.oc1..<unique_ID> --policy-id ocid1.volumebackuppolicy.oc1..<unique_ID>
To un-assign an Oracle-defined backup policy from a boot or block volume

Open a command prompt and run:

oci bv volume-backup-policy-assignment delete --policy-assignment-id <policy_assignment_OCID>

For example:

oci bv volume-backup-policy-assignment delete --policy-assignment-id ocid1.volumebackuppolicyassign.oc1..<unique_ID>
To retrieve the backup policy assignment ID for a boot or block volume

Open a command prompt and run:

oci bv volume-backup-policy-assignment get-volume-backup-policy-asset-assignment --asset-id <volume_OCID>

For example:

oci bv volume-backup-policy-assignment get-volume-backup-policy-asset-assignment --asset-id ocid1.volume.oc1..<unique_ID>

Using the API

For information about using the API and signing requests, see REST API documentation and Security Credentials. For information about SDKs, see SDKs and the CLI.

Use the following operations for working with block volume backups, boot volume backups, and backup policies.

Block Volume Backups

Boot Volume Backups

Volume Backup Policies and Policy Assignments