Tous les produits
Search
Centre de documentation

Object Storage Service:Règles de cycle de vie basées sur la dernière heure d'accès

Dernière mise à jour :Aug 18, 2026

Les règles de cycle de vie basées sur la dernière heure d'accès vous permettent de surveiller automatiquement les modèles d'accès aux données et d'identifier les données froides. Vous pouvez ensuite transférer ces données vers une autre classe de stockage. Cette approche met en œuvre un stockage hiérarchisé pour les données chaudes et froides, réduisant ainsi vos coûts de stockage.

Scénarios

  • Multimédia

    Un site web stocke ses vidéos et images dans OSS. Avec le temps, les données historiques passent progressivement du statut de données chaudes à celui de données froides. Vous souhaiterez peut-être transférer les données inutilisées depuis longtemps vers la classe de stockage Infrequent Access. Toutefois, certaines données plus anciennes restent populaires et doivent être conservées dans la classe de stockage Standard. Dans ce scénario, utilisez une règle de cycle de vie basée sur la dernière heure d'accès pour identifier automatiquement les données chaudes et froides et mettre en place un stockage hiérarchisé, réduisant ainsi les coûts de stockage.

  • Albums photo ou lecteurs cloud

    Définissez une période de transition personnalisée pour déplacer automatiquement les données froides inutilisées depuis une période prolongée vers la classe de stockage Infrequent Access, tout en garantissant un accès en temps réel.

  • Sciences de la vie

    La vaste quantité de données métier générées par le séquençage génétique est souvent classée comme chaude ou froide en fonction de sa dernière heure d'accès plutôt que de sa dernière heure de modification. Auparavant, les clients ne pouvaient gérer la hiérarchisation des données que manuellement, en analysant les journaux ou en utilisant d'autres méthodes. Une règle de cycle de vie basée sur la dernière heure d'accès permet au serveur d'identifier automatiquement les données chaudes et froides et de mettre en œuvre un stockage hiérarchisé. Vous pouvez également combiner des politiques basées à la fois sur la dernière heure d'accès et sur la dernière heure de modification au sein d'une même règle de cycle de vie pour une gestion des données plus flexible.

Limites

Aucune suppression de données

Les règles de cycle de vie basées sur la dernière heure d'accès ne permettent pas de supprimer des données.

Conditions de correspondance

Les règles de cycle de vie prennent en charge la correspondance uniquement basée sur les préfixes et les tags. La correspondance par caractères génériques, par suffixe et par expression régulière n'est pas prise en charge.

Limites d'expiration des parties

Vous ne pouvez pas configurer deux règles de cycle de vie ou plus contenant une politique de cycle de vie pour les parties, pour des objets dont les noms ont des préfixes qui se chevauchent. Exemples :

  • Exemple 1

    Si vous configurez une règle de cycle de vie contenant une politique de parties pour un bucket, vous ne pouvez pas configurer une autre règle de cycle de vie contenant une politique de parties pour tous les objets du bucket.

  • Exemple 2

    Si vous configurez une règle de cycle de vie contenant une politique de parties pour les objets dont les noms contiennent le préfixe dir1 dans un bucket, vous ne pouvez pas configurer une autre règle de cycle de vie contenant une politique de parties pour les objets dont les noms contiennent des préfixes qui se chevauchent, tels que dir1/dir2.

Notes d'utilisation

Limite de règles

Un bucket peut contenir jusqu'à 1 000 règles de cycle de vie. Une règle de cycle de vie peut contenir à la fois des politiques basées sur la dernière heure de modification et des politiques basées sur la dernière heure d'accès.

Sémantique d'écrasement

L'opération PutBucketLifecycle écrase les configurations existantes d'une règle de cycle de vie d'un bucket. Par exemple, si une règle de cycle de vie nommée Rule1 est configurée pour un bucket et que vous souhaitez configurer une autre règle de cycle de vie nommée Rule2 pour le bucket, effectuez les opérations suivantes :

  • Appelez l'opération GetBucketLifecycle pour interroger Rule1.

  • Ajoutez Rule1 et Rule2 à la configuration de la règle de cycle de vie.

  • Appelez l'opération PutBucketLifecycle pour créer Rule1 et Rule2 pour le bucket.

Heure d'effet

Après la création d'une règle de cycle de vie, OSS charge la règle dans un délai de 24 heures. Une fois la règle chargée, OSS commence à l'exécuter tous les jours à 08:00 (UTC+8).

