OCI Block Volume Storage Guide

Introduction to OCI Block Volume Storage

OCI Block Volume is a high-performance, durable block storage service that provides persistent storage for compute instances. Block volumes function as raw, unformatted hard drives that you can attach to compute instances, format with a file system, and use for databases, application data, file systems, and boot volumes. Unlike object storage, block storage provides low-latency, consistent I/O performance suited for transactional workloads.

OCI Block Volume stands out from competing cloud block storage services with its transparent pricing model, consistent performance guarantees, and no hidden IOPS charges. Every block volume includes a baseline performance level that scales linearly with volume size, and you can independently tune performance using the Ultra High Performance tier without needing to over-provision volume capacity.

This guide covers block volume types and performance tiers, boot volume management, backup and cloning strategies, volume groups, cross-region replication, and production best practices. All operations include OCI CLI commands for automation alongside console instructions.

Block Volume Performance Tiers

OCI Block Volume offers multiple performance tiers that determine the IOPS and throughput available for your volumes. Unlike AWS EBS where performance is tied to volume type (gp3, io2, etc.), OCI allows you to change the performance tier of any existing volume without detaching it or creating a new volume.

Lower Cost: Provides 2 IOPS per GB with a maximum of 3,000 IOPS per volume. Throughput scales at 240 KB/s per GB up to 480 MB/s. This tier is suitable for boot volumes, development environments, log storage, and infrequently accessed data.

Balanced (Default): Provides 60 IOPS per GB with a maximum of 25,000 IOPS per volume. Throughput scales at 480 KB/s per GB up to 480 MB/s. This tier is the best choice for most general-purpose workloads including web servers, small databases, and application servers.

Higher Performance: Provides 75 IOPS per GB with a maximum of 35,000 IOPS per volume. Throughput scales at 600 KB/s per GB up to 480 MB/s. Suited for performance- sensitive applications and medium-sized databases.

Ultra High Performance: Provides up to 225 IOPS per GB with a maximum of 300,000 IOPS per volume. Throughput can reach 2,680 MB/s. This tier is designed for the most demanding workloads including large OLTP databases, real-time analytics, and high-frequency trading systems. Ultra High Performance requires multipath-enabled attachments.

# Create a block volume with the Balanced performance tier
oci bv volume create \
  --compartment-id $C \
  --availability-domain $AD \
  --display-name "app-data-vol" \
  --size-in-gbs 100 \
  --vpus-per-gb 10 \
  --wait-for-state AVAILABLE

# Performance tier VPUs-per-GB mapping:
#   Lower Cost:           0
#   Balanced:            10  (default)
#   Higher Performance:  20
#   Ultra High Perf:     30-120

# Create an Ultra High Performance volume
oci bv volume create \
  --compartment-id $C \
  --availability-domain $AD \
  --display-name "database-vol" \
  --size-in-gbs 500 \
  --vpus-per-gb 120 \
  --wait-for-state AVAILABLE

# Change performance tier of an existing volume (online)
oci bv volume update \
  --volume-id <volume-ocid> \
  --vpus-per-gb 20 \
  --wait-for-state AVAILABLE

# List all block volumes
oci bv volume list \
  --compartment-id $C \
  --query 'data[].{"display-name":"display-name", "size-gb":"size-in-gbs", "vpus-per-gb":"vpus-per-gb", "lifecycle-state":"lifecycle-state"}' \
  --output table

Attaching and Mounting Block Volumes

Block volumes must be attached to a compute instance before they can be used. OCI supports two attachment types: iSCSI and paravirtualized. iSCSI attachments use the iSCSI protocol over the network and require running iSCSI commands on the instance to connect the volume. Paravirtualized attachments use the hypervisor's native block device interface and appear as regular block devices without any additional configuration.

For most workloads, paravirtualized attachments are simpler to configure and provide comparable performance. iSCSI attachments offer slightly higher IOPS for workloads that require multipath I/O, which is mandatory for Ultra High Performance volumes. A single compute instance can have up to 32 block volume attachments.

# Attach a volume using paravirtualized attachment
oci compute volume-attachment attach \
  --instance-id <instance-ocid> \
  --volume-id <volume-ocid> \
  --type paravirtualized \
  --display-name "data-attachment" \
  --wait-for-state ATTACHED

# Attach using iSCSI (required for Ultra High Performance)
oci compute volume-attachment attach \
  --instance-id <instance-ocid> \
  --volume-id <volume-ocid> \
  --type iscsi \
  --display-name "db-attachment" \
  --wait-for-state ATTACHED

# Get iSCSI connection details
oci compute volume-attachment get \
  --volume-attachment-id <attachment-ocid> \
  --query 'data.{iqn:iqn, ipv4:ipv4, port:port}'

# On the compute instance, connect iSCSI volume:
# sudo iscsiadm -m node -o new -T <iqn> -p <ipv4>:<port>
# sudo iscsiadm -m node -o update -T <iqn> -n node.startup -v automatic
# sudo iscsiadm -m node -T <iqn> -p <ipv4>:<port> -l

