General questions
What are Oracle Cloud Infrastructure (OCI) Block Volumes?
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.
What is a block volume?
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.
When do I use block volumes?
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.
What happens to data when an instance terminates?
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.
How do I start using Block Volumes?
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.
Do Block Volumes use NVMe SSDs in the storage infrastructure?
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.
Capacity, performance, and security
What size block volumes can I provision with OCI Block Volumes?
You can provision block volumes from 50 GB to 32 TB in 1 GB increments.
How does my operating system access a block volume?
Your operating system accesses block volumes using iSCSI protocol, a storage networking standard for linking data storage facilities.
What are the performance limits of a single Block Volume?
Refer to the Block Volume Performance documentation.
What are the performance limits of a single Block Volume attached to a virtual machine?
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.
How do I achieve the maximum performance for my application?
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.
How many Block Volumes can I attach to a compute instance?
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.
Can I move my Block Volumes to other compute instances?
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.
How is my data secure?
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.
Are there different performance and price options for Block Volumes?
Yes. For information, refer to Block Volume Elastic Performance Options and Block Volume Pricing.
Can I change the performance and price of a volume?
Yes. For information, refer to Block Volume Elastic Performance Options and Block Volume Pricing.
Does changing the performance of a volume require downtime?
No. You can change the performance of any volume without any application downtime, regardless of whether it is attached to an instance or not.Am I able to dynamically scale when my performance is low?
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.
How long does performance-based auto-tuning take when scaling up and down?
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.
Can auto-tuning my block volume’s performance provide me with any cost savings?
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.
Can I monitor my performance when I use auto-tuning to adjust my performance levels?
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.
Durability
How durable is data stored in Block Volumes?
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.
How can I resize my volume to a larger volume?
You can increase the size of a volume while it’s online without any downtime. For details, check out the technical documentation page.
What is the "read-only" access option and why do I need it?
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.
Is the read-only attachment option supported for boot volumes?
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.
Can I make an already attached volume "read-only"?
No. In order to do that, you first need to detach the volume and then reattach it, specifying the "read-only" attribute.
Can I attach a volume as "read/write" if it is already attached as "read-only"?
No. In order to do that, you first need to detach the volume and then reattach it, specifying the default attachment mode ("read/write").
What options do I have for block volume attachment protocol or type?
You have two options: iSCSI or paravirtualized. Paravirtualized volume attachments are supported for virtual machine instances only.
What is a paravirtualized volume attachment?
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.
How do I know when to use a paravirtualized attachment?
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.
Can I choose which attachment type to use when I attach a volume to an instance?
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.
Is there a performance difference between iSCSI and paravirtualized volume attachments?
Paravirtualized attachments provide lower performance than iSCSI attachments. For more details, refer to the Block Volume Performance documentation.
Back up/restore
Can I back up my block volumes?
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.
Can I back up my operating system disk, also known as a boot volume?
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.
What is a Block Volume backup?
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.
When should I create backups?
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:
- 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
- Number of stored backups: How many backups you need to keep available and the deletion schedule for those you no longer need
How long does a backup require?
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.
What backup options do I have?
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.
Can I perform an incremental backup versus a full on-demand backup?
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).
Does performing a backup have an impact on performance or my access to the live data?
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.
What are the supported backup policies for automated and policy-based scheduled backups?
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.
Can I customize, define, and apply my own backup policy?
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.
What happens to my existing backups when I remove a backup policy from a volume?
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.
What happens to my existing backups when I change a backup policy for a volume?
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.
What happens to my scheduled policy-based backups when I delete a volume?
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.
Can I change the backup policy that was assigned to a volume? How?
Yes. You can do this on the console, the CLI/SDK, or through Terraform by following the online technical documentation.
What time zone is used for automated, policy-based scheduled volume backups?
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.
Can I define multiple schedules in my custom backup 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.
Is it guaranteed that my scheduled backups will happen at the exact times scheduled?
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.
How long does it take to restore a volume?
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.
What is the performance of the restored volume?
Requests to the newly restored volume may have higher latency for a short period of time right after it is restored.
Can I use my backup to move data between availability domains?
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.
Can I back up my operating system disk?
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.
Can I copy Block Volume backups from one region to another?
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.
Can I restore a backup to a different size volume?
Yes. You can restore from your backup to a larger volume up to the currently supported maximum 32 TB volume size.
Clone
What is a volume clone? What does it do?
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.
Can I clone a boot volume? How does it work?
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.
How long does it take to make a clone?
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.
When can I start accessing a cloned 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.
How is this different than a point-in-time snapshot and backup that OCI Block Volumes and other cloud providers already offer?
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.
Do I need to detach a volume before cloning it?
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.
While a volume is being cloned, what happens to data that might change in the source volume?
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.
Can I clone a volume from one availability domain to another?
No. Block volumes are local to their availability domain. You can clone volumes only within the same availability domain.
Can I clone a volume from one compartment to another?
Yes. You need to have the necessary access permissions for the source and destination compartments.
Can I clone a volume from one tenant to another?
No. Volumes are accessible only within a tenant boundary.
Can I clone a volume from one region to another?
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.
Can I create a larger size clone than the source volume?
Yes. You can specify a clone size up to 32 TB.
How many clones can I create from a single volume simultaneously?
It depends on the attachment state of the source volume.
- If the source volume is attached: You can create one clone at a time. Cloning happens using a point-in-time, direct disk-to-disk deep copy, and there is a single point-in-time reference for a source volume while it is being cloned. You need to wait for the first clone operation to complete from the source volume.
- If the source volume is detached: You can create up to 10 clones from the same source volume simultaneously.
Can I clone a volume from a clone that is still being created?
It depends on the lifecycle state of the cloned volume that is being created.
- If the cloned volume is in "available" state: yes.
- If the cloned volume is in "provisioning" state: no. You can create a clone from a cloned volume after it becomes "available."
Can I back up a source volume while it is being cloned?
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.
Can I delete a volume while clones are still in the process of being created from it?
No. A source volume can't be deleted while any of its clones are still hydrating from it.
Are there any restrictions on when I can delete a cloned volume?
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."
Why was my clone volume unexpectedly terminated?
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
What is a boot volume? What does it provide?
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:
- The ability to preserve your boot disk content by keeping it when you terminate a compute instance: You can use the preserved boot volume to create a new instance.
- Highly durable boot disks: Like all block volumes, boot volumes have multiple replicas across an availability domain, giving you peace of mind regarding the durability of your compute instances.
- Compute instance scaling via boot volumes: When you terminate your instance, you have the option to keep its boot volume. You can then create a new bare metal or virtual machine instance, with the same or a different shape, using the original instance and the boot volume you kept.
- Your instances launch faster: All virtual machine Linux instances launch within a minute, and virtual machine Windows instances launch within five minutes.
- All boot volumes are encrypted by default: Just like all OCI Block Volumes, boot volumes are encrypted at rest.
- The ability to easily troubleshoot and repair your boot disks and OS images: You can stop the troubled instance, detach the suspect boot volume, and attach it as block storage to any other instance to troubleshoot and fix it. You can then reattach it to your original compute instance or create a new instance from it.
How do I use Block Volume–backed boot volumes for bare metal or virtual machine instances?
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.
What is the pricing for boot volumes?
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.
Are boot volumes metered and included in my tenancy block storage limit?
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.
Can I launch another instance using a given boot volume?
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.
What is the persistence and durability model for boot volumes?
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.
How can I get the benefits of boot volumes in my existing instances?
All new instances use boot volumes by default. You can reprovision your existing instances by creating a custom image and launching a new instance.
Can I create a backup of a boot volume?
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.
Can I delete a boot volume?
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.
Can I detach a boot volume from a running 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.
Can I attach a boot volume to an instance as block storage to debug issues?
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.
- Stop the instance you want to debug, click on the “Boot Volume” filter, and then click the “Detach Boot Volume” button. Alternately, you can terminate your instance, which persists your boot volume by default.
- Navigate to the new running instance you want to use to debug your boot volume and click the “Attach Block Volume” button.
How do I scale my compute instance to a larger shape by using boot volumes?
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.
What are the performance characteristics of boot volumes?
Boot volumes offer faster compute instance launch times compared to local boot disks.
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.
Can I have a boot volume for my custom image?
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.
Can I create a compute instance with a system boot volume that is larger than the default OS 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.
Can I resize my boot volume after I create my compute instance?
Yes, you can increase the size of a boot volume while it is online without any downtime. For details, check out the technical documentation.
How do I specify a custom boot volume size on the API/CLI?
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.
If I don’t specify a custom boot volume size, what size is used for my compute instance?
The instance will be launched with a default boot volume size that is equal to the size of the selected OS image.
Volume groups
What is a volume group?
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.
How is a volume group used?
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.
How many volumes can I have in 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.
How can I manage volume groups?
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.
Can I attach and detach a volume that is in a volume group?
Yes. Volumes in a volume group can be accessed and operated on individually, in addition to being managed as a group.
What is a volume group backup? How does it work?
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.
Can I use policy-based, automated scheduled backups for a volume group?
Yes. Check out the documentation for more details.
What is a volume group clone? How does it work?
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.
Can I clone and back up a volume group simultaneously?
It depends on the attachment state of the source volumes in the volume group.
- If any of the source volumes in the volume group are attached: You can create one clone of the volume group at a time. Cloning happens using a point-in-time, direct disk-to-disk deep copy, and there is a single point-in-time reference for a source volume while it is being cloned. You need to wait for the first clone operation for the volume group to complete.
- If all the source volumes in the volume group are detached: You can create up to 10 clones from the same source volume group simultaneously.
Is there an additional price for the volume groups and the volume group backup/restore and cloning capabilities?
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.
Where can I find more information about volume groups?
Refer to the volume groups documentation for more information on how to get started with and manage volume groups.
Billing
How am I billed for Block Volumes?
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.
How am I billed for Block Volume backups?
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.
How am I billed for Block Volume cross-region backup copies?
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.