Object Storage Service:Exemples de configuration du cycle de vie

Condition de filtre unique

Chaque règle de cycle de vie contient au moins une condition de filtre. Une condition de filtre détermine les objets d'un bucket auxquels la règle s'applique. Les exemples suivants illustrent comment spécifier des conditions de filtre dans une règle de cycle de vie.

Exemple 1 : Transitionner et supprimer des objets avec un préfixe spécifique après un nombre de jours défini

Dans cette règle de cycle de vie, la condition de filtre spécifie le préfixe doc/. Cette règle s'applique aux objets portant le préfixe doc/, tels que doc/test1.txt et doc/test2.jpg. La règle fait passer les objets vers la classe de stockage Infrequent Access (IA) 180 jours après leur dernière modification et les supprime 365 jours après leur dernière modification.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix>doc/</Prefix>
      <Status>Enabled</Status>    
      <Transition>
        <Days>180</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
      <Expiration>
        <Days>365</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  @id="image_f8h_i86_m2k"

  Paramètres de configuration de la console pour la règle de cycle de vie :

  • Status : Enabled

  • Policy : Match by prefix, prefix: doc/

  • File time policy : Number of days

  • Règle 1 : Les données passent automatiquement en Infrequent Access (IA) 180 jours après la dernière modification

  • Règle 2 : Les données sont supprimées 365 jours après la dernière modification (les données supprimées ne peuvent pas être récupérées)

  • Fragment expiration policy : Disabled

Exemple 2 : Supprimer tous les objets d'un bucket après un nombre de jours défini

Cette règle de cycle de vie s'applique à tous les objets d'un bucket et les expire 300 jours après leur dernière modification.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <Days>300</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  @id="image_cgz_xn0_hvm"

  Éléments de configuration clés de la règle de cycle de vie dans la console :

  • Status : Enabled

  • Policy : Applied to the entire bucket

  • File time policy : Number of days

  • Lifecycle management rule : Les données sont automatiquement supprimées 300 jours après la dernière modification (les données supprimées ne peuvent pas être récupérées)

  • Fragment expiration policy : Disabled

Exemple 3 : Supprimer tous les objets d'un bucket après une date spécifiée

Cette règle de cycle de vie s'applique à tous les objets d'un bucket (le préfixe est vide). La règle expire tous les objets dont la dernière modification est antérieure au 30 décembre 2023.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <CreatedBeforeDate>2023-12-30T00:00:00.000Z</CreatedBeforeDate>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  @id="image_kyi_zrz_8j6"

  Paramètres de configuration spécifiques de la règle de cycle de vie :

  • Status : Sélectionnez Enabled

  • Policy : Sélectionnez Applied to the entire bucket

  • File time policy : Sélectionnez Specific date. Configurez la règle de gestion du cycle de vie pour qu'elle s'applique aux objets dont la dernière modification est antérieure au 30 décembre 2023

  • Traitement des données : Sélectionnez Data deletion (deleted data cannot be recovered)

  • Fragment expiration policy : Sélectionnez Disabled

Conditions de filtre qui se chevauchent

Les exemples suivants décrivent la gestion des conflits entre les actions de cycle de vie lorsque les conditions de filtre se chevauchent.

Exemple 1 : Actions de cycle de vie basées sur des préfixes qui se chevauchent (aucun conflit)

Résultat : Les règles n'entrent pas en conflit. Les actions spécifiées dans la règle 1 et la règle 2 prennent effet.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix>test/</Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>30</Days>
        <StorageClass>Archive</StorageClass>
      </Transition>
    </Rule>
   <Rule>
      <ID>test-rule2</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <Days>365</Days>
      </Expiration>
    </Rule>  
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  • Règle 1@id="image_utj_bh4_olt"

    Configuration de la règle de cycle de vie pour la règle 1 :

    • Status : Enabled

    • Policy : Match by prefix, prefix : test/

    • File time policy : Number of days. Les données passent automatiquement vers la classe de stockage Archive 30 jours après la dernière modification

    • Fragment expiration policy : Disabled

  • Règle 2@id="image_anx_b0q_ow2"

    • Status : Enabled

    • Policy : Applied to the entire bucket

    • File time policy : Number of days. Les données sont automatiquement supprimées 365 jours après la dernière modification (les données supprimées ne peuvent pas être récupérées)

    • Fragment expiration policy : Disabled

Exemple 2 : Actions de cycle de vie basées sur le filtrage par tag (conflit)

Condition : Un objet possède les deux tags, donc les deux règles s'appliquent à cet objet.

