Controle de versão de blobs

Você pode ativar a versão de blob para manter automaticamente versões anteriores de um objeto. Quando você habilita o controle de versão de blobs, pode acessar versões anteriores de um blob para recuperar seus dados caso eles sejam modificados ou excluídos.

Configuração de proteção de dados recomendada

O versionamento de blob é um dos vários recursos de proteção de dados. Escolher o recurso certo ou a combinação de recursos depende da sua carga de trabalho e contra o que você está se protegendo. Para saber mais sobre as recomendações da Microsoft para proteção de dados, veja Visão Geral da Proteção de Dados.

Versões versus snapshots

Uma versão blob é semelhante a um snapshot, mas as duas diferem em como são criadas e para o que são mais adequadas. Uma versão é automática e gerenciada pelo sistema: o Armazenamento do Azure cria uma nova versão a cada escrita ou exclusão quando a versão de blob é ativada, sem necessidade de lógica de aplicação. Um snapshot é manual e orientado pela aplicação: você cria explicitamente uma cópia em um ponto no tempo quando sua aplicação decide que é necessária.

Use versionamento quando quiser proteção automática e contínua contra sobrescrevimentos e excluções acidentais ou maliciosas. Use snapshots quando quiser cópias deliberadas em um ponto específico no tempo, como um checkpoint conhecido e bom antes de uma atualização planejada. A Microsoft recomenda que você pare de tirar snapshots dos blobs de blocos assim que o versioning for ativado.

Como o controle de versão de blobs funciona

Uma versão captura o estado de um blob em um determinado momento. Cada versão possui um ID de versão. Quando você ativa a versão de blob para uma conta de armazenamento, o Armazenamento do Azure cria automaticamente uma nova versão com um ID único quando você cria um blob pela primeira vez e cada vez que você modifica o blob.

Uma ID de versão pode identificar a versão atual ou uma versão anterior. Um blob pode ter apenas uma versão atual por vez, isto é, seu estado atual. Um blob pode ter várias versões anteriores.

Quando você cria um blob, existe uma única versão e essa versão é a versão atual. Quando você modifica um blob existente, a versão atual se torna uma versão anterior. Uma versão é criada para capturar o estado atualizado e essa versão é a versão atual. Quando você exclui um blob, a versão atual dele se torna uma versão anterior e não há mais uma versão atual. Todas as versões anteriores do blob persistem.

O diagrama a seguir mostra como as versões são criadas em operações de escrita e como uma versão anterior pode ser promovida para a versão atual:

Versões anteriores de blob são imutáveis, ou seja, você não pode modificar o conteúdo ou os metadados.

ID da versão

Cada versão do blob tem um ID de versão único. O valor do ID da versão é o carimbo de data e hora de quando o blob foi atualizado. Você atribui o ID da versão ao criar a versão.

Você pode ler ou excluir uma versão específica de um blob usando seu ID de versão. Se você não incluir o ID da versão, a operação mira a versão atual.

Quando você realiza uma operação de escrita para criar ou modificar um blob, o Armazenamento do Azure retorna o cabeçalho x-ms-version-id na resposta. Este cabeçalho contém o ID de versão da versão atual do blob, criada pela operação de escrita.

O ID da versão permanece o mesmo durante toda a vida útil da versão.

Controle de versão em operações de gravação

Ao ativar o versionamento de blobs, cada operação de gravação em um blob cria uma nova versão. As operações de gravação incluem Put Blob, Put Block List, Copy Blob e Set Blob Metadata.

Se a operação de escrita cria um novo blob, o blob resultante é a versão atual do blob. Se a operação de escrita modificar um blob existente, a versão atual se torna uma versão anterior, e uma nova versão atual captura o blob atualizado.

O diagrama a seguir mostra como as operações de gravação afetam as versões de blob. Para simplificar, os diagramas deste artigo exibem o ID da versão como um valor inteiro simples. Na realidade, a ID da versão é um carimbo de data/hora. A versão atual é mostrada em azul e as versões anteriores são mostradas em cinza.

