Cloud Storage buckets with Object Versioning turned off

What Object Versioning keeps and what it costs

With Object Versioning on, Cloud Storage keeps a noncurrent version every time a live object is replaced or deleted. The Object Versioning overview explains that those versions stay accessible until you remove them, which lets you restore a file someone overwrote with a broken export or deleted by mistake.

It is not free. There is no default limit on the number of versions, and each noncurrent version is charged at the same rate as when it was live. Google also points out that versioning does not protect against deleting the bucket itself, and recommends soft delete as the primary guard against accidental or malicious deletion. The two can be used together: versioning for recent history, soft delete for bucket-level protection.

Checking versioning on a bucket

gcloud storage buckets describe gs://BUCKET_NAME --format="default(versioning_enabled)"

True means versioning is on. No output or False means it is off. List bucket names with gcloud storage buckets list --format="value(name)" to check a whole project.

The check ZopNight runs

ZopNight confirms the bucket record is complete by checking a storage class is present, then reads the bucket’s versioning setting. Unless versioning is reported as enabled, the rule fires; an explicit false and a missing value are treated the same way. Object count, size and access patterns play no part.

Buckets the rule does not report

A bucket whose details were not collected is skipped instead of flagged. Buckets with versioning on are silent, even if they have no lifecycle rule to prune old versions; that gap is covered by GCP GCS Bucket Missing Lifecycle Policy. The rule does not look at soft delete, so a bucket relying on soft delete alone is still reported, as the false-positive note explains.

Data-loss risk, with a cost to fixing it

ZopNight reports a $0 saving. Enabling versioning raises storage cost in proportion to how often objects change, which is why it should go with a lifecycle rule. The risk it removes is a single overwrite or delete wiping data with no copy left.

Enabling versioning without runaway storage

1. Turn it on, per Google’s versioning instructions:

   gcloud storage buckets update gs://BUCKET_NAME --versioning

2. Add an Object Lifecycle Management rule that deletes noncurrent versions after a set number of days or keeps only the newest few.

3. Wait at least 30 seconds after changing the setting before deleting or replacing objects, as Google advises, so the new behaviour applies.

4. Check soft delete is also configured if you need protection against bucket deletion.