Heure d'achèvement de l'exécution

  • Une fois qu'une règle prend effet, les opérations de cycle de vie telles que la suppression d'objets, la transition de classe de stockage et l'expiration des parties de téléchargement multipartie sont généralement achevées dans un délai de 24 heures pour un maximum de 1 milliard d'objets dans les régions Chine (Hangzhou), Chine (Shanghai), Chine (Pékin), Chine (Zhangjiakou), Chine (Ulanqab), Chine (Shenzhen) et Singapour. Dans les autres régions, ces opérations sont généralement achevées dans un délai de 24 heures pour un maximum de 100 millions d'objets.

  • L'exécution peut prendre plus de 24 heures, et dans certains cas plusieurs jours ou semaines, s'il y a beaucoup d'objets à analyser, beaucoup d'objets auxquels la règle de cycle de vie s'applique, beaucoup de tags, beaucoup de versions pour un seul objet, ou un volume élevé de nouveaux objets écrits pendant l'exécution de la tâche de cycle de vie.

    Remarque

    Si le versioning est activé pour le bucket, une opération sur chaque version d'un objet est comptée comme une opération distincte.

Facturation

  • Frais de surveillance et de gestion des objets

    Après avoir activé le suivi d'accès, des frais de surveillance et de gestion des objets sont facturés. Toutefois, OSS ne facture actuellement pas ces frais.

  • Frais liés au non-respect de la durée minimale de stockage pour Infrequent Access

    Les objets de la classe de stockage Infrequent Access ont une durée minimale de stockage de 30 jours. Si un objet est stocké pendant moins de 30 jours, vous êtes facturé pour la partie restante de la durée minimale. Les exemples suivants décrivent le fonctionnement de cet élément de facturation avec les règles de cycle de vie :

    Exemple 1 : Une règle de cycle de vie transfère un objet Standard vers la classe de stockage Infrequent Access 10 jours après sa création. Cinq jours plus tard, il est retransféré vers la classe de stockage Standard. Dans ce cas, vous êtes facturé pour 15 jours de stockage afin de respecter l'exigence de durée minimale de stockage pour Infrequent Access.

    Exemple 2 : Une règle de cycle de vie transfère un objet Standard vers la classe de stockage Infrequent Access 10 jours après sa création. L'objet est supprimé 15 jours plus tard. Dans ce cas, vous êtes facturé pour 5 jours de stockage afin de respecter l'exigence de durée minimale de stockage pour Infrequent Access.

    Pour plus d'informations, consultez Frais de stockage.

  • Frais de récupération de données pour Infrequent Access

    Les frais d'accès aux fichiers de la classe de stockage Infrequent Access sont calculés en fonction de la quantité de données récupérées. Pour plus d'informations, consultez Frais de traitement des données.

  • Frais de requête

    Une règle de cycle de vie engendre des frais de requête lorsqu'elle modifie la classe de stockage d'un objet. Pour plus d'informations, consultez Frais de requête.

Autres considérations

  • Politique de mise à jour de la dernière heure d'accès :

    Après l'activation du suivi d'accès, OSS met à jour la valeur LastAccessTime d'un objet selon les règles suivantes :

    1. Initialisation : Lorsque le suivi d'accès est activé, OSS définit la LastAccessTime de tous les objets du bucket à l'heure à laquelle le suivi d'accès a été activé.

    2. Règles de mise à jour : Après l'initialisation, des opérations telles que le téléchargement ou l'écrasement d'un objet mettent à jour la valeur LastAccessTime de l'objet. Pour plus d'informations sur les opérations qui mettent à jour la valeur LastAccessTime d'un objet, consultez Impact des opérations courantes sur la dernière heure d'accès des objets.

    3. Mécanisme de mise à jour :

      • La valeur LastAccessTime est mise à jour de manière asynchrone. La mise à jour est généralement terminée dans un délai de 24 heures.

      • Si le même objet est accédé plusieurs fois dans un délai de 24 heures, OSS enregistre l'heure du premier accès comme LastAccessTime de l'objet. Les accès ultérieurs dans la période de 24 heures ne déclenchent pas de mise à jour.

  • Classes de stockage des objets pour la transition :

    • Les règles de cycle de vie basées sur la dernière heure d'accès permettent de transférer des objets de la classe de stockage Standard vers la classe de stockage Infrequent Access. Vous pouvez également choisir de retransférer automatiquement un objet vers la classe de stockage Standard lors de son accès.

    • Les règles de cycle de vie basées sur la dernière heure d'accès permettent de transférer des objets de la classe de stockage Standard ou Infrequent Access vers la classe de stockage Archive, Cold Archive ou Deep Cold Archive. Vous pouvez également transférer des objets de la classe de stockage Archive vers la classe de stockage Cold Archive ou Deep Cold Archive. Si vous souhaitez transférer des objets de la classe de stockage Standard ou Infrequent Access vers la classe de stockage Archive, Cold Archive ou Deep Cold Archive, soumettez un ticket pour demander des autorisations. Une fois votre demande approuvée, vous devez spécifier la classe de stockage de destination pour la transition.

      Important

      Après l'approbation de votre ticket, si vous utilisez une politique basée sur la dernière heure d'accès pour transférer un objet de la classe de stockage Standard ou Infrequent Access vers la classe de stockage Archive, Cold Archive ou Deep Cold Archive, la dernière heure d'accès de l'objet dans la classe de stockage de destination correspond par défaut à l'heure à laquelle le suivi d'accès a été activé pour le bucket.

  • Configuration des règles de cycle de vie dans un bucket pour lequel OSS-HDFS est activé :

    Pour configurer ou modifier une règle de cycle de vie basée sur la dernière heure d'accès afin de correspondre à tous les objets d'un bucket pour lequel OSS-HDFS est activé, utilisez l'élément NOT pour exclure les objets stockés dans le répertoire .dlsdata/. Cela empêche les actions de suppression d'objets ou de conversion de classe de stockage déclenchées par la règle de cycle de vie de s'appliquer aux données OSS-HDFS et, par conséquent, d'affecter les opérations de lecture et d'écriture sur les données OSS-HDFS.

