Deleting the current name need not erase retained versions
Track S3 version-qualified data and delete markers, distinguish visibility from physical retention, and recover deliberately without assuming versioning is a backup by itself.
On this page
The question for today
What you’ll understand
- Explain current and noncurrent data versions in a versioning-enabled bucket.
- Distinguish a simple delete marker from permanent version deletion.
- Calculate retained logical payload separately from current listing visibility.
Versioning changes what an overwrite or delete means. In the S3 versioning-enabled general purpose bucket model used here, a new PUT creates another version, and an ordinary DELETE can create a delete marker instead of removing historical payload. A name can therefore appear absent while older data remains retained. That is useful for recovery but dangerous for capacity and deletion assumptions. Track the version identifier and operation type rather than treating every successful DELETE as proof that all bytes are gone.
Current lookup and explicit-version lookup differ
A versioning-enabled key can have one current entry and multiple noncurrent versions. A normal current-key read follows the current entry, while a version-qualified read requests a specific retained version, subject to permissions and policy. A normal PUT does not overwrite the payload of a previous version in place; it creates a new version. This does not make every associated field immutable, because tags and other supported metadata operations have their own contracts. Version IDs are opaque identifiers, not numbers to sort as application sequence counters.
The examples assume versioning is fully enabled, not suspended, and omit special null-version cases. Bucket configuration changes and initial enablement have their own propagation considerations, so do not begin a versioning recovery test by assuming a just-changed setting already governs every operation. Record the returned version ID at write time and preserve the identifiers needed by manifests, retention policies, and restore procedures. Looking up only the current key later can select a different generation than the one the producer intended.
A delete marker hides without destroying earlier payload
A simple DELETE without a version ID creates a delete marker as the current entry in the stated enabled-versioning model. Ordinary GET then treats the current name as deleted rather than automatically serving an older data version. The marker has its own identifier and metadata but no object-data payload. A version-qualified DELETE targets the specified entry for permanent removal if permissions and retention controls allow it. Those operations have very different recovery and capacity consequences despite both being called deletion.
Removing the current delete marker by its explicit version ID can expose the preceding retained data version again. Deleting an older data version does not necessarily change a newer current marker. Recovery should inspect the complete version listing and choose the intended entry rather than repeatedly issuing unqualified DELETE requests, which can add more markers. Retention settings can block a permanent removal while still allowing a new marker on top, so visible absence is not evidence that protected historical data was erased.
Retention and recovery need independent protection
Versioning can help recover an accidental overwrite, but it does not alone prevent an authorized actor from deleting specific versions or changing future lifecycle behavior. A recovery design also addresses access control, protected retention where required, independent failure domains, credentials, and restore testing. Count noncurrent versions and markers in inventory, and distinguish a retention objective from a serving objective. A service that keeps every version forever can preserve history while eventually exhausting its operational budget.
The queue lab illustrates only eligible noncurrent-version cleanup work. Reset, set both λ=3 and μ=2, predict growth from four pending items, then Play or Step. Reset and set both λ=2,μ=3 for a separate draining run. Editing retains time and recomputes from the initial four. The model has no keys, version IDs, delete markers, retention rules, or object sizes, so backlog is not stored byte volume. It shows why arrival of cleanup work and verified completion must both be measured after eligibility has been established elsewhere.
Work it through
Follow visible state and retained payload
In an enabled-versioning bucket, key K receives data version v1 of 10 MiB, then v2 of 20 MiB, then a simple DELETE creates current marker d3. Ignore metadata and coding overhead.
Both data versions remain retained, so logical payload is 10 + 20 = 30 MiB. The current entry is d3, so an ordinary GET treats K as deleted rather than returning those thirty MiB.
Permanently deleting v2 by its version ID, if authorized and unprotected, leaves v1's 10 MiB retained. Marker d3 is still current, so normal GET remains not found.
Removing marker d3 by its explicit version ID then exposes retained v1 as current in this sequence. The intended recovery is v1's ten MiB, not the permanently removed v2.
Visibility and retained payload move independently: a missing current name can still retain thirty or ten MiB, and removing a marker can reveal a surviving older version.
The living notebook
Explore the model
Interactive lab · queue
Version cleanup has its own completion backlog
For each separate run, Reset, set both λ and μ, predict the trend of four initial eligible cleanup jobs, then Play or Step. The fluid model has no version history, marker semantics, retention eligibility, or payload-size accounting.
- Fluid backlog
- 4
- Net rate · λ − μ
- −1 /s
- M/M/1 mean residence
- 1 s
Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forA deleted current name and completed permanent cleanup are different observations.
Pause & reason
Check your understanding
Your turn
Try it yourself
A key retains three data versions of 4, 6, and 8 MiB, with a delete marker current. A team reports zero retained data because its ordinary listing omits the key. Calculate the logical retained payload and explain the missing evidence.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Sum retained data versions rather than only current visible names. A marker changes lookup, not the existence of every earlier version.
Compare with the solution
The retained logical payload is 4 + 6 + 8 = 18 MiB, excluding marker metadata and backend overhead. An ordinary current listing does not enumerate all noncurrent versions. Inspect a version-aware inventory or listing and the relevant permissions and retention rules before claiming permanent deletion or calculating capacity; the current absence alone supplies neither conclusion.
Keep the idea
Take it with you
- Version-qualified identity is different from a current-key lookup.
- A delete marker can hide a name while historical payload remains stored.
- Versioning, protected retention, capacity control, and tested recovery are separate requirements.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.