Data protection & recovery
Object versioning
Object versioning is a bucket setting in S3-compatible storage that keeps every version of an object instead of replacing it. When versioning is enabled, an overwrite adds a new version and keeps the old one, and a delete hides the object behind a marker without removing its data. Earlier versions stay retrievable until they are explicitly removed.
How do operations behave in a versioned bucket?
Each version of an object has its own version ID. The most recent one is the current version, and the others are noncurrent.
| Operation | Without versioning | With versioning |
|---|---|---|
| Write to an existing key | Old data is replaced | New version becomes current, old one is kept |
| Delete | Object is removed | A delete marker is added, versions remain |
| Read | Returns the object | Returns the current version, or an older one by ID |
| Delete with a version ID | Not applicable | Permanently removes that version |
| Undelete | Not possible | Remove the delete marker |
What does versioning protect against?
Versioning protects against accidental overwrite and deletion, since the previous state can be restored. It also limits the damage from software faults and from ransomware that encrypts objects in place, because the earlier versions survive. It does not stop someone with permission to delete specific versions from removing them. For that, versioning is combined with Object Lock, which prevents version deletion for a retention period. Versioning is in fact a prerequisite for Object Lock.
What does it cost?
Every version occupies capacity. A data set that is overwritten often can consume several times its visible size, and because normal listings show only current versions, the growth is easy to miss. Delete markers also accumulate and slow down listing. Reporting current and noncurrent capacity separately makes the cost visible. S3 versioning costs works through the arithmetic.
How is the growth controlled?
Lifecycle rules manage versions automatically. A rule can expire noncurrent versions after a number of days, keep only the newest few, and remove delete markers that have no versions left behind them. The right settings depend on how far back a restore might need to reach. Thirty days of noncurrent versions covers most accidental changes. Once versioning has been enabled on a bucket it can be suspended but not removed, so it is worth deciding on the lifecycle rules at the same time. Storage lifecycle management covers the mechanism.
Frequently asked questions
Is versioning a backup?
No. Versions live in the same system as the original. They protect against logical mistakes, not against loss of the storage system or site.
Can versioning be turned off?
It can be suspended, which stops new versions being created. Existing versions remain until removed.
Do old versions count toward storage usage?
Yes. Every version is stored in full and occupies capacity.
Related terms
- S3 bucket: where versioning is switched on.
- Storage lifecycle management: rules that expire old versions.
- Data durability: protection against physical loss, a different concern.
- Object metadata: where version IDs are recorded.
- Bucket policy: who is allowed to delete specific versions.