Quando você habilita o controle de versão de blobs em uma conta de armazenamento, todas as operações de gravação em blobs de bloco disparam a criação de uma nova versão, exceto a operação Put Block.

Para blobs de páginas e blobs de acréscimo, apenas um subconjunto de operações de gravação dispara a criação de uma versão. Essas operações incluem:

• Colocar Blob
• Colocar Lista de Blocos
• Definir Metadados de Blob
• Copiar Blob

As seguintes operações não acionam a criação de uma nova versão:

• Put Page (blob de páginas)
• Append Block (blob de acréscimo)

Para capturar as mudanças dessas operações, faça um snapshot manual. Para mais informações, veja Snapshots de blob.

Todas as versões de um blob devem ter o mesmo tipo de blob. Se um blob tiver versões anteriores, você não poderá substituir um blob de um tipo por outro tipo, a menos que exclua primeiro o blob e todas as respectivas versões.

Controle de versão em operações de exclusão

Quando você realiza a operação Delete Blob sem especificar um ID de versão, a versão atual se torna uma versão anterior, e não há mais uma versão atual. A operação preserva todas as versões anteriores existentes do blob.

O seguinte diagrama mostra o efeito de uma operação de exclusão em um blob com controle de versão:

Para excluir uma versão específica de um blob, forneça a ID dessa versão na operação de exclusão. Se você também habilitar a exclusão reversível de blob para a conta de armazenamento, o sistema manterá a versão até que o período de retenção de exclusão reversível termine.

Gravar novos dados no blob cria uma versão atual do blob. Essa ação não afeta nenhuma versão existente, como mostrado no diagrama a seguir.

Níveis de acesso

Você pode mover qualquer versão de um blob de blocos, incluindo a versão atual, para uma camada de acesso de blob diferente chamando a operação Set Blob Tier. Ao mover versões mais antigas de um blob para a camada fria (cool) ou de arquivo (archive), você pode aproveitar preços de capacidade mais baixos. Para obter mais informações, confira Camadas de acesso frequente, esporádico e de arquivos para dados de blob.

Para automatizar o processo de mover blobs de blocos para o nível apropriado, crie uma política de Gerenciamento do Ciclo de Vida, crie uma tarefa de Ações de Armazenamento ou ative o Smart Tier.

Habilitar ou desabilitar o controle de versão de blobs

Para instruções sobre como ativar ou desativar o controle de versão de blob, veja Habilitar e gerenciar o controle de versão de blob.

Desabilitar o controle de versão de blobs não exclui os blobs, versões ou instantâneos existentes. Quando você desativa o controle de versão de blob, não pode criar novas versões.

Depois de desativar o controle de versão, modificar a versão atual cria um blob que não é uma versão. Todas as atualizações subsequentes para o blob substituirão os dados sem salvar o estado anterior. Todas as versões existentes persistem como versões anteriores.

Você pode ler ou excluir versões usando o ID da versão após o versionamento ser desativado. Você também poderá listar as versões de um blob depois que o controle de versão for desabilitado.

A replicação de objeto depende do controle de versão do blob. Antes de desabilitar o controle de versão do blob, exclua todas as políticas de replicação de objeto na conta. Para saber mais sobre a replicação de objeto, confira Replicação de objeto blob de blocos.

O diagrama a seguir mostra como modificar um blob após o controle de versão ser desabilitado cria um blob sem controle de versão. Todas as versões existentes associadas ao blob são persistidas.

Suporte a recursos

O suporte para esse recurso pode ser afetado pela habilitação de Data Lake Storage Gen2, protocolo NFS (Sistema de Arquivos de Rede) 3.0 ou protocolo SFTP (Protocolo de Transferência de Arquivo SSH). Se você habilitou qualquer um desses recursos, consulte suporte a recursos do Armazenamento de Blobs em contas do Armazenamento do Azure para verificar sua compatibilidade.

