What is OSS lifecycle management - Object Storage Service: Central de Documentação do Alibaba Cloud

A frequência de acesso aos dados diminui com o tempo. O gerenciamento de ciclo de vida permite criar regras que transicionam objetos automaticamente para classes de armazenamento de custo mais baixo (como Infrequent Access ou Archive) ou os excluem após um período especificado, reduzindo custos de armazenamento sem intervenção manual.

Como funciona

O gerenciamento de ciclo de vida usa regras definidas pelo usuário para automatizar operações em objetos de um bucket. O OSS carrega uma nova regra em até 24 horas após a criação. Após o carregamento, o OSS executa as regras correspondentes em um horário fixo diário, geralmente após as 00:00 (UTC) do dia seguinte (08:00 UTC+8).

Uma regra de ciclo de vida consiste em três partes principais:

Objetos a serem gerenciados: filtre os objetos de destino por prefixo do objeto (Prefix), tag do objeto (Tag) ou tamanho do objeto (ObjectSize).

As regras de ciclo de vida não aceitam caracteres curinga, correspondência por sufixo ou expressões regulares.
Ações a serem executadas: defina o que fazer com os objetos filtrados:
- Transição de classe de armazenamento (Transition): migre objetos para classes de armazenamento de custo mais baixo, como Infrequent Access, Archive ou Cold Archive.
- Expiração e exclusão (Expiration): exclua objetos após atingirem um período de ciclo de vida especificado.
- Limpeza de fragmentos (AbortMultipartUpload): exclua automaticamente partes de uploads multipart incompletos após um tempo especificado.
Políticas de acionamento: defina quando as ações são acionadas:
- Hora da última modificação (Last-Modified-Time): transicione ou exclua objetos com base na hora da última modificação. Indicado para dados com um ciclo de vida claro, como logs e backups.
- Hora do último acesso (Last-Access-Time): após ativar o rastreamento de acesso, transicione objetos com base na hora do último acesso. Indicado para padrões de acesso imprevisíveis (como uma biblioteca de materiais). Os dados frios são rebaixados automaticamente e restaurados ao serem acessados.

Todos os parâmetros configuráveis estão documentados em Lifecycle configuration elements.

Cenários de configuração

Limpar automaticamente arquivos de log expirados

Os servidores enviam logs diariamente para um diretório designado. Use uma regra baseada na hora da última modificação para delete all objects in a bucket after a specified number of days, liberando espaço de armazenamento e reduzindo custos.

Usar classificação automática em camadas para dados quentes e frios

Para dados com frequência de acesso incerta (imagens de site, vídeos, documentos), ative o rastreamento de acesso e use a lifecycle rule based on the last access time to implement intelligent data tiering. O sistema migra dados frios para classes de armazenamento de custo mais baixo com base nos padrões de acesso reais.

Limpar automaticamente versões anteriores

Com o versionamento ativado, o OSS salva substituições e exclusões como versões anteriores. Quando um bucket acumula muitas versões anteriores ou marcadores de exclusão expirados, use a lifecycle rule based on the last modified time together with versioning to reduce storage costs. Essa prática reduz custos e melhora o desempenho da listagem de objetos.

Limpar automaticamente fragmentos de uploads multipart

Uploads multipart interrompidos deixam partes não mescladas, que continuam gerando cobranças. Configure uma regra de ciclo de vida para clean up incomplete parts after a specified time.

Além dos cenários anteriores, é possível implementar políticas de gerenciamento de dados mais refinadas. Para obter mais informações, consulte Lifecycle configuration examples. Combine diferentes regras e gerencie os dados no seu bucket de forma refinada conforme a necessidade.

Várias regras de ciclo de vida

O uso de várias regras de ciclo de vida depende de dois mecanismos: prioridade de execução da regra e mecanismo de substituição de configuração.

Prioridade de execução da regra