Procédure

Console OSS

  1. Connectez-vous à la console OSS.

  2. Dans le volet de navigation de gauche, cliquez sur Buckets. Sur la page qui s'affiche, cliquez sur le nom du bucket cible.

  3. Dans le volet de navigation de gauche, choisissez Data Management > Lifecycle.

  4. Sur la page Lifecycle, activez l'interrupteur Enable Access Tracking, puis cliquez sur Create Rule.

  5. Dans le panneau Create Lifecycle Rule, configurez la règle de cycle de vie selon les descriptions suivantes.

    • Le versioning du bucket est désactivé

      Section

      Paramètre

      Description

      Basic Settings

      Status

      Définissez le statut de la règle de cycle de vie. Vous pouvez sélectionner Enabled ou Disabled.

      • Si vous activez la règle de cycle de vie, OSS modifie les classes de stockage des données en fonction de la règle.

      • Si vous désactivez la règle de cycle de vie, la tâche de cycle de vie est suspendue.

      Applied To

      Sélectionnez les objets auxquels la règle de cycle de vie s'applique. Vous pouvez sélectionner Objects with Specified Prefix ou Whole Bucket.

      Allow Overlapped Prefixes

      Par défaut, OSS vérifie si les préfixes des règles de cycle de vie se chevauchent. Par exemple, vous définissez les deux règles de cycle de vie suivantes avec des préfixes qui se chevauchent :

      • Règle 1

        Transfère tous les objets avec le préfixe dir1/ du bucket vers la classe de stockage Infrequent Access 180 jours après leur dernière heure d'accès.

      • Règle 2

        Transfère tous les objets avec le préfixe dir1/dir2/ du bucket vers la classe de stockage Archive 30 jours après leur dernière heure d'accès.

      Si cette option n'est pas sélectionnée, OSS rejette cette configuration car les objets du répertoire dir1/dir2/ correspondraient aux deux règles de transition.

      Si cette option est sélectionnée, les objets du répertoire dir1/dir2/ sont transférés vers la classe de stockage Archive après 30 jours. Les autres objets du répertoire dir1/ sont transférés vers la classe de stockage Infrequent Access après 180 jours.

      Prefix

      Saisissez le préfixe d'objet que la règle doit faire correspondre.

      • Si vous définissez le préfixe sur img, la règle correspond à tous les objets dont les noms commencent par img, tels que imgtest.png et img/example.jpg.

      • Si vous définissez le préfixe sur img/, la règle correspond à tous les objets dont les noms commencent par img/, tels que img/example.jpg et img/test.jpg.

      Tag

      La règle de cycle de vie s'applique uniquement aux objets portant le tag spécifié. Par exemple, si vous sélectionnez Objects with Specified Prefix, définissez le préfixe sur img et définissez la clé de tag sur a et la valeur sur 1, la règle correspond à tous les objets dont les noms commencent par img et qui ont le tag a=1. Pour plus d'informations sur les tags d'objets, consultez Tagging d'objets.

      NOT

      Utilisez l'option NOT pour exclure les objets ayant un préfixe et un tag spécifiés de la règle de cycle de vie.

      Important
      • Si l'option NOT est activée, vous devez spécifier au moins un préfixe ou un tag.

      • La clé définie pour le tag dans la condition NOT ne peut pas être la même que la clé définie dans le paramètre Tag.

      • Si l'option NOT est activée, vous ne pouvez pas configurer de politique d'expiration des parties.

      Object Size

      Spécifiez la taille d'objet à laquelle la règle de cycle de vie s'applique.

      • Minimum Size : La règle de cycle de vie s'applique aux objets plus grands que cette valeur. La valeur doit être supérieure à 0 o et inférieure à 5 To.

      • Maximum Size : La règle de cycle de vie s'applique aux objets plus petits que cette valeur. La valeur doit être supérieure à 0 o et inférieure ou égale à 5 To.

      Important

      Si vous configurez à la fois la Taille minimale et la Taille maximale dans la même règle de cycle de vie, tenez compte des éléments suivants :

      • Assurez-vous que la valeur de la Taille maximale est supérieure à la valeur de la Taille minimale.

      • Vous ne pouvez pas configurer de politique d'expiration des parties.

      • Vous ne pouvez pas configurer de politique pour effacer les marqueurs de suppression.

      Policy for Objects

      Object Lifecycle

      Sélectionnez une politique d'expiration pour les objets. Vous pouvez sélectionner Validity Period (Days), Expiration Date ou Disabled. Si vous sélectionnez Disabled, la politique d'expiration des objets ne prend pas effet.

      Lifecycle-based Rules

      Configurez la règle pour modifier la classe de stockage des objets. Les données peuvent être transférées vers les classes de stockage suivantes :

      • IA (Data Remains in IA After Access)

      • IA (Data Is Converted to Standard After Access)

      • Archive

      • Cold Archive

      • Deep Cold Archive

      Par exemple, si vous sélectionnez la politique Access Time, définissez la Validity Period (Days) sur 30 et spécifiez que les données sont automatiquement transférées vers IA (Data Remains in IA After Access) après la période spécifiée, un objet auquel on a accédé pour la dernière fois le 1er septembre 2021 est transféré vers cette classe de stockage le 1er octobre 2021.

      Policy for Parts

      Part Lifecycle

      Définissez l'action à effectuer sur les parties expirées. Si vous avez spécifié un Tag, vous ne pouvez pas configurer ce paramètre. Vous pouvez sélectionner Validity Period (Days) ou Expiration Date pour la politique d'expiration des parties, ou sélectionner Disabled. Si vous sélectionnez Disabled, la politique d'expiration des parties ne prend pas effet.

      Important

      Une règle de cycle de vie doit inclure au moins une politique d'expiration des objets ou une politique d'expiration des parties.

      Rules for Parts

      Spécifiez quand les parties expirent en fonction de la période de validité ou de la date d'expiration sélectionnée dans la politique d'expiration des parties. Les parties expirées sont automatiquement supprimées et ne peuvent pas être récupérées.

    • Le versioning du bucket est activé

      Après avoir activé le versioning, les éléments de configuration des sections Basic Settings et Policy for Parts sont configurés de la même manière que lorsque le versioning est désactivé. Le tableau suivant décrit uniquement les différences de configuration lorsque le versioning est activé.

      Section

      Paramètre

      Description

      Policy for Current Versions

      Clear delete markers

      Après l'activation du versioning, l'option Clear Delete Markers est ajoutée à la politique de nettoyage. Les autres options sont identiques à celles lorsque le versioning est désactivé.

      Si vous sélectionnez cette option et que la version actuelle d'un objet est la seule version et qu'il s'agit d'un marqueur de suppression, OSS supprime le marqueur de suppression de l'objet expiré. Si l'objet possède plusieurs versions et que la dernière version est un marqueur de suppression, OSS conserve le marqueur de suppression. Pour plus d'informations sur les marqueurs de suppression, consultez Marqueurs de suppression.

      Policy for Previous Versions

      Object Lifecycle

      Définissez la politique d'expiration pour les versions non actuelles des objets. Vous pouvez sélectionner Validity Period (Days) ou Disabled. Si vous sélectionnez Disabled, la politique d'expiration des objets ne prend pas effet.

      Lifecycle-based Rules

      Définissez une période de N jours. Après qu'une version non actuelle d'un objet a été consultée, elle est transférée vers une classe de stockage différente après N jours. Par exemple, si vous définissez la période sur 30 jours, une version non actuelle consultée le 1er septembre 2021 est transférée vers la classe de stockage spécifiée le 1er octobre 2021.

  6. Cliquez sur OK.

    Après avoir enregistré la règle, elle apparaît dans la liste des politiques.