O controle de versão de blob está disponível para contas de armazenamento de Blobs herdadas, de v2 de uso geral padrão e de blob de blocos premium. No momento, não há suporte para contas de armazenamento com um namespace hierárquico habilitado para uso com Azure Data Lake Storage.

A versão 2019-10-10 e superior da API REST do Armazenamento do Azure dá suporte ao controle de versão de blob.

A versionagem não é suportada para blobs que você envia usando APIs do Data Lake Storage.

Autorizar operações em versões de blobs

Você pode autorizar o acesso às versões blob usando uma das seguintes abordagens:

• Use o controle de acesso baseado em função do Azure (Azure RBAC) para conceder permissões a um principal de segurança do Microsoft Entra. Microsoft recomenda usar Microsoft Entra ID para maior segurança e facilidade de uso. Para obter mais informações sobre como usar Microsoft Entra ID com operações de blob, consulte Authorize o acesso aos dados em Armazenamento do Azure.
• Use uma assinatura de acesso compartilhada (SAS) para delegar acesso às versões do blob. Especifique o ID de versão para o tipo bvde recurso assinado, que representa uma versão blob, para criar um token SAS para operações em uma versão específica. Para obter mais informações sobre assinaturas de acesso compartilhado, consulte Conceder acesso limitado aos recursos do Armazenamento do Azure usando assinaturas de acesso compartilhado (SAS).
• Use as chaves de acesso da conta para autorizar operações em versões de blob usando a Chave Compartilhada. Para obter mais informações, consulte Autorizar com Chave Compartilhada.

O controle de versão de blobs foi projetado para proteger os seus dados contra exclusão acidental ou mal-intencionada. Para aprimorar a proteção, a exclusão de uma versão de blob requer permissões especiais. As seções a seguir descrevem as permissões necessárias para excluir uma versão de blob.

Ação do Azure RBAC para excluir uma versão de blob

A tabela a seguir mostra quais ações do Azure RBAC dão suporte à exclusão de um blob ou de uma versão de blob.

Parâmetros de SAS (Assinatura de Acesso Compartilhado)

O recurso assinado de uma versão do blob é bv. Para obter mais informações, confira Criar uma SAS de serviço ou Criar uma SAS de delegação de usuário.

A tabela a seguir mostra qual permissão é necessária em uma SAS para excluir uma versão de blob.

Considerações sobre a carga de trabalho existente

• Deletar um blob não libera mais espaço. Quando você ativa o versionamento, excluir um blob não remove seus dados. A versão atual se torna uma versão anterior que persiste e continua a gerar cobranças. Cargas de trabalho que dependem de operações de exclusão para liberar armazenamento continuam sofrendo cobranças até que você exclua explicitamente essas versões.

• Cargas de trabalho com muitas sobrescritas podem acumular versões. As versões persistem até que você as exclua explicitamente. Essa persistência pode levar ao acúmulo de versões se você não gerenciá-las corretamente. Para reduzir custos, faça com que as alterações em nível de bloco sejam cobradas no nível do bloco em todas as versões, minimizando os custos por versão.

Interações entre funcionalidades

Exclusão suave

O controle de versão e a exclusão temporária de blob fazem parte da configuração de proteção de dados recomendada para contas de armazenamento. Para obter mais informações sobre as recomendações do Microsoft para proteção de dados, consulte a visão geral da proteção de dados.

Como substituir um blob

Se você ativar o versionamento de blobs e a exclusão temporária de blobs em uma conta de armazenamento, a substituição de um blob criará automaticamente uma nova versão anterior do blob que reflete o estado do blob antes da operação de gravação. A nova versão não é removida logicamente e persiste até ser explicitamente excluída. Nenhum instantâneo excluído de maneira temporária é criado.

Como excluir um blob ou uma versão

Se você ativar tanto o controle de versão quanto a eliminação suave para uma conta de armazenamento, ao excluir um blob, a versão atual do blob se torna uma versão anterior. A operação não cria uma nova versão nem snapshots excluídos temporariamente. O período de retenção de exclusão reversível não se aplica ao blob excluído.

