Object Storage - Cas d'usage lifecycle et réplication
Objectif
OVHcloud Object Storage propose deux fonctionnalités d'automatisation puissantes qui, combinées, permettent de répondre à un large éventail de cas de gestion de données en production :
- Les lifecycle policies automatisent les transitions entre classes de stockage (Standard → Infrequent Access → Active Archive → Cold Archive) et l'expiration (suppression) des objets selon des règles que vous définissez.
- La réplication asynchrone copie automatiquement les objets d'un bucket source vers un ou plusieurs buckets de destination, au sein d'une même région ou entre différentes régions.
Utilisées séparément, chacune de ces fonctionnalités apporte déjà une valeur significative. Combinées, elles permettent de mettre en place des architectures à la fois économiques, résilientes et conformes.
Ce guide couvre 7 cas d'usage combinant ces deux fonctionnalités :
- Archivage réglementaire et conformité
- Reprise après sinistre
- Data lake et tiering automatisé
- Distribution géographique de contenu
- Gestion des environnements Dev/Staging
- Logs et observabilité
- Sauvegarde SaaS multi-tenant
Prérequis
- Disposer d'un projet Public Cloud OVHcloud actif.
- Disposer de buckets Object Storage créés dans une ou plusieurs régions OVHcloud. Consultez notre guide « Premiers pas avec l'Object Storage » si nécessaire.
- Connaître les classes de stockage OVHcloud. Consultez notre guide « Choisir la classe de stockage adaptée à vos besoins ».
- Connaître les lifecycle policies. Consultez notre guide « Object Storage - Gérer le cycle de vie des objets ».
- Connaître la réplication asynchrone. Consultez notre guide « Object Storage - Maîtriser la réplication asynchrone sur vos buckets ».
- Pour les étapes CLI uniquement : disposer de l'AWS CLI installée et configurée avec vos identifiants et endpoint Object Storage OVHcloud. Consultez notre guide « Premiers pas avec l'Object Storage ».
Référence du mapping des classes de stockage
Tous les exemples CLI de ce guide utilisent les valeurs de StorageClass de l'API S31 requises pour les opérations d'écriture (PUT, transitions lifecycle, destination de réplication) sur l'endpoint .io d'OVHcloud. Le mapping diffère entre les régions 3-AZ et les régions 1-AZ.
Le mapping ci-dessous reflète l'état actuel depuis le 3 janvier 2026. Consultez le guide « Object Storage - Endpoints et disponibilité géographique » pour la référence complète et à jour.
Régions 3-AZ (ex. Paris eu-west-par, Milan eu-south-mil)
Régions 1-AZ (ex. GRA, SBG, DE, UK, BHS, WAW, ...)
Dans les régions 1-AZ, GLACIER_IR, GLACIER et DEEP_ARCHIVE mappent tous vers Infrequent Access — aucun niveau d'archivage plus profond n'est disponible dans les régions 1-AZ. Cold Archive est actuellement disponible uniquement dans les régions 3-AZ, et uniquement à Paris (eu-west-par).
Ce mapping s'applique uniquement à l'endpoint .io. L'ancien endpoint .perf utilise un mapping différent et n'est maintenu qu'à des fins de rétrocompatibilité.
En pratique
Vous pouvez mettre en œuvre chaque cas d'usage depuis l'espace client OVHcloud ou avec l'AWS CLI.
Les exemples CLI utilisent le format d'endpoint OVHcloud :
Remplacez <region> par le slug de votre région (par exemple gra, sbg, de, uk) et remplacez tous les noms de buckets et préfixes par vos propres valeurs.
Cas d'usage 1 - Archivage réglementaire et conformité
Contexte
Les organisations des secteurs réglementés (finance, santé, juridique) doivent conserver certaines données pendant des durées légalement imposées — souvent 5 à 10 ans — tout en maîtrisant les coûts de stockage et en garantissant la disponibilité des données dans une juridiction secondaire si nécessaire. Une exigence typique combine :
- Une transition automatique vers des classes de stockage moins coûteuses à mesure que les données vieillissent
- Une copie conforme dans une région géographiquement distincte
Architecture
La lifecycle policy sur le bucket primaire gère l'optimisation des coûts. La réplication asynchrone vers le bucket secondaire assure la redondance géographique et les exigences de juridiction. Le bucket secondaire peut avoir sa propre lifecycle policy indépendante pour la rétention à long terme.
Mise en œuvre
Étape 1 - Activer le versioning sur les deux buckets
La réplication asynchrone nécessite que le versioning soit activé sur les buckets source et destination.
Accédez à la section de votre espace client OVHcloud et sélectionnez votre projet. Cliquez sur Object Storage dans le menu de gauche, puis cliquez sur le nom de votre bucket source (compliance-primary-<region>) depuis l'onglet Mes conteneurs.
Rendez-vous dans l'onglet Informations générales, activez le versioning et cliquez sur Confirmer.
Répétez cette opération pour le bucket de destination (compliance-archive-<region2>).
Étape 2 - Configurer la réplication sur le bucket primaire
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket source, puis sélectionnez l'onglet Réplication. Cliquez sur Ajouter une règle de réplication. Définissez le bucket de destination sur compliance-archive-<region2>, choisissez Standard comme classe de stockage de destination, activez la Réplication des marqueurs de suppression et cliquez sur Créer.
Étape 3 - Appliquer la lifecycle policy sur le bucket primaire
Cette configuration fait transiter les objets par Infrequent Access, Active Archive et Cold Archive à mesure qu'ils vieillissent. Les niveaux d'archivage ne sont disponibles que dans les régions 3-AZ.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket source et sélectionnez l'onglet Lifecycle. Cliquez sur Créer une règle. Laissez le filtre de préfixe vide.
Pour les régions 3-AZ, ajoutez trois actions de transition : Infrequent Access au jour 30, Active Archive au jour 90 et Cold Archive au jour 365. Pour les régions 1-AZ, ajoutez uniquement la transition Infrequent Access au jour 30.
Cliquez sur Créer la règle.
Étape 4 - Appliquer une lifecycle de rétention à long terme sur le bucket secondaire
Cette configuration retient les objets pendant 7 ans (2555 jours) avant expiration.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket de destination et sélectionnez l'onglet Lifecycle. Cliquez sur Créer une règle. Laissez le filtre de préfixe vide. Ajoutez une action d'expiration définie à 2555 jours.
Cliquez sur Créer la règle.
La réplication copie l'objet au moment de sa création. Si l'objet transite vers une classe de stockage moins coûteuse sur le bucket primaire, le réplica dans le bucket secondaire conserve sa propre classe de stockage de manière indépendante. Vous pouvez ainsi optimiser les coûts différemment de chaque côté.
Cas d'usage 2 - Reprise après sinistre
Contexte
Une stratégie de reprise après sinistre pour l'Object Storage nécessite une copie de toutes les données dans une région distante, avec des objectifs de délai de reprise (RTO) et de point de reprise (RPO) alignés sur votre SLA. Le schéma type est le suivant :
- Bucket primaire : rétention courte, classe Standard, coût réduit
- Bucket DR : copie complète dans une région distante, rétention plus longue en classe Infrequent Access pour réduire le coût en veille
La réplication asynchrone maintient le bucket DR à jour (environ 15 minutes de latence). Les lifecycle policies sur le bucket primaire maîtrisent les coûts en faisant expirer les objets déjà répliqués en sécurité.
Architecture
Mise en œuvre
Étape 1 - Activer le versioning sur les deux buckets
Accédez à la section de votre espace client OVHcloud et sélectionnez votre projet. Cliquez sur Object Storage dans le menu de gauche.
Pour chaque bucket (dr-primary-<region> et dr-backup-<region2>), cliquez sur son nom depuis l'onglet Mes conteneurs, puis dans l'onglet Informations générales, activez le versioning et cliquez sur Confirmer.
Étape 2 - Configurer la réplication vers le bucket DR
Les objets répliqués sont stockés directement en Infrequent Access côté DR pour réduire les coûts en veille.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket primaire et sélectionnez l'onglet Réplication. Cliquez sur Ajouter une règle de réplication. Définissez la destination sur dr-backup-<region2>, choisissez Infrequent Access comme classe de stockage de destination, désactivez la Réplication des marqueurs de suppression pour protéger la copie DR des suppressions accidentelles, et cliquez sur Créer.
Étape 3 - Appliquer une lifecycle de rétention courte sur le bucket primaire
Les objets expirent après 60 jours ; les versions non courantes sont nettoyées après 7 jours.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket primaire et sélectionnez l'onglet Lifecycle. Cliquez sur Créer une règle. Laissez le préfixe vide. Ajoutez une action d'expiration à 60 jours et une expiration des versions non courantes à 7 jours.
Cliquez sur Créer la règle.
Étape 4 - Appliquer une lifecycle de rétention plus longue sur le bucket DR
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket DR et sélectionnez l'onglet Lifecycle. Cliquez sur Créer une règle. Laissez le préfixe vide. Définissez l'expiration à 365 jours et l'expiration des versions non courantes à 30 jours.
Cliquez sur Créer la règle.
La Réplication des marqueurs de suppression est désactivée dans la règle de réplication DR ci-dessus. Cela empêche les suppressions effectuées sur le bucket primaire de se propager vers le bucket DR, protégeant le réplica contre les suppressions accidentelles ou malveillantes. Ajustez ce paramètre si votre cas d'usage nécessite une cohérence totale entre les deux buckets.
Cas d'usage 3 - Data lake et tiering automatisé
Contexte
Les architectures data lake génèrent de grands volumes d'objets interrogés fréquemment lorsqu'ils sont récents (chauds), occasionnellement après quelques semaines (tièdes), et rarement au-delà de quelques mois (froids). Stocker l'ensemble des données dans la même classe de stockage est inutilement coûteux. La combinaison du tiering lifecycle sur un bucket central et de la réplication vers un bucket dédié à l'analytique permet de :
- Réduire automatiquement les coûts à mesure que les données vieillissent sur le bucket data lake principal
- Disposer d'une copie stable en classe Standard pour les outils d'analytique dans une autre région, non affectée par les transitions de tiering
Architecture
Mise en œuvre
Étape 1 - Activer le versioning sur les deux buckets
Accédez à la section de votre espace client OVHcloud et sélectionnez votre projet. Cliquez sur Object Storage dans le menu de gauche.
Pour chaque bucket, cliquez sur son nom depuis l'onglet Mes conteneurs, puis dans l'onglet Informations générales, activez le versioning et cliquez sur Confirmer.
Étape 2 - Configurer la réplication vers le bucket analytique
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket data lake principal et sélectionnez l'onglet Réplication. Cliquez sur Ajouter une règle de réplication. Laissez le filtre de préfixe vide. Définissez la destination sur datalake-analytics-<region2>, choisissez Standard comme classe de stockage de destination, désactivez la Réplication des marqueurs de suppression et cliquez sur Créer.
Étape 3 - Appliquer la lifecycle de tiering par préfixe sur le bucket principal
Cette configuration applique des calendriers de tiering différents aux données brutes et aux données traitées, grâce aux filtres de préfixe.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket principal et sélectionnez l'onglet Lifecycle. Utilisez Créer une règle pour créer deux règles séparément :
- Règle 1 - préfixe
raw/: transitions vers Infrequent Access au jour 30, Active Archive au jour 90, Cold Archive au jour 365 (3-AZ uniquement) - Règle 2 - préfixe
processed/: transitions vers Infrequent Access au jour 60, Active Archive au jour 180 (3-AZ uniquement)
Le réplica analytique conserve tous les objets en classe Standard, quelle que soit la transition appliquée sur la source. Vos outils d'analytique accèdent toujours à des données immédiatement disponibles, sans délai de restauration ni coûts supplémentaires.
Cas d'usage 4 - Distribution géographique de contenu
Contexte
Les organisations qui distribuent des assets statiques (fichiers média, paquets logiciels, mises à jour de firmware, documentation) à des utilisateurs dans plusieurs régions ont intérêt à conserver des copies proches de leurs utilisateurs finaux. La combinaison de la réplication et des lifecycles vous offre :
- La propagation automatique du nouveau contenu vers les buckets régionaux
- L'expiration automatique des versions obsolètes en local, évitant la dérive du stockage dans le temps
Architecture
Mise en œuvre
Étape 1 - Activer le versioning sur tous les buckets
Accédez à la section de votre espace client OVHcloud et sélectionnez votre projet. Cliquez sur Object Storage dans le menu de gauche.
Pour chacun des trois buckets, cliquez sur son nom depuis l'onglet Mes conteneurs, puis dans l'onglet Informations générales, activez le versioning et cliquez sur Confirmer.
Étape 2 - Configurer la réplication multi-destination sur le bucket d'origine
L'Object Storage OVHcloud prend en charge plusieurs règles de réplication sur un même bucket.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket d'origine et sélectionnez l'onglet Réplication. Cliquez sur Ajouter une règle de réplication. Laissez le préfixe vide, définissez la destination sur content-eu-west-<region2>, activez la Réplication des marqueurs de suppression et cliquez sur Créer. Cliquez à nouveau sur Ajouter une règle de réplication pour ajouter une seconde règle avec pour destination content-eu-central-<region3> et les mêmes paramètres.
Étape 3 - Appliquer la lifecycle d'expiration sur les buckets régionaux
Supprimez les versions non courantes après 30 jours pour éviter l'accumulation de contenu obsolète.
Depuis l'onglet Mes conteneurs, cliquez sur le nom d'un bucket régional et sélectionnez l'onglet Lifecycle. Cliquez sur Créer une règle. Laissez le préfixe vide. Définissez l'expiration des versions non courantes à 30 jours et le nettoyage des uploads multipart incomplets à 7 jours.
Cliquez sur Créer la règle.
Répétez l'opération pour l'autre bucket régional.
Lorsque la Réplication des marqueurs de suppression est activée, la suppression d'un objet sur le bucket d'origine propage le marqueur de suppression vers tous les réplicas régionaux. La règle NoncurrentVersionExpiration nettoie ensuite automatiquement les données de version obsolètes après 30 jours — aucun nettoyage manuel n'est nécessaire.
Cas d'usage 5 - Gestion des environnements Dev/Staging
Contexte
Les environnements de développement et de staging ont souvent besoin d'une copie réaliste des données de production pour exécuter des tests significatifs. Sans automatisation, la synchronisation des données est manuelle et sujette aux erreurs. La combinaison de la réplication et de lifecycles agressives permet de :
- Synchroniser automatiquement les données de production vers le staging grâce à la réplication
- Nettoyer automatiquement les données de staging grâce à des règles d'expiration courtes, évitant l'accumulation de coûts sur les environnements non-production
Architecture
La réplication entre deux buckets dans la même région est supportée et n'engendre pas de coût d'egress. Il s'agit de la configuration typique pour les cas d'usage dev/staging où la séparation géographique n'est pas requise.
Mise en œuvre
Étape 1 - Activer le versioning sur les deux buckets
Accédez à la section de votre espace client OVHcloud et sélectionnez votre projet. Cliquez sur Object Storage dans le menu de gauche.
Pour chaque bucket, cliquez sur son nom depuis l'onglet Mes conteneurs, puis dans l'onglet Informations générales, activez le versioning et cliquez sur Confirmer.
Étape 2 - Configurer la réplication de la production vers le staging
Seul le préfixe datasets/ est répliqué afin de limiter le volume de données copiées vers le staging.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket de production et sélectionnez l'onglet Réplication. Cliquez sur Ajouter une règle de réplication. Définissez le filtre de préfixe sur datasets/, la destination sur staging-data-<region>, laissez la classe de stockage Standard, désactivez la Réplication des marqueurs de suppression et cliquez sur Créer.
Étape 3 - Appliquer une expiration agressive sur le bucket staging
Les objets expirent après 14 jours ; les versions non courantes sont nettoyées après 3 jours.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket staging et sélectionnez l'onglet Lifecycle. Cliquez sur Créer une règle. Laissez le préfixe vide. Définissez l'expiration à 14 jours, l'expiration des versions non courantes à 3 jours et le nettoyage des uploads multipart incomplets à 1 jour.
Cliquez sur Créer la règle.
La Réplication des marqueurs de suppression est désactivée dans la règle de réplication ci-dessus. Cela garantit que les suppressions effectuées sur le bucket de production ne se propagent pas vers le staging, permettant aux environnements de staging de continuer à fonctionner avec leur copie locale des données même après la suppression des objets en production.
Cas d'usage 6 - Logs et observabilité
Contexte
Les données de logs ont des exigences de rétention hétérogènes selon leur type :
- Logs d'accès : rétention courte (30 jours), volume élevé, valeur faible après quelques semaines
- Logs d'erreurs applicatifs : rétention moyenne (90 jours), utiles pour les post-mortems d'incidents
- Logs d'audit et de sécurité : rétention longue (1 à 7 ans), requise pour la conformité
La combinaison de lifecycles par préfixe et de la réplication vers un bucket de sécurité ou SIEM centralisé permet une gestion granulaire et automatisée de la rétention sans intervention manuelle.
Architecture
Mise en œuvre
Étape 1 - Activer le versioning sur les deux buckets
Accédez à la section de votre espace client OVHcloud et sélectionnez votre projet. Cliquez sur Object Storage dans le menu de gauche.
Pour chaque bucket, cliquez sur son nom depuis l'onglet Mes conteneurs, puis dans l'onglet Informations générales, activez le versioning et cliquez sur Confirmer.
Étape 2 - Configurer la réplication sélective pour les logs d'audit uniquement
Seul le préfixe audit/ est répliqué vers le bucket de sécurité.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket de logs primaire et sélectionnez l'onglet Réplication. Cliquez sur Ajouter une règle de réplication. Définissez le filtre de préfixe sur audit/, la destination sur logs-security-<region2>, choisissez Infrequent Access comme classe de stockage de destination, désactivez la Réplication des marqueurs de suppression et cliquez sur Créer.
Étape 3 - Appliquer des lifecycles différenciées sur le bucket primaire
Appliquez des règles d'expiration et de transition distinctes par type de log grâce aux filtres de préfixe.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket de logs primaire et sélectionnez l'onglet Lifecycle. Utilisez Créer une règle pour créer trois règles :
- Règle 1 - préfixe
access/: expiration à 30 jours - Règle 2 - préfixe
errors/: transition vers Infrequent Access au jour 30, expiration à 90 jours - Règle 3 - préfixe
audit/: transition vers Infrequent Access au jour 90, Active Archive au jour 365 (3-AZ uniquement), Cold Archive au jour 730 (3-AZ uniquement), expiration à 2555 jours
Étape 4 - Appliquer la rétention à long terme sur le bucket de sécurité
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket de sécurité et sélectionnez l'onglet Lifecycle. Cliquez sur Créer une règle. Laissez le préfixe vide.
Pour les régions 3-AZ, ajoutez les transitions : Infrequent Access au jour 90, Active Archive au jour 365 et Cold Archive au jour 730. Pour les régions 1-AZ, ajoutez uniquement la transition Infrequent Access au jour 90. Définissez l'expiration à 2555 jours.
Cliquez sur Créer la règle.
En structurant votre pipeline de logs avec des préfixes typés (access/, errors/, audit/), vous pouvez appliquer des règles de lifecycle précises à chaque catégorie indépendamment. L'ajout d'un nouveau type de log ne nécessite qu'un nouveau préfixe et une nouvelle règle de lifecycle — aucune refactorisation du pipeline n'est nécessaire.
Cas d'usage 7 - Sauvegarde SaaS multi-tenant
Contexte
Les plateformes SaaS servant plusieurs tenants doivent souvent fournir des garanties de sauvegarde et d'isolation des données par tenant. Les exigences courantes incluent :
- L'isolation des données par tenant (données de chaque tenant stockées sous un préfixe dédié)
- Des politiques de rétention par tenant reflétant les SLA contractuels
- La réplication hors site des données tenant pour la résilience et la conformité
Ce cas d'usage illustre un modèle préfixe par tenant au sein d'un bucket partagé, combiné à des règles de lifecycle basées sur les tags pour appliquer des politiques différenciées par tenant.
Architecture
Les objets sont stockés sous les préfixes tenants/<tenant-id>/. Les objets de chaque tenant sont tagués au moment du téléversement avec un tag tenant-tier (ex. standard ou premium), permettant des lifecycles différenciées.
Mise en œuvre
Étape 1 - Activer le versioning sur les deux buckets
Accédez à la section de votre espace client OVHcloud et sélectionnez votre projet. Cliquez sur Object Storage dans le menu de gauche.
Pour chaque bucket, cliquez sur son nom depuis l'onglet Mes conteneurs, puis dans l'onglet Informations générales, activez le versioning et cliquez sur Confirmer.
Étape 2 - Téléverser les objets avec les tags de métadonnées tenant
Les objets doivent être tagués au moment du téléversement pour que les règles de lifecycle basées sur les tags puissent les identifier correctement.
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket tenants. Sélectionnez l'onglet Objets et cliquez sur Ajouter des objets. Avant de confirmer le téléversement, développez la section Tags. Ajoutez un tag avec la clé tenant-id et la valeur tenant-abc123, et un second tag avec la clé tenant-tier et la valeur premium. Sélectionnez votre fichier et cliquez sur Importer.
Étape 3 - Configurer la réplication vers le bucket de sauvegarde
Depuis l'onglet Mes conteneurs, cliquez sur le nom de votre bucket tenants et sélectionnez l'onglet Réplication. Cliquez sur Ajouter une règle de réplication. Définissez le filtre de préfixe sur tenants/, la destination sur saas-backup-<region2>, choisissez Infrequent Access comme classe de stockage de destination, désactivez la Réplication des marqueurs de suppression et cliquez sur Créer.
Étape 4 - Appliquer des lifecycles basées sur les tags pour une rétention différenciée
À ce jour, cette fonctionnalité est uniquement disponible via l'AWS CLI. Elle sera prochainement intégrée à l'onglet Lifecycle de l'espace client OVHcloud.
Les règles de lifecycle basées sur les tags nécessitent que chaque objet soit tagué correctement au moment du téléversement. Pensez à appliquer cette contrainte au niveau applicatif pour garantir la cohérence entre tous les téléversements des tenants. Si le niveau d'un tenant change, retaguer les objets existants permettra à la règle de lifecycle appropriée de s'appliquer à partir de ce moment.
Récapitulatif
Le tableau ci-dessous fournit une référence rapide des choix de configuration clés pour les 7 cas d'usage :
Les règles de lifecycle de l'Object Storage sont évaluées une fois par jour. Il peut y avoir un délai allant jusqu'à 24 heures entre le moment où un objet remplit les critères d'une transition ou d'une expiration et le moment où l'action est effectivement réalisée. Pendant ce délai, les objets continuent d'être facturés au tarif de leur classe de stockage actuelle.
Aller plus loin
- Object Storage - Gérer le cycle de vie des objets
- Object Storage - Maîtriser la réplication asynchrone sur vos buckets
- Object Storage - Choisir la classe de stockage adaptée à vos besoins
- Object Storage - Premiers pas avec l'Object Storage
- Object Storage - Endpoints et disponibilité géographique
Échangez avec notre communauté d'utilisateurs.
1 : S3 est une marque déposée appartenant à Amazon Technologies, Inc. Les services de OVHcloud ne sont pas sponsorisés, approuvés, ou affiliés de quelque manière que ce soit.