Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Uma política WORM de nível da versão é um tipo de política de imutabilidade que pode ser definida na conta, no contêiner ou na versão. Para saber mais sobre o armazenamento imutável para o Armazenamento de Blobs do Azure, consulte Armazenar dados de blob comercialmente críticos com armazenamento imutável em estado de gravação única e leitura múltipla (WORM).
Disponibilidade
Há suporte para as políticas VLW (imutabilidade de nível de versão) no nível da conta para novas contas e no nível do contêiner e do blob para contas/contêineres novos e existentes. Há suporte para essas políticas em contas de blob de blocos de uso geral v2 e premium. Esse recurso não tem suporte em contas de namespace hierárquicas.
Dependência de versão
As políticas de nível de versão exigem que o controle de versão de blob esteja habilitado na conta de armazenamento. Para saber como habilitar o controle de versão de blobs, confira Habilitar e gerenciar o controle de versão de blobs. Tenha em mente que habilitar o controle de versão pode ter um impacto na cobrança. Para mais informações, consulte a seção de Preços e Cobrança para Versionamento de Blobs.
Depois que o controle de versão é habilitado, quando um blob é carregado pela primeira vez, essa versão do blob é a versão atual. Sempre que o blob é substituído, uma nova versão é criada que armazena o estado anterior do blob. Quando você exclui a versão atual de um blob, a versão atual se torna uma versão anterior e é mantida até ser excluída explicitamente. Uma versão anterior do blob possui a política de retenção baseada em tempo que estava em vigor quando a versão atual se tornou uma versão anterior.
Se uma política padrão estiver em vigor para a conta de armazenamento ou contêiner, quando uma operação de substituição criar uma versão anterior, a nova versão atual herdará a política padrão para a conta ou contêiner.
Cada versão pode ter apenas uma política de retenção baseada em tempo configurada. Uma versão também pode ter uma retenção legal configurada.
Para saber como configurar políticas de retenção baseadas em tempo de nível da versão, veja Configurar políticas de imutabilidade para versões de blob.
Ativação e configuração de políticas
Usar políticas imutáveis com WORM em nível de versão é um processo de duas etapas. Primeiro, habilite a imutabilidade no nível da versão. Em seguida, você pode definir políticas de imutabilidade no nível da versão.
Para definir uma política no nível da conta de armazenamento, primeiro você deve habilitar o WORM no nível da versão na conta de armazenamento. Você só pode fazer isso no momento da criação da conta. Não há nenhuma opção para habilitar o WORM no nível da versão para contas pré-existentes.
Para definir uma política no nível do contêiner, primeiro você deve habilitar o WORM no nível da versão na conta OU no contêiner.
Se você planeja habilitar o WORM no nível da versão em um contêiner, a Microsoft recomenda que você habilite-o no momento da criação do contêiner. No entanto, você pode migrar um contêiner habilitado para WORM que não está no nível de versão para um contêiner habilitado para WORM de nível da versão. Se você optar por não migrar um contêiner, ainda poderá definir uma política WORM no nível do contêiner, mas a opção de definir políticas no nível de blob não estará disponível nesse contêiner.
Para definir uma política no nível do blob, você deve habilitar o WORM no nível da versão, seja na conta ou no contêiner. Não há nenhuma opção para habilitar o WORM de nível da versão no nível do blob. Ela precisa ser herdada.
Migração
Os contêineres existentes podem dar suporte à imutabilidade no nível da versão, mas devem passar por um processo de migração primeiro. Esse processo pode levar algum tempo. Depois de habilitado, o suporte ao WORM no nível da versão para esse contêiner não pode ser removido. Você pode migrar dez contêineres de cada vez por conta de armazenamento. O tempo necessário para migrar depende principalmente da quantidade de blobs no contêiner. Contêineres com um grande número de blobs levarão muito mais tempo para serem migrados. Para obter mais informações sobre como migrar um contêiner para dar suporte à imutabilidade no nível da versão, consulte Migrar um contêiner existente para dar suporte à imutabilidade no nível da versão.
Configurar uma política na versão atual
Depois de habilitar o suporte para imutabilidade no nível de versão para uma conta de armazenamento ou contêiner, você terá a opção de configurar uma política de retenção baseada em tempo padrão para a conta ou contêiner. Quando você configura uma política de retenção baseada em tempo padrão para a conta ou contêiner e, em seguida, carrega um blob, o blob herda essa política padrão. Você também pode optar por substituir a política padrão para qualquer blob no upload configurando uma política personalizada para esse blob.
Se a política de retenção baseada em tempo padrão para a conta ou contêiner for desbloqueada, a versão atual de um blob que herda a política padrão também terá uma política desbloqueada. Depois que um blob individual é carregado, você pode reduzir ou estender o período de retenção para a política na versão atual do blob ou excluir a versão atual. Você também pode bloquear a política para a versão atual, mesmo que a política padrão na conta ou contêiner permaneça desbloqueada.
Se a política de retenção baseada em tempo padrão para a conta ou contêiner estiver bloqueada, a versão atual de um blob que herda a política padrão também terá uma política bloqueada. No entanto, se você sobrescrever a política padrão ao fazer upload de um blob definindo uma política somente para esse blob, a política desse blob permanecerá desbloqueada até que você a bloqueie explicitamente. Quando a política na versão atual está bloqueada, você pode estender o intervalo de retenção, mas não pode excluir a política nem reduzir o intervalo de retenção.
Se não houver nenhuma política padrão configurada para a conta de armazenamento ou o contêiner, você poderá carregar um blob com uma política personalizada ou sem política.
Se a política padrão em uma conta de armazenamento ou contêiner for modificada, as políticas em objetos dentro desse contêiner permanecerão inalteradas, mesmo que essas políticas tenham sido herdadas da política padrão.
A tabela a seguir mostra as várias opções disponíveis para definir uma política de retenção baseada em tempo em um blob no upload:
| Status da política padrão na conta ou contêiner | Carregar um blob com a política padrão | Carregar um blob com uma política personalizada | Carregar um blob sem nenhuma política |
|---|---|---|---|
| Política padrão em conta ou contêiner (desbloqueado) | O blob é carregado com a política desbloqueada padrão | O blob é carregado com a política desbloqueada personalizada | O blob é carregado sem nenhuma política |
| Política padrão na conta ou contêiner (bloqueado) | O blob é carregado com a política bloqueada padrão | O blob é carregado com a política desbloqueada personalizada | O blob é carregado sem nenhuma política |
| Nenhuma política padrão em uma conta ou contêiner | Não aplicável | O blob é carregado com a política desbloqueada personalizada | O blob é carregado sem nenhuma política |
Configurar uma política em uma versão anterior
Quando o controle de versão está habilitado, uma operação de gravação ou exclusão em um blob cria uma nova versão anterior desse blob que salva o estado do blob antes da operação. Por padrão, uma versão anterior possui a política de retenção baseada em tempo que estava em vigor para a versão atual, se houver, quando a versão atual se tornou uma versão anterior. A nova versão atual herda a política no contêiner, se houver uma.
Se a política herdada por uma versão anterior for desbloqueada, o intervalo de retenção poderá ser reduzido ou alongado ou a política poderá ser excluída. A política em uma versão anterior também pode ser bloqueada para essa versão, mesmo que a política na versão atual seja desbloqueada.
Se a política herdada por uma versão anterior estiver bloqueada, o intervalo de retenção poderá ser alongado. A política não pode ser excluída nem o intervalo de retenção pode ser reduzido. Se não houver nenhuma política configurada na versão atual, a versão anterior não herdará nenhuma política.
Você pode configurar uma política personalizada para a versão. Se a política em uma versão atual for modificada, as políticas nas versões anteriores existentes permanecerão inalteradas, mesmo que a política tenha sido herdada de uma versão atual.
Exclusão
Depois que uma conta ou contêiner estiver habilitado para uma política imutável, ele não poderá ser excluído até que esteja vazio. O principal a observar é que não importa se uma política imutável foi definida em uma conta WORM ou contêiner no nível de versão, importa se ela está habilitada para uma política. Uma vez que esteja, a conta ou o contêiner deve estar vazio para ser excluído.
Cenários
| Cenário | Operações proibidas | Proteção de blob | Proteção de contêiner | Proteção de conta |
|---|---|---|---|---|
| Uma versão de blob é protegida por uma política de retenção ativa e/ou uma retenção legal está em vigor | Excluir Blob, Definir Metadados de Blob e Colocar Página | A versão de blob não pode ser excluída. Os metadados do usuário não podem ser gravados. Sobrescrever um blob com Put Blob, Put Block List ou Copy Blob cria uma nova versão1. |
A exclusão do contêiner falhará se houver pelo menos um blob no contêiner, independentemente do bloqueio ou não da política. | A exclusão da conta de armazenamento falhará se houver pelo menos um contêiner com o armazenamento imutável no nível da versão habilitado ou se ele estiver habilitado para a conta. |
| Uma versão de blob é protegida por uma política de retenção expirada e nenhuma retenção legal está em vigor | Definir metadados de Blob e inserir página | Uma versão de blob é protegida por uma política de retenção expirada e nenhuma retenção legal está em vigor | A versão de blob pode ser excluída. Sobrescrever um blob com Put Blob, Put Block List ou Copy Blob cria uma nova versão1. |
A exclusão da conta de armazenamento falhará se houver pelo menos um contêiner que contenha uma versão de blob com uma política de retenção baseada em tempo bloqueada. As políticas desbloqueadas não oferecem proteção contra exclusão. |
1 As versões de blob são sempre imutáveis quanto ao conteúdo. Se o controle de versão estiver habilitado para a conta de armazenamento, uma operação de gravação em um blob de blocos criará uma nova versão, com exceção da operação Put Block.
Limites
Só pode haver 10.000 contêineres definidos com políticas de retenção exclusivas baseadas em tempo em uma conta. No entanto, você pode definir uma política de nível de conta que será herdada por mais de 10.000 contêineres.