A exclusão suave oferece proteção extra ao excluir versões de blob. Quando você exclui uma versão anterior do blob, a operação exclui temporariamente essa versão. A versão excluída de maneira temporária é preservada até que o período de retenção de exclusão temporária termine. Após isso, ela será excluída permanentemente.

Para excluir uma versão anterior de um blob, chame a operação Delete Blob e especifique a ID da versão.

Como restaurar uma versão excluída de maneira temporária

Use a operação Restaurar Blob para restaurar versões excluídas de forma reversível durante o período de retenção de exclusão reversível. A operação Undelete Blob sempre restaura todas as versões com exclusão temporária do blob. Você não pode restaurar somente uma única versão excluída temporariamente.

Restaurar versões excluídas logicamente usando a operação Undelete Blob não promove nenhuma versão a versão atual. Para restaurar a versão atual, primeiro restaure todas as versões excluídas temporariamente e use a operação Copy Blob para copiar uma versão anterior para a versão atual.

Após o término do período de retenção de exclusão reversível, o sistema elimina permanentemente quaisquer versões de blob com exclusão reversível.

Instantâneos de Blob

Um snapshot de blob é uma cópia somente leitura de um blob, feita em um momento específico. Snapshots de blob e versões de blob são semelhantes, mas você ou seu aplicativo criam manualmente um snapshot, enquanto uma versão de blob é criada automaticamente em uma operação de escrita ou exclusão quando você ativa a versão de blob para sua conta de armazenamento.

Instantâneo de um blob quando o controle de versão está habilitado

Embora não seja recomendado, você pode criar um snapshot de um blob que também esteja versionado. Se não for possível atualizar seu aplicativo para parar de tirar instantâneos de blobs ao habilitar o controle de versão, seu aplicativo poderá oferecer suporte a instantâneos e versões.

Quando você faz um snapshot de um blob versionado, cria uma nova versão ao mesmo tempo que o snapshot. Você também cria uma nova versão atual ao tirar um snapshot.

O diagrama a seguir mostra o que acontece quando você cria um instantâneo de um blob com controle de versão. No diagrama, as versões de blob e os instantâneos com a ID de versão 2 e 3 contêm dados idênticos.

Limitações conhecidas

• Não é suportado em contas de namespace hierárquico (Azure Data Lake Storage), nem para blobs enviados usando APIs do Data Lake Storage.

• Não protege contra exclusão de contêiner ou conta. A versionagem funciona apenas no nível do blob. Deletar um contêiner remove todos os blobs e suas versões. A recuperação dessa exclusão exige a exclusão temporária do contêiner. Proteger contra exclusão de contas requer um bloqueio de recursos.

• As versões são imutáveis. Você não pode alterar o conteúdo ou os metadados de uma versão existente.

• Todas as versões de um blob devem ter o mesmo tipo de blob. Você não pode sobrescrever um blob com outro tipo de blob enquanto ele tiver versões anteriores, a menos que primeiro exclua o blob e todas as suas versões.

• Nem todas as operações de gravação criam uma versão. Consulte as informações anteriores deste artigo que descrevem as exceções. Para capturar esses estados, use um snapshot manual.

• Não é possível desabilitar o versionamento enquanto existem políticas de replicação de objetos na conta. Você deve deletar todas as políticas de replicação de objetos primeiro.

• Undelete Blob restaura todas as versões excluídas temporariamente de um blob, não uma única. Você não pode restaurar apenas uma versão específica. O Undelete nunca promove uma versão para a atual.

• Teto recomendado de 1.000 versões por blob. Excedê-lo degrada o desempenho da listagem de blobs.

Preços e cobrança

Ao ativar o controle de versão de blob, pode incorrer em custos extras de armazenamento de dados. Ao projetar sua aplicação, considere como essas cobranças podem se acumular para manter os custos baixos.

Você é cobrado pelas versões de blob, como snapshots de blob, na mesma taxa que dados ativos. Como você é cobrado pelas versões depende de se você definir explicitamente o nível para as versões atuais ou anteriores de um blob (ou snapshots). Para saber mais sobre as camadas de blobs, confira Camadas de acesso frequente, esporádico e de arquivos para dados de blob.

Se você não mudar a camada de um blob ou de uma versão, você será cobrado por blocos únicos de dados em todo esse blob, suas versões e quaisquer snapshots que ele possa ter. Para mais informações, veja Faturamento quando o nível de blob não estiver explicitamente definido.

Se você mudar o nível de um blob ou versão, você é cobrado por todo o objeto, independentemente de o blob e a versão acabarem no mesmo tier novamente. Para mais informações, consulte Cobrança quando a camada de blob é definida explicitamente.

Para obter mais informações sobre detalhes de cobrança dos instantâneos de blob, confira Instantâneos de blob.

Para contas de armazenamento que usam smart tier, você paga por versões e snapshots com conteúdo completo. Para obter mais informações, consulte Otimizar custos com a camada inteligente.

Cobrança quando você não define explicitamente a camada do blob

Se você não definir explicitamente o nível de blob para quaisquer versões de um blob, você é cobrado por blocos ou páginas únicas em todas as versões, e por quaisquer snapshots que possam ter. Você é cobrado por dados que são compartilhados entre versões de blob apenas uma vez. Quando você atualiza um blob, os dados na nova versão atual divergem dos dados armazenados em versões anteriores, então você é cobrado pelos dados únicos por bloco ou página.

Quando você substitui um bloco dentro de um blob de blocos, você é cobrado por esse bloco como um bloco único. Essa regra se aplica mesmo que o bloco tenha o mesmo ID de bloco e os mesmos dados que tinha na versão anterior. Depois que você faz commit do bloco novamente, ele diverge do seu equivalente na versão anterior, e você é cobrado pelos dados dele. A mesma regra se aplica a uma página em um blob de páginas que você atualiza com dados idênticos.

O armazenamento de blobs não tem uma forma de determinar se dois blocos contêm dados idênticos. Cada bloco que você envia e faz commit é tratado como único, mesmo que tenha os mesmos dados e o mesmo ID de bloco. Como você é cobrado por blocos únicos, lembre-se de que atualizar um blob quando o versioning está ativado resulta em blocos únicos extras e cobranças extras.

Ao habilitar o versionamento de blobs, realize operações de atualização em block blobs de modo que elas atualizem o menor número possível de blocos. As operações de gravação que permitem controle refinado sobre os blocos são Put Block e Put Block List. O Put Block prepara as alterações, mas a modificação real e a criação da versão acontecem na operação Put Block List. A operação Put Blob , por outro lado, substitui todo o conteúdo de um blob e, portanto, pode levar a cobranças extras.

Os cenários a seguir demonstram como as cobranças são acumuladas para um blob de blocos e suas versões quando você não define explicitamente a camada do blob.

Cenário 1

No cenário 1, o blob tem uma versão anterior. O blob não é atualizado desde que a versão foi criada, então você só recebe cargas para blocos únicos 1, 2 e 3.

Cenário 2

No cenário 2, um bloco (bloco 3 no diagrama) no blob é atualizado. Embora o bloco atualizado contenha os mesmos dados e a mesma ID, ele não é igual ao bloco 3 na versão anterior. Como resultado, a conta é cobrada por quatro blocos.

Cenário 3

No cenário 3, o blob é atualizado, mas a versão não. O bloco 3 é substituído pelo bloco 4 no blob atual, mas a versão anterior ainda reflete o bloco 3. Como resultado, a conta é cobrada por quatro blocos.

Cenário 4

