Oci Object Storage Multipart Cleanup

December 18, 2025

OCI Object Storage: Cleaning Up Orphaned Multipart Uploads

Background

I use OCI Object Storage as a target for periodic backups.
The backups are generated by a scheduled routine, uploaded to Object Storage, and older backups are automatically deleted after a fixed retention period using prefix-based lifecycle logic implemented in my own scripts.

This setup had been working reliably.

One day, while checking the Object Storage console, I noticed a warning:

Uncommitted multipart uploads count: More than 1,000 uploads

What made this puzzling was:

The referenced paths didn’t exist in the bucket
No corresponding “folders” were visible
Recent backups looked perfectly fine

This post documents what that warning actually means and how to safely clean up those orphaned uploads.

What Are “Uncommitted Multipart Uploads”?

Object Storage uses multipart uploads automatically for large files.

A multipart upload works in two phases:

Upload object parts
Commit the upload to assemble the final object

If an upload fails before the commit step (for example due to a crash, timeout, restart, or transient network issue), the uploaded parts remain as an incomplete multipart upload.

Key characteristics:

These are not real objects
They do not appear in the Objects list
They consume backend resources
OCI does not automatically delete them

Once the number grows large, OCI displays a warning.

Why These Uploads Are Invisible in the Console

Object Storage is a flat namespace.
“Folders” are simply prefixes that exist only when at least one object is present.

Because incomplete multipart uploads never produce a final object:

No object exists
No prefix hierarchy exists
Nothing shows up in the bucket view

The only way to see them is via multipart upload listing, which is not always exposed in the OCI Console.

Step 1: Set Up OCI CLI

To investigate further, I used the OCI CLI.

oci setup config

Verification:

oci os ns get

Step 2: List Multipart Uploads

To list all incomplete multipart uploads:

oci os multipart list   --bucket-name obj-store   --namespace <namespace>   --all

Sample output:

{
  "object": "backup/2025/09/06/.../DATA_EXPORT.dmp",
  "upload-id": "f8544f02-67ba-2112-15fb-a8df3448457a",
  "time-created": "2025-09-06T22:00:55Z"
}

Important detail:

The object field represents the intended object name, not an actual file.

Step 3: Is It Safe to Delete These?

Yes — always.

Aborting a multipart upload:

Deletes only temporary upload parts
Never deletes completed objects
Never affects visible data

Step 4: Abort a Single Multipart Upload (Manual Test)

/path/to/oci os multipart abort   --bucket-name obj-store   --namespace <namespace>   --object-name "backup/2025/09/06/.../DATA_EXPORT.dmp"   --upload-id f8544f02-67ba-2112-15fb-a8df3448457a   --force

Step 5: Generate Cleanup Commands for Review

oci os multipart list   --bucket-name obj-store   --namespace <namespace>   --all   --query "data[].{object:object,upload_id:\"upload-id\"}"   --output json | jq -r '
  .[] |
  "echo /path/to/oci os multipart abort --bucket-name obj-store --namespace <namespace> --object-name \"" +
  .object +
  "\" --upload-id " +
  .upload_id +
  " --force"
'

Lessons Learned

Multipart uploads can fail silently
Orphaned uploads are invisible in the bucket view
OCI does not auto-clean multipart uploads
CLI access is essential for Object Storage hygiene
Periodic cleanup is a useful safety net

Closing Thoughts

This issue wasn’t about missing data — it was about invisible leftovers.

If you use OCI Object Storage for large uploads, understanding multipart upload behavior and cleanup is essential for long-term operational hygiene.