# Format and mount the volume (first time only)
# sudo mkfs.ext4 /dev/sdb
# sudo mkdir /mnt/data
# sudo mount /dev/sdb /mnt/data
# echo "/dev/sdb /mnt/data ext4 defaults,_netdev 0 2" | sudo tee -a /etc/fstab

# List volume attachments for an instance
oci compute volume-attachment list \
  --compartment-id $C \
  --instance-id <instance-ocid> \
  --query 'data[].{"display-name":"display-name", "lifecycle-state":"lifecycle-state", "attachment-type":"attachment-type"}' \
  --output table

Boot Volumes

Every compute instance has a boot volume that contains the operating system and is created automatically when you launch an instance. Boot volumes are a special type of block volume that persist independently of the instance lifecycle. When you terminate an instance, you can choose to preserve the boot volume, allowing you to launch a new instance from the same boot volume later.

The default boot volume size is 46.6 GB for most Oracle Linux images, but you can specify a larger size during instance creation (up to 32 TB). You can also resize boot volumes online without stopping the instance, though you will need to extend the file system from within the instance to use the additional space.

# List boot volumes
oci bv boot-volume list \
  --compartment-id $C \
  --availability-domain $AD \
  --query 'data[].{"display-name":"display-name", "size-gb":"size-in-gbs", "lifecycle-state":"lifecycle-state"}' \
  --output table

# Resize a boot volume online
oci bv boot-volume update \
  --boot-volume-id <boot-volume-ocid> \
  --size-in-gbs 100 \
  --wait-for-state AVAILABLE

# After resizing, extend the file system on the instance:
# For Oracle Linux / CentOS (XFS):
# sudo growpart /dev/sda 3
# sudo xfs_growfs /

# For Ubuntu (ext4):
# sudo growpart /dev/sda 1
# sudo resize2fs /dev/sda1

# Create a boot volume backup
oci bv boot-volume-backup create \
  --boot-volume-id <boot-volume-ocid> \
  --display-name "pre-upgrade-backup" \
  --type FULL \
  --wait-for-state AVAILABLE

# Launch an instance from a boot volume backup
oci compute instance launch \
  --compartment-id $C \
  --availability-domain $AD \
  --shape "VM.Standard.E4.Flex" \
  --shape-config '{"ocpus": 2, "memoryInGBs": 16}' \
  --source-boot-volume-backup-id <backup-ocid> \
  --subnet-id <subnet-ocid> \
  --display-name "restored-instance"

Backup Policies and Scheduling

OCI provides both manual and automated backup strategies for block volumes and boot volumes. Manual backups give you full control over when backups are created, while backup policies automate the process based on predefined or custom schedules.

OCI includes three built-in backup policies: Bronze (monthly incremental, retained for 12 months), Silver (weekly incremental + monthly full, retained for 4 weeks/12 months), and Gold (daily incremental + weekly full + monthly full, retained for 7 days/4 weeks/12 months). You can also create custom backup policies with specific schedules, retention periods, and backup types.

Backups are stored in Object Storage and are region-specific by default. You can copy backups to other regions for disaster recovery. Incremental backups only capture changes since the last backup, making them faster and more storage-efficient than full backups.

# Create a manual block volume backup
oci bv backup create \
  --volume-id <volume-ocid> \
  --display-name "manual-backup-2026-03" \
  --type INCREMENTAL \
  --wait-for-state AVAILABLE

# List available backup policies
oci bv volume-backup-policy list \
  --query 'data[].{"display-name":"display-name", id:id}' \
  --output table

# Assign a backup policy to a volume
oci bv volume-backup-policy-assignment create \
  --asset-id <volume-ocid> \
  --policy-id <policy-ocid>

# Create a custom backup policy
oci bv volume-backup-policy create \
  --compartment-id $C \
  --display-name "custom-daily-policy" \
  --schedules '[{
    "backupType": "INCREMENTAL",
    "period": "ONE_DAY",
    "retentionSeconds": 604800,
    "hourOfDay": 2,
    "timeZone": "UTC",
    "scheduleType": "DAILY"
  }]'

# List backups for a volume
oci bv backup list \
  --compartment-id $C \
  --volume-id <volume-ocid> \
  --query 'data[].{"display-name":"display-name", type:type, "time-created":"time-created", "size-gb":"size-in-gbs"}' \
  --output table

# Restore a volume from a backup
oci bv volume create \
  --compartment-id $C \
  --availability-domain $AD \
  --display-name "restored-volume" \
  --volume-backup-id <backup-ocid> \
  --wait-for-state AVAILABLE

Volume Groups and Cross-Region Replication

Volume groups allow you to manage multiple block volumes and boot volumes as a single unit. This is particularly useful for applications that span multiple volumes, such as a database with separate data, redo log, and archive log volumes. Volume group backups create coordinated, crash-consistent snapshots of all volumes in the group simultaneously.

Cross-region replication provides asynchronous replication of block volumes to a different OCI region for disaster recovery. The replica volume is continuously updated with changes from the source volume, typically with a Recovery Point Objective (RPO) of a few minutes. In a disaster scenario, you can activate the replica volume and attach it to instances in the target region.

