2.3 Block Volume Replication, Volume Groups & Backup Policies
Key Takeaways
The Block Volume service is designed for 99.99% annual durability for block and boot volumes, so Oracle still recommends regular backups.
Block Volume replication is asynchronous; Oracle's typical cross-region RPO target is under 30 minutes, but heavy write activity can push it above an hour.
Activating a volume or volume group replica creates a new volume or volume group by cloning the replica; activate the volume group replica to keep all volumes consistent.
Oracle-defined Bronze, Silver, and Gold backup policies use incremental backups, cannot copy backups across regions, and are not supported for scheduled volume group backups.
Block Volume performance can be changed online: Lower Cost is 0 VPUs/GB, Balanced 10, Higher Performance 20, and Ultra High Performance 30–120.
Durability Inside the Availability Domain
The Block Volume service stores multiple copies of every block and boot volume on separate storage servers, with built-in repair. Oracle designs the service for 99.99% annual durability. That protects against disk and server failures, but not against losing the whole availability domain or region, so Oracle recommends regular backups and, for disaster recovery, replication to another location.
Block Volume Replication
Block Volume replication continuously and asynchronously copies block volumes, boot volumes, and volume groups to another location:
- Cross-region replication copies data to a different region. Your tenancy must be subscribed to the destination region, and each source region has a list of allowed destination regions.
- Cross-availability-domain replication copies data to another AD in the same region. It is only available in commercial regions that have more than one availability domain.
Important behaviors to remember:
- Replication starts with an initial synchronization, which can take hours for large volumes. After that, replication is continuous.
- Oracle's typical RPO target for cross-region replication is under 30 minutes, but the RPO is not guaranteed. Volumes with heavy write activity can lag by more than an hour.
- Replication causes no downtime and no performance impact on the source volume.
- You cannot resize a volume while replication is enabled. Resizing requires disabling replication, which deletes the replica, and then re-enabling it, which starts a new initial sync.
- The replica is billed at the Lower Cost storage price, whatever the source performance level. Cross-region replication also incurs network transfer charges; cross-AD transfer is not billed.
Activating a Replica
A replica is not attached or used directly. To recover, you activate it. Activation creates a new volume (or a new volume group) by cloning the replica, and that new volume is what you attach to an instance in the recovery location. Replication into the replica continues for the source volume.
Volume Groups for Crash Consistency
Enterprise applications usually spread data across several volumes: a boot volume, data volumes, and log volumes. If each volume were copied on its own schedule, the copies could come from slightly different moments, and a database restored from them might be inconsistent.
A volume group solves this. It bundles boot and block volumes into one unit so that backups, clones, and replicas share a coordinated point in time:
- Crash-consistent backups and clones: all member volumes are captured at the same moment, without stopping the instance.
- Volume group replication: the whole group replicates to another region or AD. Oracle recommends activating the volume group replica, rather than individual volume replicas, so every volume is activated from the same synchronization point.
- Full Stack Disaster Recovery depends on this. Moving compute instances in an FSDR protection group must have their boot and block volumes in a replicated volume group (or in volume group backups copied to the standby region).
Backup Policies
Backups complement replication. Replicas give you the current data; backups give you earlier points in time to recover from corruption, deletion, or ransomware.
Oracle-Defined Policies
Since November 3, 2021, the Oracle-defined policies contain incremental backups only. Their schedules and retention cannot be changed:
| Policy | Schedules (all incremental) |
|---|---|
| Bronze | Monthly on the 1st, kept 12 months; yearly in early January, kept 5 years |
| Silver | Bronze schedules plus weekly on Sunday, kept 4 weeks |
| Gold | Silver schedules plus daily, kept 7 days |
User-Defined Policies
User-defined policies let you set your own frequencies (including hourly), retention periods, and full or incremental backup types. They are required in three common situations:
- Automatic cross-region copy. Only user-defined policies can copy each scheduled backup to another region. If an Oracle-defined policy is close to what you need, duplicate it and enable cross-region copy on the copy. The copied backup keeps the same retention as the source backup.
- Scheduled volume group backups. Oracle-defined policies are not supported for scheduled volume group backups.
- Compliance scenarios that require scheduled full backups.
Vault keys are not copied with cross-region backup copies. If you use customer-managed encryption keys, you specify a key in the destination region when you assign the policy.
Performance Levels and Online Changes
Block Volume performance is purchased as volume performance units (VPUs) per GB. You can change the level of an attached volume online, without detaching it or restarting the instance.
| Performance level | VPUs/GB | IOPS/GB | Max IOPS per volume | Max MB/s per volume | Notes |
|---|---|---|---|---|---|
| Lower Cost | 0 | 2 | 3,000 | 480 | Block volumes only, not boot volumes |
| Balanced (default) | 10 | 60 | 25,000 | 480 | Default for block and boot volumes |
| Higher Performance | 20 | 75 | 50,000 | 680 | High-I/O databases |
| Ultra High Performance | 30–120 | 90–225 | up to 300,000 | up to 2,680 | Requires multipath-enabled attachments |
From Balanced upward, each additional 10 VPUs/GB adds 15 IOPS/GB, following the formula IOPS/GB = 1.5 × VPUs/GB + 45. Size matters too: a Balanced volume reaches its 25,000 IOPS maximum at about 417 GB.
Putting It Together
A typical cross-region design for a stateful compute tier combines a volume group (consistency), cross-region volume group replication (low RPO), and a user-defined backup policy with cross-region copy (point-in-time recovery). Full Stack DR then orchestrates activation of the replica and the launch of compute instances in the standby region.
A database server uses three block volumes: a boot volume, a 4 TB data volume, and a 1 TB redo log volume. The DR plan requires a copy in another region with an RPO measured in minutes, and the recovered database must not be corrupted by data and log volumes captured at different moments. Which design meets these requirements?
The Bronze backup policy on each volume, with a script copying backups every 12 hours
Cross-region replication on each volume separately, activating each replica on its own
Attach the volumes to an instance pool in the other region at the Lower Cost level
A volume group with cross-region replication, then activate the group replica
A transaction system's block volumes use the Balanced performance level. During weekend sales, I/O latency rises, and the business does not allow any downtime or volume detachment to change disk settings. What should the architect do?
Restore a backup to a new Higher Performance volume and reboot to swap mounts
Change the volumes to Higher Performance (20 VPUs/GB) while attached and online
Detach each volume, set it to 30 VPUs/GB, and reattach it with iSCSI
Move the volumes to Lower Cost, which has higher throughput for transactions
Sections you finish are checked off in the contents.