Um bucket pode ter várias regras de ciclo de vida independentes. Quando um objeto corresponde a várias regras, o sistema determina a ação final com base em todos os resultados correspondentes.

Quando várias regras correspondem simultaneamente ao mesmo objeto, o OSS as executa na seguinte ordem de prioridade: Delete Object > Transition to Deep Cold Archive > Transition to Cold Archive > Transition to Archive > Transition to Infrequent Access > Transition to Standard.

Importante

A ação de exclusão sempre tem prioridade maior que as transições de classe de armazenamento. Defina o prazo das regras de exclusão como maior que o das regras de transição. Isso evita a exclusão dos objetos antes da conclusão da transição.

Exemplo de execução

Suponha que você especifique as duas regras de ciclo de vida a seguir e que ambas correspondam ao mesmo objeto.

Regra 1: especifica que objetos modificados pela última vez há mais de 365 dias são migrados para a classe de armazenamento Infrequent Access.
Regra 2: especifica que objetos modificados pela última vez há mais de 365 dias são excluídos.

Resultado: o OSS excluirá o objeto correspondente mais de 365 dias após a hora da sua última modificação.

Mecanismo de substituição de configuração

O console faz a mesclagem automaticamente, o que evita substituições acidentais. No entanto, ao usar o ossutil, SDKs ou a API, cada chamada PutBucketLifecycle substitui completamente todas as configurações de ciclo de vida existentes. O envio de uma nova regra sem incluir as existentes resulta na exclusão das regras anteriores.

Exemplo

Para adicionar uma nova regra às regras existentes, execute as seguintes etapas:

Recupere todas as regras de ciclo de vida em vigor no momento (por exemplo, Regra 1).
Adicione a nova regra (por exemplo, Regra 2).
Envie a configuração completa que inclui todas as regras (Regra 1 + Regra 2).

Observação: se você enviar apenas a configuração contendo a nova regra (Regra 2) sem incluir a regra existente (Regra 1), o OSS excluirá a Regra 1, que deixará de vigorar.

Implantação em produção

Para implantar o gerenciamento de ciclo de vida com segurança em produção:

Teste antes de implantar: crie regras primeiro em um bucket de teste. Verifique o comportamento antes de aplicá-las à produção.
Use regras de exclusão com cautela: defina o prefixo com precisão para evitar a exclusão acidental de dados importantes.
Ative o versionamento como proteção: para dados críticos, ative o versionamento para que você possa recuperar objetos excluídos acidentalmente por uma regra de ciclo de vida a partir de uma versão anterior.
Use transições em níveis para evitar taxas extras: certifique-se de que o tempo de acionamento de cada estágio subsequente exceda a soma do tempo de acionamento do estágio anterior e sua duração mínima de armazenamento. Isso evita cobranças por transições prematuras.
- Exemplo incorreto: Standard 10 days -> Infrequent Access 5 days -> Archive Storage 5 days. Essa configuração resulta no armazenamento do objeto Archive por apenas 20 dias (< 60 days), o que gera taxas de capacidade por armazenamento Archive inferior à duração especificada.
- Exemplo correto: Standard 30 days -> Infrequent Access 90 days -> Archive Storage. O objeto permanece em IA por 60 dias (atendendo ao mínimo de 30 dias) antes de migrar para Archive no dia 90.

Faturamento

A configuração de regras de ciclo de vida é gratuita. A cobrança de taxas ocorre quando as regras são executadas e alteram o estado de armazenamento.

Taxas de solicitação: cada transição de classe de armazenamento, exclusão de objeto ou exclusão de parte gera uma solicitação do tipo Put. A cobrança ocorre por solicitação. Os detalhes de faturamento estão em Lifecycle fee description.

Para buckets com muitos arquivos pequenos, as taxas de solicitação podem ser significativas. Avalie os custos antes de configurar as regras.
Taxas de armazenamento: após a transição, a cobrança dos objetos ocorre com base na taxa da nova classe de armazenamento.

