Block Volume Backups

• Listing Volume Backups
• Restoring a Backup to a New Volume
• Copying a Volume Backup Between Regions
• Moving a Block Volume Backup to Another Compartment
• Deleting a Volume Backup

See also Manually Backing Up a Volume and Policy-Based Backups (Backup Policies).

To get started with the volume backups, an administrator needs to grant user access through an IAM policy. Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).

Example policy to allow block volume administrators to manage block volumes, backups, and volume groups across regions:

Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to inspect volume-attachments in tenancy
Allow group VolumeBackupAdmins to inspect instances in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancy
Allow group VolumeBackupAdmins to use volume-backups in tenancy where request.permission='VOLUME_BACKUP_COPY'

Allow group BootVolumeBackupAdmins to use volumes in tenancy
Allow group BootVolumeBackupAdmins to manage boot-volume-backups in tenancy
Allow group BootVolumeBackupAdmins to inspect instances in tenancy
Allow group BootVolumeBackupAdmins to manage backup-policies in tenancy
Allow group BootVolumeBackupAdmins to manage backup-policy-assignments in tenancy
Allow group BootVolumeBackupAdmins to use boot-volume-backups in tenancy where request.permission='BOOT_VOLUME_BACKUP_COPY'

Following are the backup types available in Block Volume:

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

Example

You create a 50 GB block volume, write 25 GB to the volume, and then launch a full backup of the volume on Day 1 with a two-day retention period. Upon completion, the backup size is 25 GB.

On Day 2, you then modify 2 GB of existing data, write 3 GB of new data and create an incremental backup. The unique size of the incremental backup totals 5 GB.

On Day 3, another incremental backup is made with modified 3 G of existing data and added 2 GB of new data, totaling 5 GB.

On Day 4, the full backup is be deleted as the retention expires. The incremental backup size is now totals 28 GB, the contents of which are required to restore the volume contents to the time the incremental backup was taken.

On Day 5, the first incremental backup retention expires. The backup size for this second incremental backup totals 30 GB, the actual size of the volume contents at the time the second incremental backup was made. Because the blocks are retained even after the full backup was deleted, the volume can still be restored from an incremental backup.

Volume backup size might be larger than the current volume usage. Possible reasons for a larger backup size could include:

• Any part of a volume that has been written to is considered initialized, and is always be included in a volume backup.
• Many operating systems write or zero out the content, which marks these blocks as used. 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 other data. For example, in a full backup of a 256 GB Windows boot disk, you might see a backup size of 257 GB, which includes an extra 1 GB of metadata.

Copying block volume backups between regions enhances the following scenarios:

• Disaster recovery and business continuity: By copying block volume backups to another region at regular intervals, you can easily 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 Copying a Volume Backup Between Regions.

After you copy the volume backup to the new region, you can restore from that backup by creating a new volume from the backup using the steps described in Restoring a Backup to a New Volume.

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 encryption key for the volume backup to another Vault encryption key, or to an Oracle-managed key. See Changing the Assigned Master Encryption Key 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.

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.

Apply tags to resources to help organize them according to your business needs. You can apply tags when you create a resource, and you can update a resource later to add, revise, or remove tags. For general information about applying tags, see Resource Tags.

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

• Backup your critical application volumes multiple times daily. For mission-critical applications, we recommend that you take multiple backups per day for to minimize the possible recovery point objective (RPO).

  Note
  
  With policy-based backups you can only schedule one backup and copy per day. Users can use manual backups to initiate multiple backups in a day. For cross region copy, we recommend copying only one backup per day to the remote region. For even smaller RPO, review our replication support.
• Configure retention and expiry times for your backups. Backups are automatically purged after the set expiry time to free storage space and costs. Manual backups don't expire.

• Schedule or create your backups during off-peak hours. if you notice your backups aren't completing at the expected time, consider changing your scheduled or manual backup times to a different time of day. A daily backup still completes in less than 24 hours.

• Organize critical and non-critical data. To reduce the amount of backups needing to be managed, we recommend using separate creation, backup and recovery operations for critical and non-critical data. Critical data typically includes all the data that's required for application recovery and use. Best practice is to keep critical data in a secondary block volume instead of your boot volume. Non-critical data includes swap, temporary, cache or page files and non-critical logs, and tends to be larger in size.

• Use volume groups to create cross-volume, crash-consistent backups. When your data is spread across multiple volumes, you can create and back them up as a volume group. Because the volume group backups consistently capture all of the data synced to each volume, you no longer need to shut down your instances to take individual snapshots. This method is ideal for filesystems and applications that support journaling.
• Maximize data recoverability and recover time with app-consistent backups. You can achieve app-consistent backups by pausing or quiescing your service before initiating a backup. This can include stopping all I/O operations, syncing all memory buffers, and flushing in-flight transactions. You can then send an API call to back up a volume or volume group.
• Before creating a backup, 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 is 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's being backed up can't be deleted.
• To attach a restored volume that has the original volume attached, you might need to change the partition IDs first, This requirement comes from operating systems that don't allow you to restore identical volumes. For instructions on changing partition IDs, see your operating system's documentation.

See Manually Backing Up a Volume andRestoring a Backup to a New Volume for more information.

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

• 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. While the time for a backup to complete varies on several factors, the time is typically 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, that backup needs 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.

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.

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