SDK

Les SDK OSS pour Java, Go, Python et PHP prennent en charge la création de règles de cycle de vie basées sur la dernière heure d'accès. Avant de créer une règle de cycle de vie basée sur la dernière heure d'accès, vous devez activer le suivi d'accès pour le bucket spécifié. Pour obtenir des exemples de code, consultez Vue d'ensemble des SDK.

Java

import com.aliyun.oss.*;
import com.aliyun.oss.common.auth.*;
import com.aliyun.oss.common.comm.SignVersion;
import com.aliyun.oss.model.*;
import java.util.ArrayList;
import java.util.List;

public class Demo {

    public static void main(String[] args) throws Exception {
        // In this example, the endpoint of the China (Hangzhou) region is used. Specify your actual endpoint. 
        String endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
        // Obtain access credentials from environment variables. Before you run the sample code, make sure that the OSS_ACCESS_KEY_ID and OSS_ACCESS_KEY_SECRET environment variables are configured. 
        EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
        // Specify the name of the bucket. Example: examplebucket. 
        String bucketName = "examplebucket";
        // Specify the region in which the bucket is located. For example, if the bucket is located in the China (Hangzhou) region, set the region to cn-hangzhou.
        String region = "cn-hangzhou";

        // Create an OSSClient instance. 
        // Call the shutdown method to release resources when the OSSClient is no longer in use.
        ClientBuilderConfiguration clientBuilderConfiguration = new ClientBuilderConfiguration();
        clientBuilderConfiguration.setSignatureVersion(SignVersion.V4);        
        OSS ossClient = OSSClientBuilder.create()
        .endpoint(endpoint)
        .credentialsProvider(credentialsProvider)
        .clientConfiguration(clientBuilderConfiguration)
        .region(region)               
        .build();

        try {
            ossClient.putBucketAccessMonitor(bucketName, AccessMonitor.AccessMonitorStatus.Enabled.toString());
            // Create a lifecycle rule and set the ID to rule1. Specify that the storage classes of objects whose names contain the logs prefix and whose size is less than or equal to 64 KB are changed to IA 30 days after the objects are last accessed. In addition, specify that the objects whose name contain the logs prefix are still stored as IA objects when the objects are accessed again. 
            LifecycleRule lifecycleRule = new LifecycleRule("rule1", "logs", LifecycleRule.RuleStatus.Enabled);
            List<LifecycleRule> lifecycleRuleList = new ArrayList<LifecycleRule>();
            SetBucketLifecycleRequest setBucketLifecycleRequest = new SetBucketLifecycleRequest(bucketName);

            LifecycleRule.StorageTransition storageTransition = new LifecycleRule.StorageTransition();
            storageTransition.setStorageClass(StorageClass.IA);
            storageTransition.setExpirationDays(30);
            storageTransition.setIsAccessTime(true);
            storageTransition.setReturnToStdWhenVisit(false);
            storageTransition.setAllowSmallFile(true);
            List<LifecycleRule.StorageTransition> storageTransitionList = new ArrayList<LifecycleRule.StorageTransition>();
            storageTransitionList.add(storageTransition);
            lifecycleRule.setStorageTransition(storageTransitionList);
            lifecycleRuleList.add(lifecycleRule);
            
            // Create a lifecycle rule and set the ID to rule2. Specify that the previous versions of the objects whose names contain the dir prefix and whose size is greater than 64 KB are changed to IA 10 days after the objects are last accessed. In addition, specify that the storage classes of the objects whose names contain the dir prefix are changed to Standard when the objects are accessed again. 
            LifecycleRule lifecycleRule2 = new LifecycleRule("rule2", "dir", LifecycleRule.RuleStatus.Enabled);
            LifecycleRule.NoncurrentVersionStorageTransition noncurrentVersionStorageTransition = new LifecycleRule.NoncurrentVersionStorageTransition();
            noncurrentVersionStorageTransition.setStorageClass(StorageClass.IA);
            noncurrentVersionStorageTransition.setNoncurrentDays(10);
            noncurrentVersionStorageTransition.setIsAccessTime(true);
            noncurrentVersionStorageTransition.setReturnToStdWhenVisit(true);
            noncurrentVersionStorageTransition.setAllowSmallFile(false);

            List<LifecycleRule.NoncurrentVersionStorageTransition> noncurrentVersionStorageTransitionList = new ArrayList<LifecycleRule.NoncurrentVersionStorageTransition>();
            noncurrentVersionStorageTransitionList.add(noncurrentVersionStorageTransition);
            lifecycleRule2.setNoncurrentVersionStorageTransitions(noncurrentVersionStorageTransitionList);
            lifecycleRuleList.add(lifecycleRule2);

            setBucketLifecycleRequest.setLifecycleRules(lifecycleRuleList);

            // Configure the lifecycle rules. 
            ossClient.setBucketLifecycle(setBucketLifecycleRequest);
        } catch (OSSException oe) {
            System.out.println("Caught an OSSException, which means your request made it to OSS, "
                    + "but was rejected with an error response for some reason.");
            System.out.println("Error Message:" + oe.getErrorMessage());
            System.out.println("Error Code:" + oe.getErrorCode());
            System.out.println("Request ID:" + oe.getRequestId());
            System.out.println("Host ID:" + oe.getHostId());
        } catch (ClientException ce) {
            System.out.println("Caught an ClientException, which means the client encountered "
                    + "a serious internal problem while trying to communicate with OSS, "
                    + "such as not being able to access the network.");
            System.out.println("Error Message:" + ce.getMessage());
        } finally {
            if (ossClient != null) {
                ossClient.shutdown();
            }
        }
    }
}

