Summary

  • Supported Google Cloud Storage buckets have a default seven-day soft-delete retention period. Deleted objects continue accruing storage charges during that window.
  • Switching the policy off later leaves existing objects on their original retention schedules. A steady deletion flow of 1 TiB a day would leave roughly 7 TiB retained under a seven-day window.

The cleanup job has a second landlord

The temporary files have been deleted. The cleanup job succeeded. Somewhere between that green tick and the finance team’s forecast, a recovery window is still collecting rent.

Google Cloud Storage’s soft-delete feature keeps deleted or overwritten objects for a period in which they can be restored after accidental or malicious deletion. For buckets supporting the feature, the default is seven days. Objects leave active use but keep accruing storage charges throughout their retention period.

The pricing page applies storage charges in the same way to live objects, noncurrent versions and soft-deleted objects. The customer has bought a chance to undo a mistake. That chance occupies byte-time, even when the workload has finished with the bytes.

A flat working set can leave a growing queue

Consider a deliberately bounded example. All objects use Standard storage in one location. Object Versioning is off, there are no additional restored copies, and live content stays at 1 TiB. The workload has continuously and evenly deleted 1 TiB a day for at least seven days, under a seven-day soft-delete policy.

At steady state, 1 TiB of deletions a day multiplied by seven days leaves approximately 7 TiB of retained deleted content. Add the 1 TiB still live and roughly 8 TiB of content is accruing storage charges. The working set never grew. Its turnover manufactured another inventory.

This is conditional storage arithmetic. An actual money calculation needs the bucket’s deletion rate, object class, location and contract rate. Requests, networking and discounts sit outside this example; it does not measure an eightfold increase in the entire cloud bill.

The useful comparison is between workloads with the same live footprint. One rarely discards anything. Another sends a fresh working set into paid recovery storage every day. A live-capacity chart can make them look alike while their retained inventories diverge.

Today’s switch leaves yesterday’s reservations intact

The retention period can be set between seven and ninety days, or soft delete can be disabled. New-bucket defaults can also be changed. The important boundary is when the new policy takes effect.

Google applies the change to resources deleted after that point. Existing soft-deleted resources keep the duration in force when they were deleted. An object deleted on day zero under a seven-day policy follows that original schedule even if the feature is switched off on day one.

Stopping future admissions and clearing the old queue are therefore separate events. Existing cohorts depart on their own expiry dates. The newest old cohort may still have almost its full original stay ahead of it. The switch changes new reservations; it cannot check yesterday’s guests out early.

That timing matters to a cost-reduction promise. A team can have changed the policy correctly while its previous inventory remains chargeable. Expecting the next day’s storage line to collapse confuses a future-flow decision with a retroactive cancellation.

Automated deletion can feed the waiting room

Object Lifecycle Management can also send deleted objects into soft delete. Once objects are in that state, lifecycle rules cannot change their storage class or permanently delete them early. With Object Versioning enabled, deleting a live object can first make it noncurrent; the example excluded that additional path.

Google explicitly identifies short-lived temporary objects as a source of potentially substantial extra storage costs. Its examples include query results, staging files and workloads with frequent deletions. A result reproducible in seconds can reserve days of recoverable storage every time it is discarded.

An irreplaceable original and a regenerable intermediate buy different value from that window. The economic decision joins the consequence of loss, the time to regenerate and the cost of retaining the recovery option. A common default saves a meeting; it does not settle that trade.

The time to choose is before the deletion stream starts. Afterwards, existing cohorts keep their calendars. A cleanup script can do its job perfectly while filling the paid waiting room that the budget forgot.

Sources