Importante
Classes de armazenamento como Infrequent Access, Archive e Cold Archive têm requisitos de duração mínima de armazenamento (por exemplo, 30 dias para Infrequent Access e 60 dias para Archive). Se uma regra de ciclo de vida excluir ou migrar um objeto antes que a duração mínima de armazenamento seja atingida, haverá cobrança pelo período de armazenamento restante. Para evitar conditional capacity fees for storage shorter than the specified duration devido a transições ou exclusões, consulte How do I avoid capacity fees for storage shorter than the specified duration?. Certifique-se de que a duração mínima de armazenamento seja atendida antes de migrar ou excluir o objeto.
Taxas de recuperação de dados: as regras de ciclo de vida em si não geram taxas de recuperação de dados. No entanto, acessar objetos em classes de armazenamento como Infrequent Access ou Archive gera taxas de recuperação.
- A leitura direta de um objeto IA gera taxas de recuperação de dados.
- A leitura de um objeto Archive gera taxas de capacidade de recuperação de dados para acesso em tempo real.
- A restauração de um objeto Archive gera taxas de solicitação do tipo Put e taxas de capacidade de recuperação.
- A restauração de um objeto Cold Archive ou Deep Cold Archive gera taxas de solicitação de recuperação, taxas de capacidade de recuperação e taxas de capacidade restaurada temporária.
Importante
Para objetos Cold Archive e Deep Cold Archive, a taxa varia dependendo da prioridade de recuperação escolhida. Quanto maior a prioridade, maior a taxa.

Perguntas frequentes

Qual é a diferença entre as regras de ciclo de vida baseadas na hora da última modificação e na hora do último acesso?

As principais diferenças:

Política	Com base na hora da última modificação	Com base na hora do último acesso
Scenarios	Indicado para cenários de dados com padrões de acesso fixos ou previsíveis.	Indicado para cenários de dados com padrões de acesso não fixos ou imprevisíveis.
Supports Object Deletion	Suportado.	Não.
Object Recovery After Deletion	Se o versionamento não estiver ativado, não é possível recuperar objetos excluídos. Se o versioning estiver ativado, quando uma regra de ciclo de vida exclui um objeto da versão atual, ele se torna uma versão anterior e pode ser recuperado. No entanto, quando uma regra de ciclo de vida exclui um objeto de uma versão anterior, não é possível recuperá-lo.	Uma política baseada na hora do último acesso não envolve a recuperação de objetos após a exclusão.
Reversibility Of Storage Class Transition	Não reversível. Após a migração de um objeto de Standard para IA, não é possível revertê-lo automaticamente. Para mais detalhes, consulte Transition storage class. A migração para IA, Archive, Cold Archive ou Deep Cold Archive envolve tamanho mínimo faturável, duração mínima de armazenamento e taxas de recuperação de dados. Para mais detalhes, consulte Transition storage class.	Reversível. Quando um objeto é migrado automaticamente da classe de armazenamento Standard para a classe Infrequent Access, você pode optar por retorná-lo à classe Standard ao acessá-lo. Importante Um objeto é considerado "acessado" apenas quando acessado por meio de uma chamada de API GetObject. Outras chamadas de API não se aplicam. Isso também envolve tamanho mínimo faturável, duração mínima de armazenamento e taxas de recuperação de dados. Para mais detalhes, consulte Lifecycle rules based on last access time.

Por que minha regra de ciclo de vida não está funcionando?

Verifique os seguintes itens:

Tempo de vigência: a regra existe há mais de 24 horas? O OSS precisa de tempo para carregar novas regras.
Correspondência de prefixo: o prefixo na regra está definido corretamente? Por exemplo, uma pasta deve ser logs/ em vez de logs.
Condição de tempo: a hora da última modificação ou do último acesso do objeto atende de fato ao número de dias especificado?
Recurso de pré-requisito: se você estiver usando uma regra baseada na hora do último acesso, ativou o recurso de rastreamento de acesso para o bucket?