Python

import argparse
import datetime
import alibabacloud_oss_v2 as oss

parser = argparse.ArgumentParser(description="put bucket lifecycle sample")
parser.add_argument('--region', help='The region in which the bucket is located.', required=True)
parser.add_argument('--bucket', help='The name of the bucket.', required=True)
parser.add_argument('--endpoint', help='The domain names that other services can use to access OSS')

def main():
  args = parser.parse_args()
  credentials_provider = oss.credentials.EnvironmentVariableCredentialsProvider()
  cfg = oss.config.load_default()
  cfg.credentials_provider = credentials_provider
  cfg.region = args.region
  if args.endpoint is not None:
    cfg.endpoint = args.endpoint
  client = oss.Client(cfg)

  result = client.put_bucket_lifecycle(oss.PutBucketLifecycleRequest(
    bucket=args.bucket,
    lifecycle_configuration=oss.LifecycleConfiguration(
      rules=[
        oss.LifecycleRule(
          id='rule1',
          status='Enabled',
          prefix='data/',
          transitions=[oss.LifecycleRuleTransition(
            days=200,
            storage_class=oss.StorageClassType.IA,
            is_access_time=True,
            return_to_std_when_visit=False
          )]
        ),
        oss.LifecycleRule(
          id='rule2',
          status='Enabled',
          prefix='log/',
          transitions=[
            oss.LifecycleRuleTransition(
              days=120,
              storage_class=oss.StorageClassType.IA,
              is_access_time=True,
              return_to_std_when_visit=False
            ),
            oss.LifecycleRuleTransition(
              days=250,
              storage_class=oss.StorageClassType.ARCHIVE
              # If is_access_time is not set, the rule is based on the last modified time by default.
            )
          ]
        )
      ]
    )
  ))

  print(f'status code: {result.status_code}, '
        f'request id: {result.request_id}')

