Key details

  1. Google announced the feature on August 17, 2026.
  2. Soft-delete-enabled buckets are retained for a limited period after project deletion.
  3. If the project is restored during that period, the buckets are restored to their state at project deletion.
  4. The relevant retention period is governed by Cloud Storage soft-delete behavior.
  5. Retained soft-deleted data can continue to create storage cost.

What builders should take away

  1. Add project-deletion recovery to Cloud Storage incident runbooks and document the maximum useful recovery window for your configured retention settings.
  2. Before intentionally deleting a project for data destruction, check whether soft delete will retain buckets beyond the project deletion event.
  3. Test IAM, application dependencies and bucket-name behavior during a recovery drill rather than assuming restored buckets equal a restored service.
  4. Monitor cost for retained soft-deleted data after project deletion, especially in large storage environments.

What changed

On August 17, 2026, Google Cloud announced that when a project is deleted, buckets with soft delete enabled are retained for a limited period instead of being immediately and permanently removed. If the deleted project is restored during that window, those buckets are restored to the state they were in when the project was deleted.

Why it matters

Project deletion has often been treated as a destructive boundary in recovery and teardown planning. This feature adds a recovery path—but also means retained storage can persist after project deletion, so operators need to understand the soft-delete window, storage charges and restoration dependencies.

Project recovery can now bring buckets back with it

Google's August 17 release notes explicitly describe the new behavior: soft-delete-enabled buckets survive project deletion for a limited time and are restored if the project is recovered within that period.

Soft delete remains time-bounded and billable

The bucket is not preserved forever. Recovery depends on the configured soft-delete retention window and Google's project-restoration timing. Retained data can continue to incur storage-related cost during the soft-delete period.

Recovery is not the same as full application restoration

Restoring the project and buckets does not automatically prove that every IAM binding, dependent service, application secret or external integration is back in a usable state. Disaster-recovery tests should include the whole dependency chain.

Teardown runbooks need clearer intent

Teams deleting projects to guarantee data destruction should verify whether soft delete is enabled and whether retained buckets contradict that intent. Teams deleting projects accidentally now have an additional recovery path to incorporate into incident response.

Timeline

2026-08-17

Cloud Storage adds project-deletion soft-delete recovery

Google announced that soft-deleted buckets can survive project deletion and return when the project is restored within the recovery window.

What to watch next

  • More detailed Google guidance on complex restoration edge cases.
  • Interaction with organization-level retention and data-destruction policies.
  • Operational reports involving bucket-name conflicts or incomplete IAM restoration.

Still unclear

  • Exact recovery outcomes can depend on project-restoration timing, configured soft-delete retention and other project resources outside Cloud Storage.
  • Bucket restoration does not guarantee that every surrounding application dependency or permission is restored identically.

Sources

Direct reading behind this dossier.

2 sources
Soft delete
Google Cloud Storage Documentation primary

Retention, recovery and cost mechanics for soft-deleted buckets.