Cut block storage and snapshot costs on Oracle Cloud

Why this matters

Block volume cost in Oracle Cloud is set when you create the volume. You pay for provisioned GB and for the performance tier, which sets VPUs per GB. A volume that holds 200 GB but is provisioned at 2 TB bills at 2 TB. The same applies to boot volumes, and those often get oversized during a quick build and never get reviewed.

Volume backups are incremental after the first full backup, but they are not free. A daily schedule with long retention, extra on-demand backups, cross-region copies, and separate per-volume jobs for volumes already in a volume group all add stored data. Oracle calls these backups, though many teams call them snapshots.

Detached volumes are the other common leak. A terminated instance can leave boot and block volumes behind. Clones for a test that ran last quarter still bill. None of this shows up in CPU charts, so it sits in the block volume and backup lines until someone looks.

Before you start

Get read access to the compartments you will review. You need to list block volumes, boot volumes, volume groups, backups, backup policies, and attachments. The Console works for a quick view. The OCI CLI is better when you want a CSV you can sort and join with tags.

Pull at least 30 days of volume metrics. Look at VolumeReadThroughput, VolumeWriteThroughput, VolumeReadOps, and VolumeWriteOps, plus used space and provisioned size. Note the peak and the typical level. A volume that peaks for ten minutes a day is a different case from one that runs flat out.

Talk to the application owner before you delete or move anything. A volume can look idle because the app is seasonal, or because it is a standby copy. Check whether the volume is part of a volume group, a clone chain, or a replication setup. Pick a maintenance window for any tier change or migration.

Test a restore before you shorten retention. Pick one backup, restore it to a scratch volume, and mount it. Confirm the data is what you expect. If you cannot restore it, the backup is not a backup. That test also tells you how long a restore takes.

How to do it

Start with the inventory, not the delete button. Use Cost Analysis in the Console to see block volume and backup spend by compartment and tag. Then export the volume and backup list so you can match spend to actual resources. The biggest line is often a small number of oversized volumes, not hundreds of small ones.

Work from low risk to high risk. Unattached volumes and stale clones come first. Performance tier changes and capacity migrations come after that. Backup retention changes come last, because they affect recovery.

Make one change per week where you can. That way the next bill tells you which change worked. If you change tiers, retention, and volume sizes in the same week, you will not know which one saved money or which one caused the latency complaint.

1. Export a volume and backup inventory. List every block volume, boot volume, volume group, and backup across the compartments you own. Include size, performance tier, attachment, creation date, tags, and backup policy. Save it as a CSV so you can sort by cost and owner.
2. Remove unattached and orphaned volumes. Find volumes with no attachment and boot volumes left from terminated instances. Confirm with the owner, take a final backup if needed, then delete the volume. Check the recycle bin setting first so a mistake is recoverable.
3. Right-size provisioned capacity. Compare 30-day peak used space with provisioned GB. If a volume is far larger than its peak, build a smaller replacement, copy the data, and switch the attachment. Oracle block volumes do not shrink in place, so plan a migration window.
4. Match the performance tier to the workload. Use volume metrics to see IOPS and throughput. Move steady low-IO volumes to Lower cost, and turn on performance-based auto-tune for spiky workloads. Test latency before you leave the change in place.
5. Tighten backup schedules and retention. Assign a backup policy that matches recovery needs instead of putting every volume on a long default schedule. Delete old on-demand backups and stale cross-region copies after a restore test. Use volume group backups for multi-volume apps instead of separate per-volume jobs.
6. Clean up clones and test copies. List block volume clones and old test volumes. Give each clone an owner and an expiry date. Delete clones that have served their purpose, and move cold test data to Object Storage.
7. Move cold data off block storage. Archive logs, old exports, and inactive datasets to Object Storage. Keep only active files on block volumes. Update scripts so they write to Object Storage directly instead of filling a block volume.
8. Add tags and budget alerts. Tag volumes by app, owner, and environment. Create a budget alert for block volume and backup spend. Review the alert monthly so new volumes do not recreate the old problem.

How to check it worked

Use Cost Analysis with a filter for Block Volume and a second view for backups. Compare the current month with the month before, and with the same month last year if your usage is seasonal. Sort by compartment and tag so you can see which team or app changed.

Check performance metrics for every volume you moved to a lower tier or put on auto-tune. Look at throughput, IOPS, and latency during the busiest hour. Ask the app owner if any batch job got slower. A cost cut that adds ten minutes to a nightly load may still be fine, but someone needs to make that call.

Run a restore from the new backup policy. Restore a block volume and a boot volume, not just one. Confirm the backup you kept is the one you need, and that the retention window covers your recovery point. Then check that no new unattached volumes have appeared since the cleanup.

Set a monthly review. New instances create new boot volumes. New projects create new clones. A cleanup that runs once will drift back within a quarter.

Mistakes to avoid

Deleting backups before a restore test is the fastest way to turn a cost project into an outage. Keep the base backup and the incrementals that depend on it. If you shorten retention, confirm the oldest backup you keep still restores on its own or with its chain.

Changing a performance tier on a busy database without a test can hurt more than it saves. Lower cost volumes have fewer VPUs per GB. Auto-tune helps with spiky workloads, but watch it for the first week. Also check volume groups before you delete a member, because a group backup can depend on every volume in the group.

Do not stop at block volumes. Boot volumes, cross-region backup copies, and old clones are easy to miss. A clone can look like a test artifact and still carry full provisioned capacity. Tag every volume with an owner and an expiry date for clones.

The last mistake is treating this as a one-time cleanup. Put the review in the monthly close, or hand it to someone who owns it. If you want a second set of eyes, the Cloud cost audit from Cloudverg is a fixed price $4,500 two-week read-only review of up to three cloud accounts, and it ranks storage tier and idle resource findings. It is one option among others.

Frequently asked questions