Escreva uma vez no nível da versão, leia muitas políticas (WORM) para dados de blob imutáveis
Uma política WORM (write once, read many) no nível da versão é um tipo de política de imutabilidade que pode ser definida no nível da conta, contêiner ou versão. Para saber mais sobre o armazenamento imutável para o Armazenamento de Blobs do Azure, consulte Armazenar dados de blob críticos para os negócios com armazenamento imutável em um estado WORM (write once, read many).
Disponibilidade
As políticas de imutabilidade no nível da versão (VLW) são suportadas 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. Essas políticas são suportadas para contas v2 de uso geral e contas de blob de bloco premium. Esse recurso não é suportado em contas de namespace hierárquico.
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 para a conta de armazenamento. Para saber como habilitar o controle de versão de blob, consulte Habilitar e gerenciar o controle de versão de blob. Lembre-se de que habilitar o controle de versão pode ter um impacto na cobrança. Para obter mais informações, consulte a seção Preço e cobrança para Controle de versão de Blob.
Depois que o controle de versão é habilitado, quando um blob é carregado pela primeira vez, essa versão do blob é a versão atual. Cada vez 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 de blob anterior 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 no tempo configurada. Uma versão também pode ter uma retenção legal configurada.
Para saber como configurar políticas de retenção baseadas no tempo no nível da versão, consulte Configurar políticas de imutabilidade para versões de blob.
Habilitação e definição de políticas
O uso de políticas imutáveis com o WORM de 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, você deve primeiro habilitar o WORM no nível da versão na conta de armazenamento. Você pode fazer isso somente no momento da criação da conta. Não há 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, você deve primeiro 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ê o habilite no momento da criação do contêiner. No entanto, você pode migrar um contêiner habilitado para WORM sem nível de versão para um contêiner habilitado para WORM de nível de 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 nesse 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 de blob, você deve habilitar o WORM no nível da versão na conta ou no contêiner. Não há opção para ativar o WORM no nível da versão no nível do blob; deve ser herdada.
Migração
Os contêineres existentes podem oferecer suporte à imutabilidade no nível da versão, mas devem passar por um processo de migração primeiro. Este processo pode demorar algum tempo. Uma vez ativado, o suporte WORM no nível da versão para esse contêiner não pode ser removido. Você pode migrar 10 contêineres de cada vez por conta de armazenamento. Para obter mais informações sobre como migrar um contêiner para oferecer suporte à imutabilidade no nível da versão, consulte Migrar um contêiner existente para oferecer suporte à imutabilidade no nível da versão.
Configurar uma política na versão atual
Depois de habilitar o suporte para imutabilidade em 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 carregamento configurando uma política personalizada para esse blob.
Se a política de retenção baseada no 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 encurtar ou estender o período de retenção da 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 no 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ê substituir a política padrão quando carregar um blob definindo uma política apenas para esse blob, a política desse blob permanecerá desbloqueada até que você o bloqueie explicitamente. Quando a política na versão atual é bloqueada, você pode estender o intervalo de retenção, mas não pode excluir a política ou encurtar 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 no contêiner | Carregar um blob com a política padrão | Carregar um blob com uma política personalizada | Carregar um blob sem política |
|---|---|---|---|
| Política padrão na conta ou contêiner (desbloqueado) | O Blob é carregado com a política desbloqueada padrão | O Blob é carregado com uma política desbloqueada personalizada | O Blob é carregado sem 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 uma política desbloqueada personalizada | O Blob é carregado sem política |
| Nenhuma política padrão em qualquer conta ou contêiner | N/A | O Blob é carregado com uma política desbloqueada personalizada | O Blob é carregado sem 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 no 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.
Se a política herdada por uma versão anterior for desbloqueada, o intervalo de retenção poderá ser encurtado ou alongado ou a política poderá ser excluída. A política de uma versão anterior também pode ser bloqueada para essa versão, mesmo que a política da versão atual esteja desbloqueada.
Se a política herdada por uma versão anterior estiver bloqueada, o intervalo de retenção poderá ser aumentado. A política não pode ser excluída, nem o intervalo de retenção pode ser encurtado. 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 em versões anteriores existentes permanecerão inalteradas, mesmo que a política tenha sido herdada de uma versão atual.
Eliminação
Quando uma conta ou contêiner é habilitado para uma política imutável, ele não pode ser excluído até que esteja vazio. A principal coisa a observar é que não importa se uma política imutável foi definida em uma conta ou contêiner WORM no nível da versão, importa se ela está habilitada para uma política. Uma vez assim, a conta ou contêiner deve estar vazio para ser excluído.
Cenários
| Cenário | Operações proibidas | Proteção de blob | Proteção de contentores | Produção de contas |
|---|---|---|---|---|
| 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 do blob não pode ser excluída. Os metadados do usuário não podem ser gravados. A substituição de um blob por Put Blob, Put Block List ou Copy Blob cria uma nova versão1. |
A exclusão do contêiner falhará se pelo menos um blob existir no contêiner, independentemente de a política estar bloqueada ou desbloqueada. | A exclusão da conta de armazenamento falhará se houver pelo menos um contêiner com 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 colocar 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 blob pode ser excluída. A substituição de um blob por 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 fornecem proteção contra exclusão. |
1 As versões de Blob são sempre imutáveis para o 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 bloco 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 baseadas em tempo exclusivas em uma conta; no entanto, você pode definir uma política no nível da conta que será herdada por mais de 10.000 contêineres.