Résultat : L'objet expire 10 jours après sa dernière modification. Étant donné que l'objet est supprimé, la transition de classe de stockage ne peut pas avoir lieu. Par conséquent, seule l'action d'expiration de la règle 2 prend effet.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix></Prefix>
      <Tag>
        <Key>tag1</Key>
        <Value>value1</Value>
      </Tag>
      <Status>Enabled</Status>
      <Transition>
        <Days>180</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
    <Rule>
      <ID>test-rule2</ID>
      <Prefix></Prefix>
      <Tag>
        <Key>tag2</Key>
        <Value>value2</Value>
      </Tag>
      <Status>Enabled</Status>
      <Expiration>
        <Days>10</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  • Règle 1@id="image_227_mzc_2f8"

    Configuration de la console pour la règle 1 :

    • Status : Enabled

    • Policy : Applied to the entire bucket

    • Tag : tag1:value1

    • File time policy : Number of days. Les données passent automatiquement en Infrequent Access (IA) 180 jours après la dernière modification

  • Règle 2@id="image_qs5_vmn_vw5"

    Configuration du cycle de vie pour la règle 2 :

    • Status : Enabled

    • Policy : Applied to the entire bucket

    • Tag : tag2:value2

    • File time policy : Number of days

    • Lifecycle management rule : Data deletion est exécutée 10 jours après la dernière modification (les données supprimées ne peuvent pas être récupérées)

Exemple 3 : Actions de cycle de vie basées sur la même période (conflit)

Résultat de l'exécution : Les objets correspondant aux règles sont supprimés après que leur dernière modification remonte à plus de 365 jours.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>rule1</ID>
      <Prefix></Prefix>    
      <Status>Enabled</Status>
      <Transition>
        <Days>365</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
    <Rule>
      <ID>rule2</ID>
      <Prefix></Prefix>    
      <Status>Enabled</Status>
      <Expiration>
        <Days>365</Days>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  • Règle 1@id="image_ldr_4ti_lpz"

    Configuration de la règle 1 :

    • Policy : Sélectionnez Applied to the entire bucket

    • File time policy : Sélectionnez Number of days. Règle : Les données passent automatiquement en Infrequent Access (IA) 365 jours après la dernière modification

    • Fragment expiration policy : Sélectionnez Disabled

  • Règle 2@id="image_dv9_qil_7z2"

    Configuration du cycle de vie pour la règle 2 :

    • Status : Enabled

    • Policy : Applied to the entire bucket

    • File time policy : Number of days

    • Lifecycle management rule : Les données sont automatiquement supprimées 365 jours après la dernière modification (les données supprimées ne peuvent pas être récupérées)

    • Fragment expiration policy : Disabled

Exemple 4 : Actions de cycle de vie basées sur des préfixes qui se chevauchent et spécifient la même action (conflit)

Supposons que vous spécifiiez deux règles de cycle de vie. Voici les détails des règles :

• Règle 1 : Spécifie le passage des objets avec le préfixe logs/ vers la classe de stockage Infrequent Access 180 jours après leur dernière modification.

• Règle 2 : Spécifie le passage de tous les objets du bucket actuel vers la classe de stockage Infrequent Access 30 jours après leur dernière modification.

Résultat : Tous les objets du bucket passent vers la classe de stockage Infrequent Access 30 jours après leur dernière modification.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>rule1</ID>
      <Prefix>logs/</Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>180</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
   <Rule>
      <ID>rule2</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>30</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>  
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  • Règle 1@id="image_z03_ysx_iye"

    Configuration de la console pour la règle 1 :

    • Status : Enabled

    • Policy : Match by prefix, prefix : logs/

    • File time policy : Number of days. Les données passent automatiquement vers la classe de stockage Infrequent Access (IA) 180 jours après la dernière modification

    • Fragment expiration policy : Disabled

  • Règle 2@id="image_ie7_6vp_0t4"

    Configuration de la règle 2 : Status est Enabled. File time policy est Number of days. La règle de gestion du cycle de vie spécifie que les données passent automatiquement vers la classe de stockage Infrequent Access (IA) 30 jours après la dernière modification. Fragment expiration policy est Disabled.

Désactivation d'une règle de cycle de vie

Supposons que vous spécifiiez deux règles de cycle de vie. Voici les détails des règles :

• Règle 1 (Désactivée) : Spécifie le passage des objets avec le préfixe logs/ vers la classe de stockage IA 100 jours après leur création.

• Règle 2 (Activée) : Spécifie le passage des objets avec le préfixe documents/ vers la classe de stockage Archive 50 jours après leur création.

