Overview of Block Volume Backups

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).

The following is an 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'

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.

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

• Any part of a volume that has been written to is considered initialized, and will 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 additional 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 additional 1 GB of metadata.

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, 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 Required IAM Policy.

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 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.

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.

When a volume backup is created, the source volume's tags are automatically included. This also includes volumes with custom backup policies applied to create scheduled backups. 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.

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, it is recommended to only copy one backup per day to the remote region. For even smaller RPO, please take a look into our replication support.
  • Configure retention and expiry times for your backups. Backups will be automatically purged after the set expiry time to free storage space and costs. Manual backups do not expire.

  • Schedule or create your backups during off-peak hours. if you notice your backups are not completing at the expected time, consider changing your scheduled or manual backup times to a different time of day. A daily backup will still complete 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 is required for application recovery and use, and should be kept 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 have 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 take a backup of a volume or volume group.
• 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.

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.

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.

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