Block volume and boot volume cleanup on OCI is about finding storage that costs money but does no work: volumes detached from any instance, boot volumes left behind when a compute instance was terminated, and backups that have outlived their usefulness. None of these show up as a running instance, so they survive every casual review of the console and bill month after month until someone goes looking on purpose.
This article sits inside our Oracle cloud cluster. For the wider picture, start with the complete guide to Oracle Cloud (OCI) cost optimization, the pillar this page links up to. Volume cleanup is the Cut step of our See, Cut, Lock, Run method applied to storage, and it is usually the fastest no-risk saving in an OCI estate because deleting genuinely idle storage changes nothing a workload depends on.
Why block and boot volumes keep billing after you forget them
OCI bills block and boot volumes for their provisioned capacity, in gigabytes per month, whether or not they are attached to a running instance. A boot volume is the storage that holds an instance's operating system; a block volume is additional storage you attach for data. When you terminate a compute instance, OCI gives you the option to preserve the boot volume, and that option is often left selected, so the instance disappears from your running-resources view while its boot volume keeps billing indefinitely. Detached block volumes behave the same way. The result is a slowly growing layer of storage that is invisible in the places people usually look.
On top of the volumes themselves, OCI charges for volume backups and for the performance tier each volume is set to. A volume provisioned at a higher performance level than its workload needs is over-tiered, paying for input-output capacity nobody uses. Cleanup addresses all three: idle volumes, stale backups and over-tiered performance.
Terminating a compute instance does not delete its boot volume unless you explicitly choose to. Preserved boot volumes from instances killed months ago are one of the most common sources of silent OCI storage spend. Always check the boot volumes list, not just the running instances list.
Step 1: Find every unattached block volume
In the OCI console, open Block Storage and list block volumes across every compartment and region, not just the one you work in most. Filter for volumes with no attachment. Each unattached volume is billing for its full provisioned size while serving nothing. Before deleting, confirm with the owning team that the data is not needed, because deletion is permanent. For anything uncertain, take a backup first, then delete the volume; the backup costs far less than the live volume and can be restored if someone needs the data later. Searching across all compartments matters, since the same discipline applies as in OCI compartments and tagging for cost allocation, where untagged and uncompartmentalized resources are exactly the ones that hide.
Step 2: Hunt down orphaned boot volumes
Open the Boot Volumes list and look for boot volumes in the AVAILABLE state with no associated running instance. These are the leftovers from terminated instances where the boot volume was preserved. Most are safe to delete once you confirm the instance is genuinely gone for good and no one intends to recreate it from that disk. As with block volumes, back up anything questionable before deleting. Boot volumes are frequently sized at the operating-system default and add up quickly when dozens accumulate across a busy estate.
Step 3: Prune stale volume backups
Volume backups are cheaper than live volumes but still bill for the space they hold, and backup policies often retain far more history than anyone needs. Review your backup retention: a non-production volume rarely needs months of point-in-time copies. Tighten the retention period on the backup policy and delete manual backups that no longer serve a purpose. Be deliberate here, because backups are your safety net for the deletions in steps one and two, so prune the obviously stale ones and keep enough recent coverage to restore if a cleanup turns out to be premature.
Want your OCI storage swept clean?
Our OCI cost audit inventories every block volume, boot volume and backup across all compartments and regions, flags the unattached and orphaned ones, and hands you a safe deletion plan. On the performance model, you pay only from realized savings. No savings, no fee.
Book an OCI cost audit →Step 4: Right-tier the volumes you keep
Not every cleanup is a deletion. Block volumes that stay can often drop a performance tier. OCI offers volume performance settings from a lower-cost tier through balanced and higher-performance options, and the price scales with the input-output capacity you provision. A volume holding logs, archives or infrequently accessed data does not need a high-performance tier, and lowering it cuts cost with no practical impact. This connects to the broader tiering decision in Oracle Cloud storage tiers and cost control, our sibling guide on matching the storage class to the workload.
| What you find | What it means | Action |
|---|---|---|
| Block volume, no attachment | Billing full size, serving nothing | Confirm, back up if unsure, delete |
| Boot volume, no running instance | Orphan from a terminated instance | Confirm instance is gone, delete |
| Months of backups on non-prod | Over-retained, paying for old copies | Tighten retention, delete stale ones |
| High-performance tier on cold data | Over-tiered, paying for unused IO | Lower the performance tier |
Per-gigabyte billing for attached and unattached volumes, the preserve-on-terminate behavior of boot volumes, and the volume performance tiers reflect OCI Block Volume as of May 2026. Verify the current behavior and pricing in Oracle's OCI documentation before deleting in production, and always confirm data is not needed before any permanent deletion.
The OCI Cost Optimization Field Guide includes the storage cleanup checklist, the unattached-volume sweep and the performance-tier decision table in one working document. It is the downloadable companion to this method.
The short version
Block volume and boot volume cleanup on OCI means sweeping every compartment and region for unattached block volumes, orphaned boot volumes from terminated instances and over-retained backups, then deleting what is genuinely idle and right-tiering what stays. Back up anything uncertain before you delete, confirm with owners, and you reclaim storage spend without touching a single running workload. When you want it run thoroughly across the whole estate, that is exactly what our OCI cost optimization service delivers.