Estrutura de política de gerenciamento de ciclo de vida do Azure Blob Storage

2025-06-17

Você pode usar políticas de gerenciamento de ciclo de vida para fazer a transição de blobs para camadas de acesso econômicas com base em seus padrões de uso. Você também pode excluir blobs inteiramente no final do ciclo de vida. Embora uma política possa operar em versões atuais, versões anteriores e snapshots, ela não opera em blobs em contêineres do sistema, como os contêineres $logs ou $web. Para obter informações gerais, consulte a visão geral do gerenciamento do ciclo de vida do Armazenamento de Blobs do Azure.

Este artigo descreve os elementos de uma política de gerenciamento de ciclo de vida. Para obter exemplos de política, consulte os seguintes artigos:

Dica

Embora o gerenciamento do ciclo de vida ajude você a otimizar seus custos para uma única conta, você pode usar as Ações de Armazenamento do Azure para realizar várias operações de dados em escala em várias contas.

Regras

Uma política de gerenciamento do ciclo de vida é uma coleção de regras em um documento JSON. O seguinte JSON de exemplo mostra uma definição de regra completa:

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

Nome do parâmetro	Tipo de parâmetro	Anotações
réguas	Uma matriz de objetos de regra	Pelo menos uma regra é necessária em uma política. Você pode definir até 100 regras em uma política.

Cada regra na política tem vários parâmetros, descritos na seguinte tabela:

Nome do parâmetro	Tipo	Anotações	Obrigatório
nome	fio	Um nome de regra pode incluir até 256 caracteres alfanuméricos. O nome da regra diferencia maiúsculas de minúsculas. Ela deve ser exclusiva em uma política.	Sim
habilitado	Booliano	Um booliano opcional para permitir que uma regra seja desabilitada temporariamente. O valor padrão é true.	Não
tipo	Um valor de enumeração	O tipo válido atual é `Lifecycle`.	Sim
definição	Um objeto que define a regra de ciclo de vida	Cada definição é composta por um conjunto de filtros e um conjunto de ações.	Sim

Filtros

Os filtros limitam as ações a um subconjunto de blobs na conta de armazenamento. Você pode usar um filtro para especificar quais blobs devem ser incluídos. Um filtro não fornece meios para especificar quais blobs devem ser excluídos. Se mais de um filtro for definido, um AND lógico será aplicado a todos os filtros. A tabela a seguir descreve cada parâmetro.

Nome do filtro	Tipo	Descrição	Obrigatório
blobTypes	Matriz de valores de enumeração predefinidos	O tipo de blob (blockblob ou appendBlob)	Sim
prefixMatch	Matriz das cadeias de caracteres	Essas cadeias de caracteres são prefixos a serem correspondidos.	Não
blobIndexMatch	Uma matriz de valores de dicionário	Esses valores consistem em condições de valor e chave de marca de índice de blob a serem correspondidas.	Não

Filtro de correspondência de prefixo

Se você aplicar o filtro prefixMatch, cada regra poderá definir até 10 prefixos que diferenciam maiúsculas e minúsculas. Uma cadeia de caracteres de prefixo deve começar com um nome de contêiner. Por exemplo, se você quiser corresponder a todos os blobs no caminho https://myaccount.blob.core.windows.net/sample-container/blob1/..., especifique o prefixMatch como sample-container/blob1.

Esse filtro corresponderá a todos os blobs em sample-container que os nomes começam com blob1. Se você não definir uma correspondência de prefixo, a regra se aplicará a todos os blobs dentro da conta de armazenamento. As cadeias de caracteres de prefixo não dão suporte à correspondência de caracteres coringa. Caracteres como * e ? são tratados como literais das cadeias de caracteres.

Filtro de correspondência de índice de blob

Se você aplicar o filtro blobIndexMatch, cada regra poderá definir até 10 condições de marca de índice de blob. Por exemplo, se você quiser corresponder a todos os blobs com Project = Contoso sob https://myaccount.blob.core.windows.net/, o filtro blobIndexMatch será {"name": "Project","op": "==","value": "Contoso"}. Se você não definir um valor para o filtro blobIndexMatch , a regra se aplicará a todos os blobs dentro da conta de armazenamento.

Ações

Você deve definir pelo menos uma ação para cada regra. Ações são aplicadas aos blobs filtrados quando a condição de execução é atendida. Para saber mais sobre as condições de execução, consulte a seção Condições de execução da ação deste artigo. A tabela a seguir descreve cada ação que está disponível em uma definição de política.

Ação	Descrição
TierToCool	Defina um blob para a camada de acesso esporádico. Não há suporte para blobs de acréscimo, blob de páginas ou blobs em uma conta de armazenamento de blob de blocos premium.
TierToCold	Defina um blob para a camada de acesso a frio. Não há suporte para blobs de acréscimo, blob de páginas ou blobs em uma conta de armazenamento de blob de blocos premium.
TierToArchive	Defina um blob para a camada de arquivos. A reidratação de um blob não atualiza a última propriedade modificada ou a última propriedade de tempo de acesso do blob. Como resultado, essa ação pode mover blobs reidratados de volta para a camada de arquivos. Para evitar que isso aconteça, adicione a `daysAfterLastTierChangeGreaterThan` condição a essa ação. Essa ação não tem suporte com blobs de acréscimo, blob de páginas ou blobs em uma conta de armazenamento de blob de blocos premium. Também não há suporte para blobs que usam um escopo de criptografia ou blobs em contas configuradas para armazenamento com redundância de zona (ZRS), armazenamento com redundância de zona geográfica (GZRS) / armazenamento com redundância de zona geográfica com acesso de leitura (RA-GZRS).
enableAutoTierToHotFromCool	Se um blob estiver definido como a camada fria, essa ação moverá automaticamente esse blob para a camada quente quando o blob for acessado. Essa ação só está disponível quando usada com a condição de execução daysAfterLastAccessTimeGreaterThan . Essa ação não tem efeito sobre blobs que foram configurados para a camada fria antes de habilitar a ação em uma regra. Essa ação move blobs de frio para quente apenas uma vez em 30 dias. Essa proteção é implementada para proteger contra várias penalidades de exclusão antecipada cobradas na conta. Não é compatível com versões ou snapshots anteriores.
excluir	Exclui um blob. Não há suporte para blob de páginas ou blobs em um contêiner imutável.