No cenário 4, a versão atual está completamente atualizada e não contém nenhum dos blocos originais. Como resultado, a conta é cobrada por todos os oito blocos únicos - quatro na versão atual e quatro combinados nas duas versões anteriores. Esse cenário pode ocorrer se você escrever em um blob usando a operação Put Blob , porque ela substitui todo o conteúdo do blob.

Faturamento quando você define explicitamente o nível do blob

Se você definir explicitamente o nível do blob para um blob, versão ou snapshot, você paga pelo comprimento total do conteúdo do objeto no novo tier, independentemente de ele compartilhar blocos com um objeto do tier original. Você também paga pela extensão total do conteúdo da versão mais antiga na categoria original. Para quaisquer outras versões anteriores ou snapshots que permaneçam no nível original, você paga por blocos exclusivos que eles compartilham, conforme descrito em Cobrança quando a camada do blob não está definida explicitamente.

Como mover um blob para uma nova camada

A tabela a seguir descreve o comportamento de faturamento de um blob ou versão quando você o move para um novo nível.

¹Se houver outras versões ou snapshots anteriores que você não migrou de seu nível original, essas versões ou snapshots serão cobrados com base no número de blocos exclusivos que contêm, conforme descrito em Cobrança quando a camada do blob não está definida explicitamente.

O diagrama a seguir ilustra como os objetos são faturados quando você move um blob versionado para um nível diferente.

Não é possível desfazer a definição explícita da camada (tier) de um blob, versão ou snapshot. Se você mover um blob para uma nova camada e depois movê-lo de volta para sua camada original, pagará pelo tamanho total do conteúdo do objeto, mesmo se ele compartilhar blocos com outros objetos na camada original.

As operações que definem explicitamente a camada de um blob, versão ou instantâneo incluem:

• Definir Camada do Blob
• Put Blob com a camada especificada
• Put Block List com a camada especificada
• Copy Blob com a camada especificada

Como excluir um blob quando a exclusão temporária está habilitada

Ao habilitar a exclusão reversível de blobs, você paga por todas as entidades excluídas reversivelmente a mesma tarifa aplicada aos dados ativos. Se você deletar ou sobrescrever uma versão atual para a qual definiu explicitamente o nível, você paga por qualquer versão anterior do blob excluído temporariamente pelo comprimento total do conteúdo. Para mais informações sobre como a versão de blob e a soft delete funcionam juntas, veja Interações com funcionalidades.

Monitoramento e solução de problemas

• Minha política de LCM não exclui versões quando eu espero: A idade de uma versão é baseada em quando você escreveu originalmente seus dados, não em quando ela se tornou uma versão anterior. O relógio começa na criação do blob, não na sobrescrita que o empurrou para o histórico de versões. Como resultado, um blob que permaneceu atual por muito tempo antes de ser sobrescrito pode produzir uma versão anterior que já ultrapassa seu limite daysAfterCreationGreaterThan no momento em que é criada, fazendo com que seja deletado quase imediatamente. Por outro lado, versões de blobs recentemente criados podem persistir por mais tempo do que o esperado. Para confirmar, verifique o carimbo de tempo real de criação nas versões em vez de assumir que ele corresponde ao tempo de sobrescrevimento. Se você precisar basear a retenção em quando uma versão se tornou inatualizada ou quiser um controle mais detalhado do que os limites diários permitidos pelo gerenciamento do ciclo de vida, considere usar o Armazenamento do Azure Actions. Para mais informações, veja Ações de Armazenamento.

• Minha fatura ainda está alta após desativar as versões: As versões existentes permanecem até que você as exclua manualmente.

• Não consigo desativar o versionamento. A replicação de objetos pode ser configurada na conta. Exclua todas as políticas de replicação de objetos primeiro e depois desative o controle de versões. Alternativamente, uma política de Imutabilidade (WORM) pode existir em um contêiner ou em uma conta em que o controle de versão não pode ser desativado.

Confira também

• Habilitar e gerenciar o controle de versão de blob
• Como criar um instantâneo de um blob
• Exclusão temporária para blobs
• Exclusão temporária para contêineres