Backups
S3 versioning for backup and recovery: useful history with real costs
Versioning can preserve older generations when the same object key is overwritten or deleted. That history is valuable for some recovery workflows, but it also consumes storage and does not replace a separate backup or retention policy.
Versioning keeps generations of a key
With versioning enabled, a new write can create another generation while preserving the previous bytes. A delete may create a marker while older versions remain retrievable by version identifier.
Applications that always write new unique keys receive less benefit because they already preserve old objects by writing unique keys.
Capacity includes old versions
A 100 GB object overwritten every day can accumulate far more than 100 GB of billed storage. Hard quotas can stop later writes when old generations consume the remaining capacity.
Monitor object versions and establish lifecycle rules only after understanding which historical copies the recovery plan actually needs.
Versioning is not immutability
A sufficiently privileged credential may be able to delete versions. If ransomware resistance requires protected retention, test Object Lock or another retention control explicitly. Versioning by itself does not make data undeletable.
Keep backup credentials scoped so the software does not receive version-deletion privileges it never uses.
Restore tooling must understand versions
The S3 API can retrieve a specific version, but an application may only request the current object. Document how operators locate and restore an earlier generation after accidental overwrite.
A recovery drill should intentionally replace a test object, locate its previous version and restore the expected checksum.
Combine versioning with independent copies when needed
Version history inside one provider project protects against some logical mistakes. It does not eliminate provider, account or region failure from the threat model.
For high-value data, decide whether a second independent destination is required and test how version history is preserved or flattened during replication.