Após ativar o versionamento, excluí um objeto. Por que meu uso de armazenamento não diminuiu?

Com o versionamento ativado, uma operação de exclusão cria apenas um marcador de exclusão. O objeto original se torna uma versão anterior e continua ocupando espaço. Crie uma regra de ciclo de vida para limpar versões anteriores.

Os objetos migrados serão restaurados se eu excluir a regra de ciclo de vida?

Não. A exclusão de uma regra não reverte ações já executadas. Restaure manualmente os objetos migrados para sua classe de armazenamento original.

Por que um objeto excluído ainda ocupa espaço após a ativação do versionamento?

Com o versionamento ativado, uma operação de exclusão cria um marcador de exclusão. O objeto original se torna uma versão anterior e continua ocupando espaço. Configure uma regra para excluir versões anteriores.

O que devo fazer se receber o erro Set bucket lifecycle error, InvalidArgument, Days in the Transition action for StorageClass Archive must be more than the Transition action for StorageClass IA?

Esse erro ocorre porque os tempos de transição para diferentes classes de armazenamento não atendem aos requisitos. O período de transição configurado para o bucket deve satisfazer: Infrequent Access < Archive < Cold Archive < Deep Cold Archive.

O recurso de ciclo de vida do OSS pode executar ações de migração ou exclusão de dados com base em sufixos de arquivo?

As regras de ciclo de vida não aceitam correspondência por sufixo (como .png). Use as seguintes soluções alternativas:

Método 1: armazene objetos usando um prefixo específico

Armazene objetos com um sufixo específico (como arquivos .png) em um diretório dedicado com um prefixo como images/. Em seguida, configure uma regra de ciclo de vida que corresponda ao prefixo images/.

Método 2: use tags de objetos

Adicione uma tag (como image:png) a todos os arquivos .png e, em seguida, configure a regra de ciclo de vida para corresponder à tag. Para obter mais informações, consulte Tag objects.

As regras de ciclo de vida se aplicam a objetos existentes em um bucket?

Uma regra de ciclo de vida se aplica a todos os objetos, incluindo aqueles enviados antes da configuração da regra. Por exemplo, se uma regra configurada em 7 de outubro excluir objetos após 30 dias, o OSS excluirá em 6 de novembro um objeto enviado em 5 de outubro, e excluirá em 9 de novembro um objeto enviado em 8 de outubro.

Como modifico uma ou mais configurações de regra de ciclo de vida?

Suponha que seu bucket tenha duas regras de ciclo de vida (Rule1 e Rule2) e você queira modificar a Rule1:

Chame GetBucketLifecycle para recuperar todas as regras de ciclo de vida atuais (Rule1 e Rule2).
Em seguida, modifique o item de configuração da regra de ciclo de vida Rule1.
Chame PutBucketLifecycle e envie as regras atualizadas (Rule1 + Rule2).

Existem registros de log para transições de classe e exclusões por expiração executadas por regras de ciclo de vida?

Sim. O OSS registra em log todas as transições de classe e exclusões por expiração bem-sucedidas executadas por regras de ciclo de vida. Os campos de log são os seguintes:

Operação
- CommitTransition: migra a classe de armazenamento.
- ExpireObject: exclui um objeto expirado.
Solicitação de sincronização

lifecycle: as operações de transição e exclusão acionadas.

Os campos de log do OSS estão documentados em Log field details. O faturamento de consulta de log é abordado em Billing.

Posso criar uma única regra de ciclo de vida para limpar marcadores de exclusão e objetos da versão atual ao mesmo tempo?

Não, não é possível. Você deve criar uma regra para limpar marcadores de exclusão e outra para excluir objetos da versão atual.

Como limpar rapidamente todos os arquivos em um bucket usando regras de ciclo de vida

Bucket com versionamento desativado

