OCI Block Volumes provide persistent, durable, high-performance data storage. OCI lets you store your data on block volumes independently and beyond the lifespan of your compute instance. OCI Block Volumes can help you dynamically provision and manage your block storage volumes, control data, and achieve the storage configuration your application requires. 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 features and performance like on-premises storage area networks (SANs) and are designed for the security and durability of the data lifecycle. You can create and attach OCI Block Volumes 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. OCI 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 only survives as long as the compute instance does, so this storage option 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 was created.
You can access Block Volumes using the console, a REST API, or SDKs. See the Oracle Cloud Infrastructure Getting Started Guide and Overview of Block Volumes for details.
Yes. Industry-leading, highest-performance NVMe solid-state drives are used. They deliver high performance, are backed by a performance SLA, and are 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.
Refer to the Block Volume Performance documentation.
The performance of Block Volumes attached to Oracle Cloud Infrastructure Compute virtual machine instances is 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 the Block Volume Performance documentation 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 that 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 volume to another compute instance without rebooting your compute servers. You can find more details in the documentation.
All Block Volumes and their backups are always encrypted at rest by using the Advanced Encryption Standard (AES) algorithm with a 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’s moving between the instance and the Block Volume, you can enable encryption in transit 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 access the tenant/compartment can access them.
Boot volumes are also provided and managed by the Block Volume service, so they are secured the same way as Block Volumes.
Yes. For information, refer to Block Volume Elastic Performance Options and Block Volume Pricing.
Yes. For information, refer to Block Volume Elastic Performance Options and Block Volume Pricing.
Yes. With Block Volume auto-tuning, you can set your performance to the lowest performance, at least 10 VPUs per GB, and highest performance, at most 120 VPUs per GB. By using the auto-tuning feature, your block volume will only use what it needs when it needs it.
*Note: Boot volumes and single path attachments don’t currently offer this new capability, but support for this feature is coming in a future update. To learn more about Block Volume auto-tuning, visit the Performance-Based Dynamic Scaling documentation.
With auto-tuning, increases in performance take effect quickly; actions are repeated within 15 seconds for each level adjustment to provide a steady performance increase as needed. Decreases in performance happen slowly, with the initial decrease taking effect in an hour and subsequent decreases in minutes to avoid reducing volume performance abruptly while the performance is still needed. For more information, read the Performance-Based Dynamic Scaling documentation.
Yes, it can, but it’s not always guaranteed. Whether you can save with this auto-tuning feature will depend on your workload usage and the height of the performance you set. You will need to understand your applications’ demand, usage patterns, and budget before enabling and configuring this capability for your volumes. Review the OCI Block Volume pricing page to help determine your volume’s performance auto-tuning range based on your budget.
Yes, you can monitor the performance characteristics and settings for a volume by using the volume metrics and audit logs. Read the documentation to learn more about block volume metrics and audit logs.
Multiple copies of data are stored redundantly across multiple storage servers with built-in repair mechanisms. The Block Volume service is designed to provide 99.99% (four 9s) 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’s online without any downtime. For details, check out the technical documentation page.
When you attach a block volume, you have the option to specify the access type as read-only. This means an instance can only read the data on the volume, so the data in the volume is not mutable. This option allows you to safeguard data against accidental or malicious modifications by an untested or untrusted application.
You can also use read-only attachments in situations where you have multiple compute instances, each running a client app (such as a web front end), accessing the same volume for read-only purposes—for example, a web front end that serves 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 as read-only for debug purposes.
No. In order to do that, you first need to detach the volume and then reattach it, specifying the "read-only" attribute.
No. In order to do that, you first need to detach the volume and then reattach it, specifying the default attachment mode ("read/write").
You have two options: iSCSI or paravirtualized. Paravirtualized volume attachments are supported for virtual machine instances only.
Paravirtualized volume attachments are block volumes that have native operating system support and don’t need an iSCSI initiator and attachment. All Oracle operating systems, Linux, and Windows support paravirtualized attachments as an option for virtual machine deployments.
Using paravirtualized attachments simplifies the process of configuring your block volume attachments. If you do not want to run iSCSI configuration commands when attaching volumes, you may consider using paravirtualized attachments instead. Note that iSCSI provides better performance at the expense of additional initial configuration steps.
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 it, specifying the new attachment type.
Paravirtualized attachments provide lower performance than iSCSI attachments. For more details, refer to the Block Volume Performance documentation.
Yes. OCI Block Volumes provide an integrated backup capability to protect your data by storing a copy of the block volume in OCI Object Storage.
Yes. Boot volume backups have all the capabilities of block volume backups. The Block Volume service manages operating system disks as boot volumes. To back up the contents of a boot volume, create a backup just like you would for any other block volume. OCI boot volumes provide an integrated backup capability to protect your data by storing a copy of the boot volume in OCI 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 the data. To ensure you have a bootable image, create a custom image from your instance.
A backup is a complete point-in-time snapshot copy of all the 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 OCI Object Storage.
The primary purpose of a backup 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 snapshots; 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 it to take about 30 minutes for the backup to complete. For a 50 GB boot volume being backed up for the first time, expect the backup to complete in a few minutes. 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 removing it all together.
2. On-demand, one-off backups. You can select whether to back up only the data that has changed since the last backup (incremental) or all the data that has changed since the time you created the volume (full).
For more details, refer to the technical documentation.
Yes. You can select whether to back up only the data that has changed since the last backup (incremental) or all the data that has changed since the time you created the volume (full).
A backup is done by a point-in-time snapshot, so it continues asynchronously without impacting access to data. Access to the block volume that is being backed up continues without any interruption or additional impact to latency or performance.
You can create and apply your own custom backup policies. In addition, the OCI Block Volume service provides three different predefined backup policies, which are outlined in the documentation.
Yes. You can create your own backup policies, with daily, weekly, monthly, and yearly schedules, and assign your policies to your volume to back it up automatically. You can also duplicate an existing policy and customize the duplicate policy as needed by modifying the parameters of the schedules and adding or removing schedules in the policy. For more details, refer to the technical documentation.
They will stay. However, 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 expire 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 effect and new backups will be automatically created according to the new policy.
Backups and volumes have different lifecycles. If a volume is deleted, the backup can last beyond the volume’s lifespan, depending on the kind of backup you created. Policy-based backups have an expiration time. They will expire at their expiration time and will be automatically deleted once they expire. If you want to preserve a backup for longer, you must manually create a backup. Manually created backups do not expire.
Yes. You can do this on the console, the CLI/SDK, or through 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 OCI availability domain where the volume resides. All OCI availability domains in a region are in the same time zone, so in effect, the scheduled backups are based on the region’s time zone.
With a custom backup policy, you can specify whether to use UTC or the time zone of the data center where your volume resides for each schedule item in the policy.
Yes, you can create multiple different schedules, but you can only back up each volume once per day. You can set up to one daily schedule entry, up to 7 different weekly schedule entries (one for each day of the week, at a specific time on that day), up to 31 different monthly schedule entries (one for each day of the month, at a specific time on that day), and up to 365 yearly schedule entries (you specify the month, day, and time) in each custom backup policy. If more than one backup is scheduled for a volume on a particular day, the service runs only one of them in the following order of priority: yearly, monthly, weekly, and daily. For more details, refer to the technical documentation.
For example, if you set up a daily backup for every day at midnight and a weekly backup for every Monday at midnight, you will have two scheduled backups every Monday. Since you have two backups scheduled for the same day, the weekly backup would take precedence as the retention time is longer. The next day, if the only backup scheduled is the daily backup, then the Tuesday backup would be a daily scheduled backup, which is set to be retained until the next scheduled backup on the next day.
Every effort will be made to perform scheduled backups at 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 restoring 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 volume may have higher latency for a short period of time right after it is restored.
Yes. A backup can be restored to any availability domain within the same region it is stored in, and this is the recommended method for moving data efficiently.
Yes, you can create a backup of a boot volume either manually or using the policy-based, automated scheduled backups. Also check out an option to create an image from the running instance in 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 to.
Yes. You can restore from your backup to a larger volume up to the currently supported maximum 32 TB volume size.
Cloning is a feature of Block Volumes that allows you to copy 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 a thick clone) directly without a backup.
Yes, you can clone a boot volume just like you would 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 the data. To ensure you have 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 the data happens in the background. Timing is proportional to the data in the source volume and can take up to 15 minutes for a 1 TB volume.
A clone can be attached and used as a regular volume when its lifecycle state becomes "available," which is usually within seconds. Hydration will continue to happen in the background. There may be latency spikes for blocks of data that are not yet copied over.
A Block Volume clone is a point-in-time, direct disk-to-disk deep copy of an entire volume. It is different than a 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 in the source volume are not copied to the clone.
No. Block volumes are local to their availability domain. You can clone volumes only within the same availability domain.
Yes. You need to have the necessary access permissions for the source and destination compartments.
No. Volumes are accessible only within a tenant boundary.
No. Block volumes are local to availability domains and reside in the region they are created in. You can clone volumes only within the same availability domain of the region in which 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 regardless of whether the volume is attached or not. When a clone is in progress for a volume, it can't be backed up regardless of whether the 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 if you started a clone from a source volume, and while the clone was in the process of 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 operations on the source volume will proceed as expected.
Boot volumes provide remote boot disks that are encrypted by default and have faster performance, lower launch times, and higher durability for your bare metal and virtual machine instances. Additionally, boot volumes allow you to create significantly faster custom images of running virtual machines without having to reboot. All bare metal and virtual machine compute instances launch using boot volumes and offer the following benefits:
Any newly launched bare metal or virtual machine compute instance will automatically create a new boot volume within your compartment. You can use the OCI 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 Block Storage console page. Boot volume details include the instance the boot volume is attached to as well as the size of the volume and other volume metadata.
You will be charged for your boot volumes using standard Block Volume pricing. Note that this is in addition to the price of the compute instance.
Yes, boot volumes are metered and included in your 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 volume 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 Block Volumes. Your boot volumes persist independently of the lifecycle of your compute instance. Boot volumes are only terminated when you manually delete them.
All new instances use 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 volume by going to the Compute page in your OCI 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 choose to automatically delete the boot volume when terminating an instance by selecting the checkbox in the delete confirmation dialog.
OCI does not allow you to delete a 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 has been 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 to permanently delete your boot volume.
Yes. You will first need to detach the boot volume from its associated compute instance to attach it to a different instance.
Follow these steps to debug your boot volume.
1. Terminate the old instance and keep the original boot volume when you terminate the instance (select “yes” in the confirmation dialog when asked if you want to keep the boot volume).
2. Launch a new instance of a different shape by selecting the boot volume you kept from the old instance.
This applies to both bare metal and virtual machine instances.
*Note: A new instance will have a different IP address and network configuration than your original instance. You will need to adjust for these differences to ensure a seamless experience for the 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 the standard Oracle OS image size by default and offer 3,000 IOPS and 24 MB/sec 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 the Block Volume Performance documentation.
If you have an existing custom image already in use on the OCI platform, you can choose 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 50 GB 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 size 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 out the technical documentation.
Use the Launch instance API and specify a larger boot volume size by using the bootVolumeSizeInGBs parameter. Note that 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 volumes that can be treated as a single entity for backup and cloning purposes. A volume group is associated with a single availability domain, and volumes within the group are also within the same availability domain.
The volume group has the same backup/restore and cloning capabilities as individual volumes. This means you can perform a coordinated point-in-time, crash-consistent 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, the CLI/SDK, APIs, and Terraform to manage volume groups. 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 volume group backup is a coordinated point-in-time, crash-consistent backup of the entire set of volumes that are in a volume group. 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 in any availability domain within the region where the backup resides by restoring all the volumes that are in the volume group.
Yes. Check out the documentation for more details.
A volume group clone is 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 with new volumes in it, which is an exact copy of the source volume group and the 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. The time it takes is proportional to the data in the source volumes, and cloning can take up to 15 minutes for a 1 TB volume.
The source volume group and the volumes in it are not impacted by the cloning 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 there is 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 volume storage at Block Volume pricing and for volume group backups at Object Storage pricing, based on actual usage.
Refer to the volume groups documentation for more information on how to get started with and manage volume groups.
Block Volumes are metered based on the provisioned GB volume size and the performance option selected for each volume. Block Volume usage is billed according to Block Volume pricing.
Block Volume backups are kept in Object Storage and metered and billed based on the Object Storage they consume. For details, refer to the Object Storage pricing page.
Refer to the OCI Storage pricing page. Cross-region backups are metered and billed based on the Object Storage and outbound data transfer network usage.