if __name__ == "__main__":
  main()

Go

package main

import (
	"context"
	"flag"
	"log"

	"github.com/aliyun/alibabacloud-oss-go-sdk-v2/oss"
	"github.com/aliyun/alibabacloud-oss-go-sdk-v2/oss/credentials"
)

// Define global variables.
var (
	region     string // The region where the bucket is located.
	bucketName string // The name of the bucket.
)

// The init function initializes command-line arguments.
func init() {
	flag.StringVar(&region, "region", "", "The region in which the bucket is located.")
	flag.StringVar(&bucketName, "bucket", "", "The name of the bucket.")
}

func main() {
	// Parse command-line arguments.
	flag.Parse()

	// Check if the bucket name is provided.
	if len(bucketName) == 0 {
		flag.PrintDefaults()
		log.Fatalf("invalid parameters, bucket name required")
	}

	// Check if the region is provided.
	if len(region) == 0 {
		flag.PrintDefaults()
		log.Fatalf("invalid parameters, region required")
	}

	// Load the default configuration, and set the credentials provider and region.
	cfg := oss.LoadDefaultConfig().
		WithCredentialsProvider(credentials.NewEnvironmentVariableCredentialsProvider()).
		WithRegion(region)

	// Create an OSS client.
	client := oss.NewClient(cfg)

	// Create a request to set lifecycle rules for the bucket.
	request := &oss.PutBucketLifecycleRequest{
		Bucket: oss.Ptr(bucketName), // The name of the bucket.
		LifecycleConfiguration: &oss.LifecycleConfiguration{
			Rules: []oss.LifecycleRule{
				{
					// In lifecycle rule "rule1", transition all objects with the prefix "data/"
					// to the Infrequent Access (IA) storage class 200 days after they are last accessed.
					// When these objects are accessed again, they remain in the IA storage class.
					ID:     oss.Ptr("rule1"),
					Status: oss.Ptr("Enabled"),
					Prefix: oss.Ptr("data/"),
					Transitions: []oss.LifecycleRuleTransition{
						{
							Days:                 oss.Ptr(int32(200)),
							StorageClass:         oss.StorageClassIA,
							IsAccessTime:         oss.Ptr(true), // Set to true for a rule based on last access time.
							ReturnToStdWhenVisit: oss.Ptr(false),
						},
					},
				},
				{
					// In lifecycle rule "rule2", transition all objects with the prefix "log/"
					// to the Infrequent Access (IA) storage class 120 days after they are last accessed.
					// When these objects are accessed again, they remain in the IA storage class.
					// A single rule cannot contain more than one IsAccessTime=true Transition.
					// The 250-day Archive transition is configured in a separate rule (rule3) below.
					ID:     oss.Ptr("rule2"),
					Status: oss.Ptr("Enabled"),
					Prefix: oss.Ptr("log/"),
					Transitions: []oss.LifecycleRuleTransition{
						{
							Days:                 oss.Ptr(int32(120)),
							StorageClass:         oss.StorageClassIA,
							IsAccessTime:         oss.Ptr(true), // Set to true for a rule based on last access time.
							ReturnToStdWhenVisit: oss.Ptr(false),
						},
					},
				},
				{
					// In lifecycle rule "rule3", transition all objects with the prefix "log/"
					// to the Archive storage class 250 days after they are last accessed.
					// When these objects are accessed again, they remain in the Archive storage class.
					// This rule is separate from rule2 because a single rule cannot contain
					// more than one IsAccessTime=true Transition.
					ID:     oss.Ptr("rule3"),
					Status: oss.Ptr("Enabled"),
					Prefix: oss.Ptr("log/"),
					Transitions: []oss.LifecycleRuleTransition{
						{
							Days:                 oss.Ptr(int32(250)),
							StorageClass:         oss.StorageClassArchive,
							IsAccessTime:         oss.Ptr(true), // Set to true for a rule based on last access time.
							ReturnToStdWhenVisit: oss.Ptr(false),
						},
					},
				},
			},
		},
	}

	// Set the lifecycle rules for the bucket.
	result, err := client.PutBucketLifecycle(context.TODO(), request)
	if err != nil {
		log.Fatalf("failed to put bucket lifecycle %v", err)
	}

	// Print the result of setting the lifecycle rules.
	log.Printf("put bucket lifecycle result:%#v\n", result)
}

