Object Storage - Lifecycle and replication use cases
Objective
OVHcloud Object Storage offers two powerful automation features that, when combined, can address a wide range of production data management challenges:
- Lifecycle policies automate transitions between storage classes (Standard → Infrequent Access → Active Archive → Cold Archive) and the expiration (deletion) of objects based on rules you define.
- Asynchronous replication automatically copies objects from a source bucket to one or more destination buckets, within the same region or across different regions.
Used in isolation, each feature already provides significant value. Used together, they unlock architectures that are simultaneously cost-efficient, resilient, and compliant.
This guide covers 7 production-ready use cases combining both features:
- Regulatory archiving and compliance
- Disaster recovery
- Data lake and automated tiering
- Geographic content distribution
- Dev/Staging environment management
- Logs and observability
- SaaS multi-tenant backup
Requirements
- An active OVHcloud Public Cloud project.
- Object Storage buckets created in one or more OVHcloud regions. Refer to our guide Getting started with Object Storage if needed.
- A working understanding of OVHcloud storage classes. Refer to our guide Choosing the right storage class for your needs.
- A working understanding of lifecycle policies. Refer to our guide Object Storage - Managing object lifecycle.
- A working understanding of asynchronous replication. Refer to our guide Object Storage - Mastering asynchronous replication across your buckets.
- For CLI steps only: the AWS CLI installed and configured with your OVHcloud Object Storage credentials and endpoint. Refer to our guide Getting started with Object Storage.
Storage class mapping reference
All CLI examples in this guide use the S31 API StorageClass values as required for write operations (PUT, lifecycle transitions, replication destination) on the OVHcloud .io endpoint. The mapping differs between 3-AZ regions and 1-AZ regions.
The mapping below reflects the current state as of 2026-01-03. Refer to the Object Storage - Endpoints and geoavailability guide for the full and up-to-date reference.
3-AZ regions (e.g. Paris eu-west-par, Milan eu-south-mil)
1-AZ regions (e.g. GRA, SBG, DE, UK, BHS, WAW, ...)
In 1-AZ regions, GLACIER_IR, GLACIER, and DEEP_ARCHIVE all map to Infrequent Access — there are no deeper archive tiers available. Cold Archive is currently available in 3-AZ regions only, and only in Paris (eu-west-par).
This mapping applies to the .io endpoint only. The legacy .perf endpoint uses a different mapping and is maintained for backward compatibility purposes only.
Instructions
You can implement each use case from the OVHcloud Control Panel or with the AWS CLI.
CLI examples use the OVHcloud endpoint format:
Replace <region> with your actual region slug (e.g. gra, sbg, de, uk), and replace all placeholder bucket names and prefixes with your own values.
Use case 1 - Regulatory archiving and compliance
Context
Organisations in regulated industries (finance, healthcare, legal) must retain certain data for legally mandated periods — often 5 to 10 years — while keeping storage costs under control and ensuring data is available in a secondary jurisdiction if required. A typical requirement combines:
- Automatic transition to cheaper storage classes as data ages
- A compliant copy in a geographically separate region
Architecture
The lifecycle policy on the primary bucket handles cost optimisation. Asynchronous replication to the secondary bucket handles geographic redundancy and jurisdiction requirements. The secondary bucket can have its own, independent lifecycle policy for long-term retention.
Implementation
Step 1 - Enable versioning on both buckets
Asynchronous replication requires versioning to be enabled on both the source and destination buckets.
Go to the section of your OVHcloud Control Panel and select your project. Click Object Storage in the left-hand menu, then click the name of your source bucket (compliance-primary-<region>) from the My containers tab.
In the General information tab, enable versioning and click Confirm.
Repeat this operation for the destination bucket (compliance-archive-<region2>).
Step 2 - Configure replication on the primary bucket
From the My containers tab, click the name of your source bucket, then select the Replication tab. Click Add a replication rule. Set the destination bucket to compliance-archive-<region2>, set the destination storage class to Standard, enable Replicating delete markers, and click Create.
Step 3 - Apply the lifecycle policy on the primary bucket
This configuration transitions objects through Infrequent Access, Active Archive, and Cold Archive as data ages. Archive tiers are only available in 3-AZ regions.
From the My containers tab, click the name of your source bucket and select the Lifecycle tab. Click Create a rule. Leave the prefix filter empty.
For 3-AZ regions, add three transition actions: Infrequent Access at day 30, Active Archive at day 90, and Cold Archive at day 365. For 1-AZ regions, add only the Infrequent Access transition at day 30.
Click Create rule.
Step 4 - Apply a long-term retention lifecycle on the secondary bucket
This configuration retains objects for 7 years (2555 days) before expiration.
From the My containers tab, click the name of your destination bucket and select the Lifecycle tab. Click Create a rule. Leave the prefix filter empty. Add an expiration action set to 2555 days.
Click Create rule.
Replication copies the object at the time of its creation. If the object transitions to a cheaper storage class on the primary bucket, the replica in the secondary bucket retains its own storage class independently. This means you can optimise costs differently on each side.
Use case 2 - Disaster recovery
Context
A disaster recovery (DR) strategy for Object Storage requires a copy of all data in a remote region, with a recovery time objective (RTO) and recovery point objective (RPO) that align with your SLA. The typical pattern is:
- Primary bucket: short retention, Standard storage class, low cost
- DR bucket: full copy in a remote region, longer retention in Infrequent Access class to reduce standby cost
Asynchronous replication ensures the DR bucket stays up to date (approximately 15 minutes lag). Lifecycle policies on the primary bucket keep costs down by expiring objects that are already safely replicated.
Architecture
Implementation
Step 1 - Enable versioning on both buckets
Go to the section of your OVHcloud Control Panel and select your project. Click Object Storage in the left-hand menu.
For each bucket (dr-primary-<region> and dr-backup-<region2>), click its name from the My containers tab, then in the General information tab, enable versioning and click Confirm.
Step 2 - Configure replication to the DR bucket
Replicated objects are stored directly in Infrequent Access on the DR side to reduce standby storage costs.
From the My containers tab, click the name of your primary bucket and select the Replication tab. Click Add a replication rule. Set the destination to dr-backup-<region2>, set the destination storage class to Infrequent Access, disable Replicating delete markers to protect the DR copy from accidental deletions, and click Create.
Step 3 - Apply a short-retention lifecycle on the primary bucket
Objects expire after 60 days; non-current versions are cleaned up after 7 days.
From the My containers tab, click the name of your primary bucket and select the Lifecycle tab. Click Create a rule. Leave the prefix empty. Add an expiration action set to 60 days and a non-current version expiration set to 7 days.
Click Create rule.
Step 4 - Apply a longer retention lifecycle on the DR bucket
From the My containers tab, click the name of your DR bucket and select the Lifecycle tab. Click Create a rule. Leave the prefix empty. Set expiration to 365 days and non-current version expiration to 30 days.
Click Create rule.
Replicating delete markers is disabled in the DR replication rule above. This prevents deletions on the primary bucket from propagating to the DR bucket, protecting the replica against accidental or malicious deletions. Adjust this setting if your use case requires full consistency between both buckets.
Use case 3 - Data lake and automated tiering
Context
Data lake architectures generate large volumes of objects that are queried frequently when fresh (hot), occasionally after a few weeks (warm), and rarely beyond a few months (cold). Storing everything at the same storage class is unnecessarily expensive. The combination of lifecycle tiering on a central bucket and replication to an analytics-dedicated bucket enables:
- Automatic cost reduction as data ages on the primary lake bucket
- A stable, always-Standard copy available to analytics tools in another region, unaffected by the tiering transitions
Architecture
Implementation
Step 1 - Enable versioning on both buckets
Go to the section of your OVHcloud Control Panel and select your project. Click Object Storage in the left-hand menu.
For each bucket, click its name from the My containers tab, then in the General information tab, enable versioning and click Confirm.
Step 2 - Configure replication to the analytics bucket
From the My containers tab, click the name of your main data lake bucket and select the Replication tab. Click Add a replication rule. Leave the prefix filter empty. Set the destination to datalake-analytics-<region2>, set the destination storage class to Standard, disable Replicating delete markers, and click Create.
Step 3 - Apply prefix-based tiering lifecycle on the main bucket
This configuration applies different tiering schedules to raw data and processed data using prefix filters.
From the My containers tab, click the name of your main bucket and select the Lifecycle tab. Use Create a rule to add two rules separately:
- Rule 1 - prefix
raw/: transitions to Infrequent Access at day 30, Active Archive at day 90, Cold Archive at day 365 (3-AZ only) - Rule 2 - prefix
processed/: transitions to Infrequent Access at day 60, Active Archive at day 180 (3-AZ only)
The analytics replica keeps all objects in Standard class regardless of transitions applied on the source. Your analytics tools always access immediately available data without retrieval delays or additional restore costs.
Use case 4 - Geographic content distribution
Context
Organisations distributing static assets (media files, software packages, firmware updates, documentation) to users in multiple regions benefit from keeping copies close to their end users. The combination of replication and lifecycle gives you:
- Automatic propagation of new content to regional buckets
- Automatic expiration of outdated versions locally, preventing storage drift over time
Architecture
Implementation
Step 1 - Enable versioning on all buckets
Go to the section of your OVHcloud Control Panel and select your project. Click Object Storage in the left-hand menu.
For each of the three buckets, click its name from the My containers tab, then in the General information tab, enable versioning and click Confirm.
Step 2 - Configure multi-destination replication on the origin bucket
OVHcloud Object Storage supports multiple replication rules on a single bucket.
From the My containers tab, click the name of your origin bucket and select the Replication tab. Click Add a replication rule. Leave the prefix empty, set the destination to content-eu-west-<region2>, enable Replicating delete markers, and click Create. Click Add a replication rule again to add a second rule with destination content-eu-central-<region3> and the same settings.
Step 3 - Apply expiration lifecycle on the regional buckets
Remove non-current versions after 30 days to prevent accumulation of stale content.
From the My containers tab, click the name of a regional bucket and select the Lifecycle tab. Click Create a rule. Leave the prefix empty. Set non-current version expiration to 30 days and abort incomplete multipart upload cleanup to 7 days.
Click Create rule.
Repeat for the other regional bucket.
With Replicating delete markers enabled, when you delete an object on the origin bucket, the delete marker propagates to all regional replicas. The NoncurrentVersionExpiration rule then cleans up the superseded version data after 30 days automatically — no manual cleanup is required.
Use case 5 - Dev/Staging environment management
Context
Development and staging environments often need a realistic copy of production data to run meaningful tests. Without automation, data synchronisation is manual and error-prone. The combination of replication and aggressive lifecycle policies enables:
- Automatic one-way sync from production to staging using replication
- Automatic cleanup of staging data using short lifecycle expiration rules, preventing cost accumulation on non-production environments
Architecture
Replication between two buckets in the same region is supported and incurs no egress cost. This is the typical configuration for dev/staging use cases where geographic separation is not required.
Implementation
Step 1 - Enable versioning on both buckets
Go to the section of your OVHcloud Control Panel and select your project. Click Object Storage in the left-hand menu.
For each bucket, click its name from the My containers tab, then in the General information tab, enable versioning and click Confirm.
Step 2 - Configure replication from production to staging
Only the datasets/ prefix is replicated to limit the volume of data copied to staging.
From the My containers tab, click the name of your production bucket and select the Replication tab. Click Add a replication rule. Set the prefix filter to datasets/, set the destination to staging-data-<region>, leave the storage class as Standard, disable Replicating delete markers, and click Create.
Step 3 - Apply aggressive expiration on the staging bucket
Objects expire after 14 days; non-current versions are cleaned up after 3 days.
From the My containers tab, click the name of your staging bucket and select the Lifecycle tab. Click Create a rule. Leave the prefix empty. Set expiration to 14 days, non-current version expiration to 3 days, and abort incomplete multipart upload cleanup to 1 day.
Click Create rule.
Replicating delete markers is disabled in the replication rule above. This ensures that deletions in the production bucket do not propagate to staging, allowing staging environments to continue working with their local copy of the data even after production objects have been removed.
Use case 6 - Logs and observability
Context
Log data has heterogeneous retention requirements depending on its type:
- Access logs: short retention (30 days), high volume, low value after a few weeks
- Application error logs: medium retention (90 days), useful for incident post-mortems
- Audit and security logs: long retention (1 to 7 years), required for compliance
The combination of prefix-based lifecycle policies with replication to a centralised SIEM or security bucket enables granular, automated retention management without manual intervention.
Architecture
Implementation
Step 1 - Enable versioning on both buckets
Go to the section of your OVHcloud Control Panel and select your project. Click Object Storage in the left-hand menu.
For each bucket, click its name from the My containers tab, then in the General information tab, enable versioning and click Confirm.
Step 2 - Configure selective replication for audit logs only
Only the audit/ prefix is replicated to the security bucket.
From the My containers tab, click the name of your primary logs bucket and select the Replication tab. Click Add a replication rule. Set the prefix filter to audit/, set the destination to logs-security-<region2>, set the destination storage class to Infrequent Access, disable Replicating delete markers, and click Create.
Step 3 - Apply differentiated lifecycle policies on the primary bucket
Apply separate expiration and transition rules per log type using prefix filters.
From the My containers tab, click the name of your primary logs bucket and select the Lifecycle tab. Use Create a rule to create three rules:
- Rule 1 - prefix
access/: expiration at 30 days - Rule 2 - prefix
errors/: transition to Infrequent Access at day 30, expiration at 90 days - Rule 3 - prefix
audit/: transition to Infrequent Access at day 90, Active Archive at day 365 (3-AZ only), Cold Archive at day 730 (3-AZ only), expiration at 2555 days
Step 4 - Apply long-term retention on the security bucket
From the My containers tab, click the name of your security bucket and select the Lifecycle tab. Click Create a rule. Leave the prefix empty.
For 3-AZ regions, add transitions: Infrequent Access at day 90, Active Archive at day 365, and Cold Archive at day 730. For 1-AZ regions, add only the Infrequent Access transition at day 90. Set expiration to 2555 days.
Click Create rule.
By structuring your log pipeline with typed prefixes (access/, errors/, audit/), you can apply precise lifecycle rules to each category independently. Adding a new log type only requires a new prefix and a new lifecycle rule — no pipeline refactoring is needed.
Use case 7 - SaaS multi-tenant backup
Context
SaaS platforms serving multiple tenants often need to provide per-tenant backup and data isolation guarantees. Common requirements include:
- Per-tenant data isolation (each tenant's data stored under a dedicated prefix)
- Per-tenant retention policies reflecting contractual SLAs
- Offsite replication of tenant data for resilience and compliance
This use case demonstrates a prefix-per-tenant model within a shared bucket, combined with tag-based lifecycle rules to enforce per-tenant policies.
Architecture
Objects are stored under tenants/<tenant-id>/ prefixes. Each tenant's objects are tagged at upload time with a tenant-tier tag (e.g. standard or premium), enabling differentiated lifecycle policies.
Implementation
Step 1 - Enable versioning on both buckets
Go to the section of your OVHcloud Control Panel and select your project. Click Object Storage in the left-hand menu.
For each bucket, click its name from the My containers tab, then in the General information tab, enable versioning and click Confirm.
Step 2 - Upload objects with tenant metadata tags
Objects must be tagged at upload time so that tag-based lifecycle rules can identify them correctly.
From the My containers tab, click the name of your tenants bucket. Select the Objects tab and click Add objects. Before confirming the upload, expand the Tags section. Add a tag with key tenant-id and value tenant-abc123, and a second tag with key tenant-tier and value premium. Select your file and click Import.
Step 3 - Configure replication to the backup bucket
From the My containers tab, click the name of your tenants bucket and select the Replication tab. Click Add a replication rule. Set the prefix filter to tenants/, set the destination to saas-backup-<region2>, set the destination storage class to Infrequent Access, disable Replicating delete markers, and click Create.
Step 4 - Apply tag-based lifecycle policies for differentiated retention
As of today, this feature is only available via the AWS CLI. It will soon be available in the Lifecycle tab of the OVHcloud Control Panel.
Tag-based lifecycle rules require that each object is tagged correctly at upload time. Consider enforcing this at the application layer to ensure consistency across all tenant uploads. If a tenant's tier changes, re-tagging existing objects will cause the appropriate lifecycle rule to apply going forward.
Summary
The table below provides a quick reference for the key configuration choices across all 7 use cases:
Object Storage lifecycle rules are evaluated once per day. There may be a delay of up to 24 hours between the moment an object meets the criteria for a transition or expiration and the moment the action is actually performed. During this delay, objects continue to be billed at their current storage class rate.
Go further
- Object Storage - Managing object lifecycle
- Object Storage - Mastering asynchronous replication across your buckets
- Object Storage - Choosing the right storage class for your needs
- Object Storage - Getting started with Object Storage
- Object Storage - Endpoints and geoavailability
Join our community of users.
1: S3 is a trademark of Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc.