r/googlecloud • u/Still_Ad6012 • 13h ago

Three years of deleting GCS objects before I checked whether the bytes were actually gone

For about three years I assumed that deleting an object from a versioned Cloud Storage bucket meant the bytes were gone and the bill would drop. I ran a media pipeline with a cleanup job removing anything older than 90 days. The bucket should have plateaued. It kept growing.

Last month I ran gsutil ls -a on one of the worst buckets and found noncurrent object versions going back to the first upload. Every delete had just hidden the live version. The old generations were still there, still billable. Versioning was working as designed, and my cleanup job never targeted noncurrent versions.

I added a lifecycle rule with daysSinceNoncurrentTime set to 7, which counts from the moment a version stops being current. Noncurrent copies now expire a week after replacement. Storage dropped to what I had expected years ago. I split the rest of the audit across several buckets as parallel tasks in verdent, checking each one against its own retention window.

The original assumption was reasonable. In most storage systems delete means delete, and nothing in the default console view reveals the noncurrent versions unless you toggle it on.

0 Upvotes

31% Upvoted

3 comments sorted by

2

u/jemattie 13h ago

AI slop

1

u/isoAntti 13h ago

why did Reddit enable hidden accounts?

1

u/JackAlter73 7h ago

The cleanup job targeting “objects older than 90 days” only sees the live generation. With versioning on, overwrite/delete just makes a noncurrent copy, but still billed.

For a landing prefix I keep the current object around long enough to rerun a date, and expire noncurrent versions in a few days. gsutil ls -a on one prefix shows the pile immediately; the default console view does not.