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. 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.
These are on-demand one-off backups that you can launch immediately by following the steps described in Backing Up a 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.
These are automated scheduled backups as defined by the backup policy assigned to the volume.
There are two kinds of backup policies:
Oracle defined: Predefined backup policies that have a set backup frequency and retention period. You cannot modify these policies. For more information, see Oracle Defined Backup Policies.
User defined: Custom backup policies that you create and configure schedules and retention periods for. For more information, see User Defined Backup Policies.
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.
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.
Backups are not an identical copy of the volume being backed up. For incremental backups, they are a record of all the changes since the last 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, upon completion the volume backup size is 40 GB.
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.
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. 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 Overview of Vault.
If you do not 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.
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.
You should not delete the original volume until you have verified that the backup you created of it completed successfully.
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.
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.
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.
Slower (minutes or hours)
Policy-based backups expire, manual backups do not expire
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 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.
Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud InfrastructureConsole, API, or CLI.
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).