PHP

<?php

// Include the autoload file to load dependencies.
require_once __DIR__ . '/../vendor/autoload.php';

use AlibabaCloud\Oss\V2 as Oss;
use AlibabaCloud\Oss\V2\Models\LifecycleConfiguration;

// Describe command-line parameters.
$optsdesc = [
    "region" => ['help' => 'The region in which the bucket is located', 'required' => True], // (Required) Specify the region in which the bucket is located.
    "endpoint" => ['help' => 'The domain names that other services can use to access OSS', 'required' => False], // (Optional) Specify the OSS endpoint.
    "bucket" => ['help' => 'The name of the bucket', 'required' => True], // (Required) Specify the name of the bucket.
];

// Generate a long options list to parse the command-line parameters.
$longopts = \array_map(function ($key) {
    return "$key:"; // Add a colon (:) to the end of each parameter to indicate that a value is required.
}, array_keys($optsdesc));

// Parse the command-line parameters.
$options = getopt("", $longopts); 

// Check whether the required parameters are missing.
foreach ($optsdesc as $key => $value) {
    if ($value['required'] === True && empty($options[$key])) {
        $help = $value['help'];
        echo "Error: the following arguments are required: --$key, $help"; // Display the required but missing parameters.
        exit(1); 
    }
}

// Obtain the values of the command-line parameters and assign the values to variables.
$region = $options["region"]; // The region in which the bucket is located.
$bucket = $options["bucket"]; // The name of the bucket.

// Load the AccessKey ID and AccessKey secret from environment variables.
$credentialsProvider = new Oss\Credentials\EnvironmentVariableCredentialsProvider();

// Use the default configuration of the SDK.
$cfg = Oss\Config::loadDefault();

// Specify the credential provider.
$cfg->setCredentialsProvider($credentialsProvider);

// Specify the region.
$cfg->setRegion($region);

// If an endpoint is provided, specify the endpoint.
if (isset($options["endpoint"])) {
    $cfg->setEndpoint($options["endpoint"]);
}

// Create an OSS client instance.
$client = new Oss\Client($cfg);

{}
$lifecycleRule = new Oss\Models\LifecycleRule(
    prefix: 'log/', // The prefix of object names.
    transitions: array(
        new Oss\Models\LifecycleRuleTransition(
            days: 30, // Specify the days.
            storageClass: 'IA', // Change to IA.
            isAccessTime: 'true', // Trigger the change based on the last access time.
            returnToStdWhenVisit: 'true' // Return to the Standard storage class after they are accessed.
        )
    ),
    id: 'rule', // The rule ID.
    status: 'Enabled' // Enable the rule.
);

// Create a lifecycle configuration and add lifecycle rules to the configuration.
$lifecycleConfiguration = new LifecycleConfiguration(
    rules: array($lifecycleRule)
);

// Create a request to set a lifecycle configuration and pass the lifecycle configuration.
$request = new Oss\Models\PutBucketLifecycleRequest(
    bucket: $bucket,
    lifecycleConfiguration: $lifecycleConfiguration
);