Résultat : Seule la règle activée prend effet.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule1</ID>
      <Prefix>logs/</Prefix>
      <Status>Disabled</Status>
      <Transition>
        <Days>100</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
    </Rule>
    <Rule>
      <ID>test-rule2</ID>
      <Prefix>documents/</Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>50</Days>
        <StorageClass>Archive</StorageClass>
      </Transition>
    </Rule>
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  • Règle 1@id="image_mh8_8rv_j29"

    Configuration de la règle de cycle de vie pour la règle 1 :

    • Policy : Match by prefix, prefix : logs/

    • File time policy : Number of days. Les données passent automatiquement en Infrequent Access (IA) 100 jours après la dernière modification

    • Fragment expiration policy : Disabled

    • Status : Disabled

  • Règle 2@id="image_8o3_g0y_iy7"

    Configuration de la règle 2 : Policy est défini sur Match by prefix, prefix : documents/. File time policy est défini sur Number of days, avec un passage automatique des données vers la classe de stockage Archive 50 jours après la dernière modification. Fragment expiration policy est défini sur Disabled.

Règles de cycle de vie avec versioning

Lorsque le versioning est activé, chaque objet du bucket possède une version actuelle et zéro ou plusieurs versions non actuelles. Pour plus d'informations sur le versioning, consultez Versioning.

Exemple 1 : Transitionner et supprimer les versions d'objets non actuelles après un nombre de jours défini

Dans cet exemple, une règle de cycle de vie est configurée pour un bucket avec versioning activé. La règle fait passer les versions actuelles des objets vers la classe de stockage IA 10 jours après leur dernière modification. La règle fait également passer les versions non actuelles des objets vers la classe de stockage Archive 60 jours après qu'elles deviennent non actuelles, puis les supprime 90 jours après qu'elles deviennent non actuelles.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Transition>
        <Days>10</Days>
        <StorageClass>IA</StorageClass>
      </Transition>
      <NoncurrentVersionTransition>
        <NoncurrentDays>60</NoncurrentDays>
        <StorageClass>Archive</StorageClass>
      </NoncurrentVersionTransition>
      <NoncurrentVersionExpiration>
        <NoncurrentDays>90</NoncurrentDays>
      </NoncurrentVersionExpiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  @id="image_oc4_yfo_fh6"

  Détails de la configuration :

  • Status : Sélectionnez Enabled. Policy : Sélectionnez Match by prefix

  • Current version file execution policy : File time policy : Sélectionnez Number of days. Configurez le passage automatique des données en Infrequent Access (IA) 10 jours après la dernière modification

  • Noncurrent version file execution policy : File time policy : Sélectionnez Number of days. Configurez le passage vers la classe de stockage Archive 60 jours après le devenir non actuel, et la delete des données 90 jours après le devenir non actuel (les données supprimées ne peuvent pas être récupérées)

  • Fragment execution policy : Sélectionnez Disabled

Exemple 2 : Supprimer les marqueurs de suppression expirés

Si la seule version d'un objet est un marqueur de suppression, on parle de marqueur de suppression expiré. L'exemple suivant montre une règle de cycle de vie qui supprime les marqueurs de suppression expirés.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>test-rule0</ID>
      <Prefix></Prefix>
      <Status>Enabled</Status>
      <Expiration>
        <ExpiredObjectDeleteMarker>true</ExpiredObjectDeleteMarker>
      </Expiration>
    </Rule>
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  @id="image_p65_1o0_nyr"

  Configuration de la règle de cycle de vie :

  • Status : Sélectionnez Enabled

  • Policy : Sélectionnez Applied to the entire bucket

  • Current version file execution policy : File time policy : Sélectionnez Remove expired delete markers

  • Noncurrent version file execution policy : File time policy : Sélectionnez Disabled

  • Fragment execution policy : Fragment expiration policy : Sélectionnez Disabled

Nettoyage des fragments expirés

Cet exemple montre une règle de cycle de vie qui expire les fragments avec le préfixe logs/ après 5 jours. Les fragments sont des parties issues d'un téléchargement multipart pour lequel l'opération CompleteMultipartUpload n'a pas été exécutée.

Les exemples ci-dessous présentent les configurations XML et console pour cette règle de cycle de vie :

• XML

  <LifecycleConfiguration>
    <Rule>
      <ID>lifecyclerule1</ID>
      <Prefix>logs/</Prefix>
      <Status>Enabled</Status>
      <AbortMultipartUpload>
        <Days>5</Days>
      </AbortMultipartUpload>
    </Rule>
  </LifecycleConfiguration>

• Console

  Remarque

  Vous pouvez également utiliser la console pour configurer une règle de cycle de vie avec ces conditions. Pour plus d'informations, consultez Définir des règles de cycle de vie.

  @id="image_b91_v3x_kia"

  Configuration de la règle de cycle de vie dans la console :

  • Status : Enabled

  • Policy : Match by prefix, prefix : logs/

  • File time policy : Disabled

  • Fragment expiration policy : Number of days. Les fragments générés il y a plus de 5 jours sont automatiquement supprimés par le système (les données supprimées ne peuvent pas être récupérées)

Références

• Coûts du cycle de vie