The setting named keep less was the one that removed the protection
- date
- 20260726 (original trap identified); corrected 20260920
- what happened
- Backblaze B2's bucket lifecycle setting defaults to Keep all versions, which silently keeps every version a backup tool deletes as a hidden version the account is still billed for, so pruning appeared to succeed and reclaimed nothing. The setting was changed to Keep only the last version, which looked like the obvious tightened alternative. A correction eight weeks later, verified against B2's own API documentation, found that option makes hidden versions permanently unrecoverable after one day.
- what it cost
- An unmeasured but real security exposure. The offsite bucket was confirmed to be running under this setting on the day it was found, meaning a compromised backup-writer credential could have hidden the entire offsite backup set with no recovery window.
- what changed
- The bucket moved to a custom rule, hide-to-delete after 30 days, plus the design that permanent-delete permission belongs only to a separate vaulted administrative key. Whether the backup tool's own key actually lacks deleteFiles was not confirmed on 20260920: the 30-day rule is the verified half, the key scope the pending half. The cost of the 30 days is pruned packs billed a month longer, unmeasured at this account's churn.
- the check now
- Never treat a cloud storage lifecycle setting's plain-English name as sufficient. Verify what it does against the provider's own API documentation, specifically checking which permission level, write or delete, each destructive-looking operation actually requires.
Cloud object storage services often expose version retention as a small handful of named presets, and the names can be actively misleading about what security property each one provides. The first mistake here was a cost problem, not a security one. The default keeps every version forever, silently billing for space a backup tool believed it had already reclaimed by pruning.
The fix for that, choosing the option that sounded like the tightened version of the same idea, quietly introduced a much worse problem. Once a file version is hidden, it becomes permanently and irreversibly gone after one day. Hiding requires only a write permission, not a delete permission, an important and easy-to-miss detail in how these systems distinguish the two. That defeats the point of keeping hidden versions at all, which is to survive a scenario where the credential doing the writing has been compromised and is being used to destroy data. With a one-day window, an attacker barely needs to act quickly.
The correction came from reading the provider’s own API documentation rather than relying on the preset names, which is the transferable lesson. A security-relevant setting’s name is a summary written for a general audience. The actual mechanism, especially which permission level triggers which effect, deserves verification against primary documentation before being trusted, particularly for the one setting whose entire purpose is protecting against an already-compromised credential.
Source: node0 lessons v0.1, lesson 3.20. Sanitized: checklist v0.1, 20260921; bucket name, S3 endpoint; voice pass 20260921. Part of oznog.com/node0.