// Call the putBucketLifecycle method to configure the lifecycle rules.
$result = $client->putBucketLifecycle($request);

// Display the result.
printf(
    'status code:' . $result->statusCode . PHP_EOL . // The HTTP response status code.
    'request id:' . $result->requestId . PHP_EOL // The request ID.
);

ossutil

Vous pouvez utiliser ossutil pour configurer des règles de cycle de vie. Pour plus d'informations sur l'installation d'ossutil, consultez Installer ossutil.

L'exemple suivant montre comment configurer une règle de cycle de vie pour le bucket examplebucket :

ossutil api put-bucket-lifecycle --bucket examplebucket--lifecycle-configuration "{\"Rule\":{\"ID\":\"rule1\",\"Prefix\":\"tmp/\",\"Status\":\"Enabled\",\"Expiration\":{\"Days\":\"10\"},\"Transition\":{\"Days\":\"5\",\"StorageClass\":\"IA\",\"IsAccessTime\":true,\"ReturnToStdWhenVisit\":true},\"AbortMultipartUpload\":{\"Days\":\"10\"}}}"

Pour plus d'informations sur cette commande, consultez put-bucket-lifecycle.

Référence API

Les opérations précédentes sont basées sur des appels API. Si vous avez besoin d'un degré élevé de personnalisation, vous pouvez envoyer directement des requêtes REST API. Cela nécessite que vous écriviez votre propre code pour calculer les signatures. Pour plus d'informations, consultez PutBucketLifecycle.

FAQ

Que se passe-t-il si je crée deux règles de cycle de vie pour des objets ayant le même préfixe dans un bucket, où l'une est basée sur la dernière heure de modification et l'autre sur la dernière heure d'accès ?

Par exemple, vous créez deux règles de cycle de vie pour le bucket de destination nommé examplebucket. La règle 1 spécifie que tous les objets avec le préfixe doc sont supprimés 30 jours après leur dernière heure de modification. La règle 2 spécifie que tous les objets avec le préfixe doc sont transférés vers la classe de stockage Infrequent Access 30 jours après leur dernière heure d'accès.

OSS exécute les règles de cycle de vie selon le principe de minimisation des coûts pour l'utilisateur. Par conséquent, seule la règle 1 prend effet. En effet, la règle 1 spécifie que les objets correspondants sont supprimés après 30 jours, après quoi aucun frais n'est encouru. En revanche, la règle 2 transfère les objets vers la classe de stockage Infrequent Access, ce qui engendre toujours des frais de stockage et des frais de récupération de données.

Quand une modification apportée à une règle de cycle de vie configurée prend-elle effet, et comment les données qui correspondaient à la règle d'origine sont-elles traitées ?

Par exemple, vous avez configuré une règle de cycle de vie pour que les objets avec le préfixe er soient transférés vers la classe de stockage Infrequent Access 30 jours après le dernier accès, puis retransférés vers la classe de stockage Standard s'ils sont consultés après 30 jours supplémentaires. Toutefois, 35 jours après le dernier accès, vous modifiez le préfixe dans la règle de cycle de vie de er à re. Dans ce cas, les objets d'origine ne sont transférés que vers la classe de stockage Infrequent Access. Le transfert ultérieur vers la classe de stockage Standard ne se produit pas. La dernière heure d'accès pour les objets correspondant à la nouvelle règle est également comptée à partir du moment où le suivi d'accès a été activé pour le bucket.

Si Intelligent Tiering est activé dans un bucket avec versioning, comment les niveaux de stockage s'appliquent-ils aux différentes versions d'un objet ?

Chaque objet dans un bucket avec versioning possède un ID de version unique, et les objets avec des ID de version différents sont indépendants les uns des autres. Par conséquent, une version non actuelle d'un objet peut se trouver dans la classe de stockage Infrequent Access tandis que la version actuelle se trouve dans la classe de stockage Standard.

Puis-je désactiver le suivi d'accès ?

Oui, à condition qu'aucune règle de cycle de vie basée sur la dernière heure d'accès n'existe dans le bucket. Une fois le suivi d'accès désactivé, le système cesse de suivre la dernière heure d'accès des objets. La prochaine fois que vous activerez le suivi d'accès, le système actualisera la dernière heure d'accès pour tous les objets.

Références

La dernière heure d'accès (LastAccessTime) est un attribut important d'un objet et est utilisée dans des scénarios tels que la facturation et les règles de cycle de vie. Une fois le suivi d'accès activé pour un bucket, certaines opérations sur un objet peuvent mettre à jour sa LastAccessTime. Pour plus d'informations, consultez Impact des opérations courantes sur la dernière heure d'accès des objets.