Para um bucket com versionamento desativado, basta configurar uma regra de ciclo de vida para limpar automática e rapidamente todos os arquivos e partes de uploads multipart incompletos.

Faça login no console do OSS, acesse a página Bucket List e encontre o bucket de destino.
No painel de navegação à esquerda, escolha Data Security > Versioning e confirme se o versionamento está desativado para o bucket.
No painel de navegação à esquerda, escolha Data Management > Lifecycle. Defina uma regra de ciclo de vida para excluir automaticamente todos os arquivos no bucket 1 dia após a última modificação. Além disso, limpe automaticamente as partes de uploads multipart incompletos criadas há mais de 1 dia.

Bucket com versionamento ativado

Quando o versionamento é ativado para um bucket, o bucket gera objetos da versão atual, objetos de versões anteriores, partes de uploads multipart incompletos e marcadores de exclusão. Basta configurar uma regra de ciclo de vida para limpar automática e rapidamente todos esses itens.

Faça login no console do OSS, acesse a página Bucket List e encontre o bucket de destino.
No painel de navegação à esquerda, escolha Data Security > Versioning e confirme se o versionamento está ativado para o bucket.
No painel de navegação à esquerda, escolha Data Management > Lifecycle. Defina uma regra de ciclo de vida para excluir automaticamente todos os objetos da versão atual e de versões anteriores no bucket 1 dia após a última modificação. Além disso, limpe automaticamente as partes de uploads multipart incompletos criadas há mais de 1 dia. Essa regra também limpa os marcadores de exclusão.

Se eu criar duas regras de ciclo de vida para objetos com o mesmo prefixo, uma baseada na hora da última modificação e a outra na hora do último acesso, qual regra o OSS aplica?

Por exemplo, suponha que você crie duas regras de ciclo de vida para o bucket de destino examplebucket. A Regra 1 especifica que o OSS exclui todos os objetos com o prefixo doc no bucket 30 dias após a hora da última modificação. A Regra 2 especifica que o OSS migra todos os objetos com o prefixo doc no bucket para a classe de armazenamento Infrequent Access 30 dias após a hora do último acesso.

O OSS executa regras de ciclo de vida com base no princípio de minimizar os custos do usuário. Portanto, apenas a Regra 1 entra em vigor. Isso ocorre porque a Regra 1 exclui os objetos após 30 dias, o que interrompe a geração de todas as taxas. Em contrapartida, a Regra 2, que migra objetos para a classe de armazenamento Infrequent Access, ainda geraria taxas relacionadas ao armazenamento ou à recuperação de dados.

Quando uma alteração em uma regra de ciclo de vida configurada entra em vigor e como o OSS trata os dados correspondidos pela regra original?

Por exemplo, você configura uma regra de ciclo de vida para objetos com o prefixo er. Essa regra migra os objetos para a classe de armazenamento Infrequent Access 30 dias após a hora do último acesso e, em seguida, os migra de volta para a classe de armazenamento Standard se eles forem acessados novamente após mais 30 dias. No entanto, 35 dias após a hora do último acesso de um objeto, você altera o prefixo na regra de ciclo de vida de er para re. Como resultado, o objeto é migrado para a classe de armazenamento Infrequent Access, mas a ação de migração de volta para a classe de armazenamento Standard não entra em vigor. Para objetos correspondentes à regra atualizada, o OSS calcula o último acesso a partir da ativação do rastreamento de acesso no bucket.

Em um bucket com versionamento ativado, como o armazenamento em camadas inteligente afeta as classes de armazenamento de diferentes versões de objetos?

Em um bucket com versionamento ativado, cada versão de objeto tem um ID de versão exclusivo e o OSS a trata como um objeto independente. Portanto, uma versão anterior de um objeto pode estar na classe de armazenamento Infrequent Access, enquanto a versão atual do mesmo objeto está na classe de armazenamento Standard.