Oracle Block Volumes provide persistent, durable, and high-performance storage for your data. Oracle Block Volumes let you store your data on block volumes independently and beyond the lifespan of your compute instance. Oracle Block Volumes can help you manage your block volumes, control data, and achieve the storage configuration your application requires.
Oracle Block Volumes let you dynamically provision and manage block storage volumes. You can create, attach, connect, and move volumes as needed to meet your storage and application requirements. Once attached and connected to an instance, you can use a volume like a regular hard drive. Volumes can also be disconnected and attached to another instance without the loss of data.
A block volume is a type of data storage that is more expansive than file storage. Block volumes use iSCSI Ethernet protocol to deliver the features and performance similar to on-premise storage area networks (SANs), and are designed for the security and durability of the data life cycle. Using Oracle Block Volumes, you can create block volumes and attach them to your compute instance.
We recommend using block volumes when your workload application requires highly available storage and the performance of a SAN, or your data governance needs to include integrated backups. Your application benefits from service elasticity, data persistence, and performance. Block volumes provide you with simple management options, operational flexibility, and pay-as-you-go pricing with isolation and maximum control.
Data stored on local compute drives persists only as long as that compute instance, and should only be used for temporary files. When you store data on higher durability block volumes, your data persists for the lifetime of the block volume. If the compute instance terminates, you can attach the volume to another compute instance and regain access to the persistent data in that volume. By using block volumes, you can extend your data protection plan to include integrated block volume backups, providing a copy of your data at the date the backup is created.
Yes. Industry-leading, highest performance NVMe solid-state drives are used. They deliver high performance, are backed by a performance SLA, and enabled without using storage caching.
You can provision block volumes from 50 GB to 32 TB, in 1 GB increments.
Your operating system accesses block volumes using iSCSI protocol, a storage networking standard for linking data storage facilities.
Block volumes attached to Oracle Cloud Infrastructure Compute virtual machine instances are limited by the network bandwidth available. Refer to the Compute Service FAQ for instance limits.
You can observe up to 700,000 or more IOPS and near-line-rate throughput for your bare metal compute instance.
Refer to Oracle Cloud Infrastructure Block Volume Performance for more details.
You can attach up to 32 volumes per compute instance, resulting in up to 32 TB*32=1 PB attached capacity per compute instance. We recommend you measure and adjust the number of attached volumes according to your high-performance application needs.
Yes. To provide the highest performance, block volumes are optimized to attach to any compute instance within the same Availability Domain. You can detach a volume from one compute instance, and then attach the block volume to another compute instance without rebooting your compute servers. More details can be found in the Oracle Cloud Infrastructure documentation.
All block volumes and their backups are always encrypted at rest by using the Advanced Encryption Standard (AES) algorithm with 256-bit key for encryption. All data moving between the instance and the block volume is transferred over our internal and highly secure network. If you have specific compliance requirements related to the encryption of the data while it is moving between the instance and the block volume, you can enable in-transit encryption if you use paravirtualized volume attachments.
Block volumes and their backups are accessible only within your tenant/compartment boundary, and only authenticated users who have been granted permission by you to the tenant/compartment can access them.
Boot volumes are also provided and managed by the Block Volumes service, so they are secured the same way as block volumes.
No. You can change the performance of any volume without any downtime for your applications, regardless if it is attached to an instance or not.
Multiple copies of data are stored redundantly across multiple storage servers with built-in repair mechanisms. The Block Volumes service is designed to provide 99.99 percent (Four 9's) annual durability for block and boot volumes. However, we recommend that you make regular backups to protect against the failure of an availability domain.
You can increase the size of a volume while it is online without any downtime. For details, check technical documentation page.
Read-only attachment is used to mark a volume for read-only purpose, so the data in the volume is not mutable. This allows safeguarding data against accidental or malicious modifications by an untested or untrusted application.
You can also use read-only attachments where you have multiple compute instances (each running a client app, such as web front end) accessing the same volume for read-only purpose. For example, a web front end that serve static product catalog information to clients.
Boot volumes are by definition mutable, and therefore by default are not "read-only". After you detach a boot volume you may choose to attach it read-only for debug purposes.
No. In order to do that, you first need to detach the volume and reattach it by specifying the "read-only" attribute.
No. In order to do that, you first need to detach the volume and reattach it by specifying the default attachment mode ("read/write").
You have two options: iSCSI or Paravirtualized. Paravirtualized volume attachment is supported for VM instances only.
Block volumes that have native operating system support without a need for iSCSI initiator and attachment. All Oracle operating systems, Linux, and Windows support paravirtualized attachment as an option for VM deployments.
Using paravirtualized attachments simplifies volume attachment configuration. If you do not want to run iSCSI configuration commands during the volume attachments, you may consider using paravirtualized attachments instead. Note that iSCSI provides better performance at the expense of initial configuration steps. The convenience of paravirtualized attachments comes with a performance trade-off over the published performance characteristics for iSCSI attachments.
Yes. You can select the attachment type on the CLI/SDK and from the console when you attach a volume. To change the attachment type, you must detach the volume and then reattach, specifying the new attachment type.
Paravirtualized attachments provide less performance than ISCSI attachments. For more detail, refer to Oracle Cloud Infrastructure Block Volumes performance.
Yes. Oracle Block Volumes provide an integrated backup capability to protect your data by storing a copy of the block volume in Oracle Cloud Infrastructure Object Storage.
Yes. Boot volume backups have all the capabilities of block volume backups. Oracle Cloud Infrastructure Block Volumes manage the operating system disks as boot volumes. To backup the contents of a boot volume, create a backup just like any other block volume. Oracle boot volumes provide an integrated backup capability to protect your data by storing a copy of the boot volume in Oracle Object Storage. Making a boot volume backup while an instance is running creates a crash-consistent backup. In most cases, you can create an instance directly from the boot volume backup, or you can attach it to an instance to recover data. To ensure a bootable image, create a custom image from your instance.
A backup is a complete point-in-time snapshot copy of all data on your block volume when that backup was initiated. Immediately after a backup is completed, your backup is available to restore to a block volume. Backups are encrypted and copied to your account in Oracle Cloud Infrastructure Object Storage.
The primary use of backups is to support business continuity, disaster recovery, and long-term archiving. When determining a backup schedule, your backup plan and goals should consider the following:
Backups are done using point-in-time snapshot; therefore, while the backup is being performed in the background asynchronously, your applications can continue to access your data without any interruption or performance impact. For a 2 TB volume being backed up for the first time, expect about 30 minutes for the backup to complete. For a 50 GB boot volume being backed up for the first time, expect a few minutes for the backup to complete. Subsequent backups of the same volume depend on the amount of data that has changed since your last backup.
You have two options:
1. Automated policy-based scheduled backups. You have an option to use Oracle-provided predefined backup policies, or you can create and use your own custom backup policy. Backup policies, both predefined and custom, set the frequency and retention period for your backups, which allows you to adhere to your data compliance and regulatory requirements. You can rest assured knowing that your data will be backed up automatically on schedule and retained, based on the backup policy you selected. Later, as your needs change, you can easily adjust by selecting a different backup policy or modifying your custom policy, or remove it all together.
2. On-demand one-off backups. You can select whether to backup only the data that has changed since the last backup (incremental) or the entire data that has changed since the time you created the volume (full).
For more details, refer to technical documentation.
Yes. You can select whether to backup only the data that has changed since the last backup (incremental) or the entire data that has changed since the time you created the volume (full).
Backup is done by a point-in-time snapshot. It continues asynchronously without impacting access to data. Access to the block volume that is being backed up continues without any interruption or additional latency or performance impact.
Yes. You can create your own backup policies, with daily, weekly, monthly, and yearly schedules, and assign your policies to your volume for its automatic backup. You can also duplicate an existing policy and customize the duplicate policy as you need, by modifying the parameters of the schedules, adding or removing schedules in the policy.
For more details, refer to technical documentation.
They will stay. However when they expire, they will be deleted automatically. All automatically created backups based on a policy have an expiration time, and they are deleted automatically when they expire.
Manually created backups do not have expiration and will stay until you delete them.
They will stay, however when they expire, they will be deleted automatically based on the settings that were effective when they were created. All automatically created backups based on a policy have an expiration time, and they are deleted automatically when they expire.
After you change the backup policy for a volume to another policy, the new policy takes affect and new backups will be automatically created according to the new policy.
Policy based backups have an expiration time. They will expire on their expiration time, and will be automatically deleted. If you want to preserve a backup, manually create a backup. The manually created backups do not expire.
Yes. You can do this on the Console, CLI/SDK, and Terraform by following the online technical documentation.
Backups that are created using the Oracle-provided predefined backup policies are based on the time zone of the Oracle Cloud Infrastructure Availability Domain where the volume resides. All Availability Domains of an Oracle Cloud Infrastructure region are on the same time zone, so in effect the scheduled backups are based on Oracle Cloud Infrastructure region time zone.
For your custom backup policies, for each schedule item in a policy, you can specify whether to use UTC or the data center time zone where your volume resides.
Yes, you can define one daily, up to 7 weekly (one for each day of the week), up to 31 monthly (one for each day of the month), and up to 365 yearly (one for each day of the year) schedule entries in each custom backup policy.
For more details, refer to technical documentation.
They will be performed using the best effort to fit them to the scheduled times. However, based on system load, they might be queued and processed together with all other scheduled backup requests in the system. Check the backup status to ensure your backup is completed, or trigger a manual backup as needed.
You can restore a volume in less than a minute regardless of the volume size. Although the restore of a volume is fast and the volume is immediately accessible for your workloads, you may see latency spikes when you first begin to use a restored volume.
Requests to the newly restored block volume may have higher latency for a short period of time right after it got restored.
Yes. A backup can be restored to any Availability Domain within the same region it is stored, and is the recommended method for efficiently moving data.
Yes, you can create a backup of a boot volume either manually, or using the policy-based automated and scheduled backups. Also check for an option to create an image from the running instance by following the Compute Service FAQ.
Yes, you can use the cross-region backup copy feature to copy your existing block volume backups to another region that you have access.
Yes. You can restore from your backup to a larger volume up to the currently supported maximum 32 TB volume size.
Clone is a feature of Oracle Cloud Infrastructure Block Volume service that allows copying an entire existing block volume to a new volume without needing to go through a backup and restore process. It creates a point-in-time deep copy of a source volume (also known as thick clone) directly without a backup.
Yes, you can clone a boot volume just like you clone a block volume. Making a boot volume clone while an instance is running creates a crash-consistent clone. In most cases, you can create an instance directly from the boot volume clone or you can attach it to an instance to recover data. To ensure a bootable image, create a custom image from your instance.
The clone operation is immediate, and the cloned volume becomes available to use right after initiating the clone operation. The actual copying of data happens in the background. Timing is proportional to the data in the source volume and can take up to 15 minutes for 1 TB volume.
A clone can be attached and used as regular volume when its lifecycle state becomes "available," usually within seconds. Hydration will continue happening in the background. There may be latency spikes for blocks of data which are not yet copied over.
Oracle Block Volume clone is a point-in-time direct disk-to-disk deep copy an entire volume. It is different than snapshot as there is no copy-on-write or dependency to the source volume. There is no backup involved. A block volume clone is created without creating a snapshot, without a backup to Object Storage, and without restoring from backup.
No. The clone happens via a point-in-time direct disk-to-disk deep copy of the source volume, and there is no need to detach a volume before cloning it.
The clone happens via a point-in-time direct disk-to-disk deep copy of the source volume. All the data in the source volume at the time the clone becomes "available" is copied to the clone volume. Subsequent changes that happen on the source volume are not copied to the clone.
No. Block volumes are AD-local. You can clone volumes only within the same AD.
Yes. You need to have the necessary access permissions on the source and destination compartments.
No. Volumes are accessible only within a tenant boundary.
No. Block volumes are AD-local and reside in the region they are created in. You can clone volumes only within the same AD of the region that they exist.
Yes. You can specify a clone size up to 32 TB.
It depends on the attachment state of the source volume.
It depends on the lifecycle state of the cloned volume that is being created.
Clone and backup operations are mutually exclusive. When a backup is in progress for a volume, it can't be cloned or backed up again irrespective of whether volume is attached or not. When a clone is in progress for a volume, it can't be backed up irrespective of whether volume is attached or not.
No. A source volume can't be deleted while any of its clones are still hydrating from it.
A clone can be deleted once its lifecycle state is "available". Also note that a clone that is still hydrating can be deleted once its lifecycle state is "available".
This might happen for this case: You started a clone from a source volume, and while the clone is in progress hydrating from the source volume, you attached the source volume to a compute instance, and then detached it. In this case, if you initiate another clone request for the same source volume, the new clone results in a terminated state. This does not affect the first clone that is being hydrated. When that first clone becomes fully hydrated, then subsequent clone operation on the source volume will proceed as expected.
Boot volumes provide remote boot disks that are encrypted by default, have faster performance and lower launch times, and higher durability for your bare metal and virtual machine (VM) instances. Additionally, boot volumes allow you to create significantly faster custom images of running VMs without having to reboot. All bare metal and VM compute instances launch using the boot volumes and offer:
Any newly launched bare metal or VM compute instance will automatically create a new boot volume within your compartment. You can use the Oracle Cloud Infrastructure console to see the boot volumes attached to your instance under the instance details page. All boot volumes within your compartment will be listed under Boot Volumes within the Storage console page. Boot volume details include the instance the boot volume is attached to as well as size of the volume and other volume metadata.
You will be charged for your boot volumes at standard Oracle Block Volumes pricing. Note, this is in addition to the price of the compute instance.
Yes, boot volumes are metered and included in the tenancy block storage limit just like block volumes. They should also be included in your tenancy block storage limit calculation and planning, in addition to your block volumes consumption.
Yes, you can launch another instance with your boot volume by first creating a custom image of your boot volume and then using the custom image to launch the instance.
Alternately, you can launch a new instance directly from an unattached boot volume if you don't wish to create a custom image.
All boot volumes are created on highly durable Oracle Cloud Infrastructure Block Volumes. Your boot volumes persist independent of the lifecycle of your compute instance.
Boot volumes are only terminated when you manually delete them.
All new instances use the boot volumes by default. You can reprovision your existing instances by creating a custom image and launching a new instance.
Yes, you can create a backup of your boot volumes by going to the Compute page in your Oracle Cloud Infrastructure console or through the API/CLI. The backup will be associated with the boot volume it was created from.
Yes, you can delete an unattached boot volume by using the console or API/CLI. Additionally, you can optionally chose to automatically delete the boot volume when terminating an instance by selecting the checkbox in the delete confirmation dialog.
Oracle Cloud Infrastructure does not allow you to delete the boot volume currently attached to an instance.
You can stop an instance, detach its boot volume, and delete the detached boot volume. The stopped instance cannot be started after its boot volume is deleted. You can only terminate that instance.
No, you can only detach a boot volume from a stopped instance. Terminating your instance will automatically detach and persist your boot volume unless you opt into permanently deleting your boot volume.
Yes, you can attach any boot volume to an instance as block storage in order to debug issues. You will first need to detach a boot volume from its associated compute instance in order to attach it to a different instance.
You can follow the steps below to debug your boot volume:
1. Terminate the old instance, and keep the original boot volume when you terminate the instance (select “yes” on the confirmation dialog asking if you want to keep the boot volume).
2. Launch a new instance of different shape, by selecting the boot volume you kept from the old instance.
This applies to both bare metal and VM instances.
Note: A new instance will have different IP address and network configuration than your original instance. You need to adjust for these differences for a seamless experience for your workloads that use these instances.
Boot volumes offer faster compute instance launch times compared to local boot disks: Linux instances launch within a minute, and Windows instances launch within five minutes.
Boot volumes are standard Oracle OS image size by default, and offer 3,000 IOPS and 24 MB/s throughput with submillisecond latency for 50 GB boot volumes. Larger boot volumes have predictable performance that scales linearly with size, just like block volumes. This performance is independent of workload type (for all read/write distributions). For details, refer to Oracle Cloud Infrastructure Block Volumes performance documentation.
If you have an existing custom image already in use on the Oracle Cloud Infrastructure platform, you can select to use it to launch your instances. The boot volumes created during instance launch using a custom image will have the same size as your custom image.
Yes. You can specify any size starting from the default size of the selected OS image up to 32 TB, in 1 GB increments when launching a compute instance. The minimum boot volume size is constrained by the size of the OS image you select. You cannot specify less than 50GB, or less than the size of your selected OS image. For example, if you select an OS image that is 256 GB in size, the minimum boot volume you can specify to use is 256 GB.
Yes, you can increase the size of a boot volume while it is online without any downtime. For details, check technical documentation page.
Use the Launch instance API and specify a larger boot volume size by using bootVolumeSizeInGBs parameter. Note: If the size specified is smaller than the image size, the API call will fail.
The instance will be launched with a default boot volume size that is equal to the size of the selected OS image.
A volume group represents a set of block storage volumes that can be treated as a single entity for backup and clone purposes. A volume group is associated with a single Availability Domain (AD), and volumes within the group are also within the same AD.
The volume group exposes the same backup/restore and clone capabilities as individual volumes. This means you can perform a point-in-time crash consistent coordinated backup of a volume group—either incremental or full—and create a point-in-time crash consistent clone of a volume group.
Up to 32 volumes can be placed in a volume group, for a total volume group size of 128 TB. This is a soft limit, and can be increased per tenancy as requested via the limit increase. Each volume may only be in one volume group.
You can use the Console, CLI/SDK, APIs, and Terraform to manage group volumes. This includes creating and deleting volume groups, adding and removing volumes from a group, and renaming volume groups.
Yes. Volumes in a volume group can be accessed and operated on individually, in addition to being managed as a group.
A coordinated point-in-time crash consistent backup of the entire set of volumes that are in a volume group. This operation creates a volume group backup. There is no impact to the source volume group and volumes during the backup process.
Volume group backups are replicated across all Availability Domains within the region where the source volume group resides. A volume group backup can then be used to create a new volume group to any Availability Domain within the region the backup resides, by restoring all the volumes data that are in the volume group.
Yes. Check the documentation page for details
A coordinated point-in-time crash consistent deep disk-to-disk copy of the entire set of volumes that are in a volume group. This operation creates a new volume group and new volumes that are in it, which are exact copy from the source volume group and volumes in it.
The clone operation is immediate, and the cloned volume group and cloned volumes in it become available to use right after initiating the clone operation. The actual copying of data happens in the background. Timing is proportional to the data in the source volumes and can take up to 15 minutes for 1 TB volume.
The source volume group and volumes in it are not impacted by the clone process. The source and destination volume groups, and the set of volumes in them, are completely isolated from each other with nothing shared. This ensures no impact to the source while the clone is in progress, and when the clone is completed.
It depends on the attachment state of the source volumes in the volume group.
These features come at no additional charge. You are only charged for the block and boot volumes storage at Block Volume pricing, and for volume group backups at Object Storage pricing, based on actual usage.
Refer to Oracle Cloud Infrastructure product documentation for more information on how to get started with and manage volume groups.
Block volumes are metered based on provisioned GB volume size and performance option selected for each volume. Block volume usage is billed according to Oracle Cloud Infrastructure Block Volumes pricing.
Block Volume backups are kept in Oracle Cloud Infrastructure Object Storage, metered and billed based on the Object Storage that they consume. For details, refer to Object Storage pricing.
Refer to Oracle Cloud Infrastructure Storage pricing. Cross-region backups are metered and billed based on the Object Storage and outbound data transfer network usage.