> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Versioning, lifecycle, and retention

> Protect object history, restore earlier versions, automate aging policies, and prevent protected objects from being deleted too early.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

Match S2 data-protection controls to the recovery and retention requirements of each object prefix.

## Prerequisites

* An existing S2 bucket
* Permission to update bucket settings and policies

## Workflow

<Steps>
  <Step>
    Enable versioning before workloads begin overwriting important keys.
  </Step>

  <Step>
    Set a bucket default retention period or create narrower prefix retention rules.
  </Step>

  <Step>
    Create lifecycle rules for deletion, old-version expiry, or storage-class tiering.
  </Step>

  <Step>
    List versions for a key and test restoration with a non-production object.
  </Step>

  <Step>
    Review active rules before deleting a bucket or changing application key conventions.
  </Step>
</Steps>

## Object versioning

When versioning is enabled, S2 records object history and delete markers. The management API can list versions for a specific key and restore a selected version as the current object.

Version records preserve the object checksum, content headers, metadata, tags, storage class, retention state, and encryption metadata associated with that write.

## Lifecycle rules

* `delete` removes matching current objects after the configured age.
* `expire_versions` removes matching historical versions after the configured age.
* `tier` changes matching objects from the hot storage class to the cold storage class.
* Rules can target a key prefix and use supported ages of 7, 30, or 90 days.
* Disable or delete obsolete rules instead of leaving policies attached to prefixes the application no longer owns.

## Retention rules

A retention rule protects matching objects for a configured number of days. Prefixes let one bucket hold data with different retention requirements, such as `invoices/`, `audit/`, and `temporary/`.

S2 rejects deletion of an object while its effective retention period or legal hold protects it. Validate the required retention policy before storing regulated or contractual records.

## Bucket defaults

* Bucket settings support default retention values of 0, 7, 30, or 90 days.
* The tier-after setting uses the same supported day values and applies to new policy evaluation.
* Changing a bucket default does not rewrite the encryption metadata or content of existing object versions.

## Expected result

<Check>
  Overwrites remain recoverable when versioning is enabled, protected objects resist premature deletion, and aging policies run against intentional prefixes.
</Check>

## Common failures

<Warning>
  * Enabling versioning after an overwrite and expecting an older unversioned body to exist.
  * Using a broad lifecycle prefix that also matches current production objects.
  * Treating a retention rule as a backup. Retention prevents deletion; recovery copies and application-level restore testing remain separate concerns.
  * Changing key prefixes without updating the lifecycle and retention rules that target them.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Access keys, encryption, isolation, and quotas" href="/object-storage/access-and-security">
    Operate S2 credentials, encryption, visibility, tenant isolation, request limits, and customer-plan quotas safely.
  </Card>

  <Card title="S3 operations and presigned access" href="/object-storage/s3-operations-and-presigned-access">
    Use the supported S3 operations, conditional requests, object metadata, tags, multipart uploads, and presigned URLs.
  </Card>

  <Card title="Capacity, monitoring, and recovery" href="/object-storage/operations-and-recovery">
    Monitor bucket usage, handle temporary service responses, protect critical objects, and validate application recovery.
  </Card>
</CardGroup>