# Create a volume group
oci bv volume-group create \
  --compartment-id $C \
  --availability-domain $AD \
  --display-name "database-volumes" \
  --source-details '{"type": "volumeIds", "volumeIds": ["<data-vol-ocid>", "<log-vol-ocid>", "<archive-vol-ocid>"]}' \
  --wait-for-state AVAILABLE

# Create a volume group backup
oci bv volume-group-backup create \
  --compartment-id $C \
  --volume-group-id <volume-group-ocid> \
  --display-name "db-group-backup" \
  --type FULL \
  --wait-for-state AVAILABLE

# Enable cross-region replication for a volume
oci bv volume create \
  --compartment-id $C \
  --availability-domain $AD \
  --display-name "replicated-volume" \
  --size-in-gbs 200 \
  --block-volume-replicas '[{"availabilityDomain": "<target-ad>", "displayName": "dr-replica"}]' \
  --wait-for-state AVAILABLE

# Copy a backup to another region
oci bv backup copy \
  --volume-backup-id <backup-ocid> \
  --destination-region "us-phoenix-1" \
  --display-name "dr-backup-copy"

Block Volume Resizing and Online Operations

OCI Block Volume supports online volume resizing, allowing you to increase the size of a volume while it remains attached and in use. This eliminates the need for downtime during capacity expansion. Volumes can be resized from their current size up to 32 TB. Note that volumes can only be grown, not shrunk.

After resizing the block volume in OCI, you must extend the partition and file system from within the compute instance to use the additional space. The process varies depending on your operating system and file system type.

# Resize a block volume online (increase only)
oci bv volume update \
  --volume-id <volume-ocid> \
  --size-in-gbs 500 \
  --wait-for-state AVAILABLE

# On the instance, rescan the iSCSI target (if iSCSI attachment)
# sudo iscsiadm -m node -T <iqn> -p <ipv4>:<port> -R

# Extend the partition (if partitioned)
# sudo growpart /dev/sdb 1

# Resize the file system
# For ext4:
# sudo resize2fs /dev/sdb1

# For XFS:
# sudo xfs_growfs /mnt/data

# Verify new size
# df -h /mnt/data

# Detach a volume (graceful)
oci compute volume-attachment detach \
  --volume-attachment-id <attachment-ocid> \
  --wait-for-state DETACHED

# Delete a volume
oci bv volume delete \
  --volume-id <volume-ocid> \
  --force

Performance Tuning and Best Practices

Maximizing block volume performance requires attention to several factors beyond just selecting the right performance tier. Here are the key tuning parameters and best practices:

Use Multipath for Ultra High Performance: Ultra High Performance volumes require multipath-enabled iSCSI attachments. Multipath uses multiple network paths between the instance and the volume, aggregating bandwidth and providing failover. Enable multipath with --is-multipath true on the attachment.

Volume Size Affects Performance: IOPS and throughput scale linearly with volume size within each performance tier. A 100 GB Balanced volume provides 6,000 IOPS, while a 500 GB volume provides 25,000 IOPS (the tier maximum). If you need more IOPS than your current volume provides, either increase the volume size or upgrade the performance tier.

Instance Shape Limits: Each compute shape has maximum block volume bandwidth and IOPS limits. A VM.Standard.E4.Flex with 1 OCPU supports up to 24,000 IOPS and 480 MB/s, while a 64 OCPU instance supports up to 400,000 IOPS. Ensure your instance shape can handle the aggregate I/O of all attached volumes.

File System Choice: For high-IOPS workloads, XFS generally outperforms ext4, especially for large files and parallel I/O. For database workloads, consider using ASM (Automatic Storage Management) or raw devices to bypass the file system overhead entirely.

I/O Scheduler: For block volumes on OCI, use the noop ornone I/O scheduler. The underlying storage system already handles I/O optimization, and a complex I/O scheduler on the instance can add unnecessary overhead.

# Attach with multipath enabled (for Ultra High Performance)
oci compute volume-attachment attach \
  --instance-id <instance-ocid> \
  --volume-id <volume-ocid> \
  --type iscsi \
  --is-multipath true \
  --display-name "uhp-attachment" \
  --wait-for-state ATTACHED

# Monitor volume IOPS and throughput
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_blockstore" \
  --query-text 'VolumeReadOps[5m]{resourceId = "<volume-ocid>"}.rate()'

oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_blockstore" \
  --query-text 'VolumeWriteOps[5m]{resourceId = "<volume-ocid>"}.rate()'

# Check throughput
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_blockstore" \
  --query-text 'VolumeReadThroughput[5m]{resourceId = "<volume-ocid>"}.rate()'

# Set I/O scheduler to noop on the instance
# echo noop | sudo tee /sys/block/sdb/queue/scheduler

Block Volume Pricing and Comparison

OCI's block volume pricing is straightforward compared to AWS EBS, where you pay separately for storage capacity and provisioned IOPS. In OCI, the performance tier determines both the per-GB price and the IOPS/throughput available. There are no separate IOPS charges or burst credit mechanics. Backup storage costs approximately $0.05/GB/month.