Se você definir mais de uma ação no mesmo blob, o gerenciamento do ciclo de vida aplicará a ação mais barata ao blob. Por exemplo, uma ação de exclusão é mais barata do que a ação tierToArchive e a ação tierToArchive é mais barata que a ação tierToCool .

Excluir a ação em contas que têm um namespace hierárquico

Quando aplicada a uma conta com um namespace hierárquico habilitado, uma ação de exclusão remove diretórios vazios. Se o diretório não estiver vazio, a ação de exclusão removerá objetos que atendam às condições de política no primeiro ciclo de execução da política de ciclo de vida. Se essa ação resultar em um diretório vazio que também atenda às condições de política, esse diretório será removido no próximo ciclo de execução e assim por diante.

Excluir a ação em blobs que têm versões e instantâneos

Uma política de gerenciamento de ciclo de vida não excluirá a versão atual de um blob até que quaisquer versões ou instantâneos anteriores associados a esse blob tenham sido excluídos. Se os blobs em sua conta de armazenamento tiverem versões ou instantâneos anteriores, você deverá incluir versões e instantâneos anteriores ao especificar uma ação de exclusão como parte da política.

Condições de execução de ação

Todas as condições de execução são baseadas em tempo. Se o número de dias que se passaram exceder o número especificado para a condição, a ação associada pode ser executada. As condições de política são avaliadas em cada objeto apenas uma vez durante uma execução de política. Em alguns casos, um objeto pode atender à condição depois de já ter sido avaliado por uma execução. Esses objetos são processados em execuções subseqüentes.

As versões atuais usam o horário da última modificação ou do último acesso, as versões anteriores usam a hora de criação da versão e os instantâneos de blob usam a hora de criação do instantâneo para controlar a idade.

A tabela a seguir descreve cada condição de execução de ação.

Nome da condição	Tipo	Descrição
daysAfterModificationGreaterThan	Número Inteiro	O tempo decorrido em dias após a última modificação do blob de tempo. Aplica-se a ações em uma versão atual de um blob.
daysAfterCreationGreaterThan	Número Inteiro	O tempo decorrido em dias após o tempo de criação. Aplica-se a ações na versão atual de um blob, a versão anterior de um blob ou um instantâneo de blob.
daysAfterLastAccessTimeGreaterThan	Número Inteiro	O tempo decorrido em dias após o horário do último acesso ou, em alguns casos, a data em que a política foi habilitada. Para saber mais, consulte a seção de acompanhamento de tempo do Access abaixo. Aplica-se a ações na versão atual de um blob quando o rastreamento de acesso estiver habilitado.
daysAfterLastTierChangeGreaterThan	Número Inteiro	O tempo decorrido em dias após a última alteração da camada de blob. A duração mínima em dias em que um blob reidratado é mantido em camadas de acesso frequente, esporádico ou frio antes de ser retornado para a camada de arquivo morto. Aplica-se somente a ações tierToArchive .

Controle de tempo de acesso

Você pode habilitar o rastreamento do tempo de acesso para manter um registro de quando o seu blob é lido ou gravado pela última vez e utilizá-lo como um filtro para gerenciar a hierarquização e a retenção do seu blob de dados.

Quando você habilita o controle de tempo de acesso, uma propriedade de blob chamada LastAccessTime é atualizada quando um blob é lido ou gravado. As operações Obter Blob e Colocar Blob são operações de acesso e atualizarão o tempo de acesso de um blob. No entanto, as propriedades Get Blob, Get Blob Metadata e Get Blob Tags não são operações de acesso. Essas operações não atualizarão o tempo de acesso de um blob.

Se você aplicar a condição de execução daysAfterLastAccessTimeGreaterThan a uma política, a LastAccessTime será usada para determinar se essa condição é atendida.

Se você aplicar a condição de execução daysAfterLastAccessTimeGreaterThan a uma política, mas não tiver habilitado o rastreamento de tempo de acesso, a LastAccessTime opção não será usada. Em vez disso, a data em que a política de ciclo de vida foi habilitada é usada. Na verdade, a data em que a política de ciclo de vida foi habilitada é usada em qualquer situação em que a LastAccessTime propriedade do blob seja um valor nulo. Isso pode acontecer mesmo se você habilitar o acompanhamento de tempo de acesso em casos em que um blob não foi acessado desde que o rastreamento foi habilitado.

Observação

Para minimizar o impacto na latência de acesso de leitura, somente a primeira leitura das últimas 24 horas atualiza o horário do último acesso. As leituras subsequentes no mesmo período de 24 horas não atualizam o horário do último acesso. Se um blob for modificado entre leituras, o horário do último acesso será o mais recente dos dois valores.

Para saber como habilitar o controle de tempo de acesso, consulte Opcionalmente habilitar o controle de tempo de acesso.

Compartilhar via