Controle de versão de Blob

Pode ativar o controlo de versões de blobs para manter automaticamente versões anteriores de um objeto. Quando ativas a versão de blob, podes aceder a versões anteriores de um blob para recuperar os teus dados se forem modificados ou eliminados.

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

O controlo de versões de blobs é uma das várias funcionalidades de proteção de dados. Escolher a funcionalidade certa ou a combinação de funcionalidades depende da sua carga de trabalho e do que está a proteger. Para saber mais sobre as recomendações da Microsoft para proteção de dados, consulte Visão Geral da Proteção de Dados.

Versões vs. snapshots

Uma versão em blob é semelhante a um snapshot, mas as duas diferem na forma como são criadas e para o que servem melhor. Uma versão é automática e gerida pelo sistema: o Armazenamento do Azure cria uma nova versão a cada escrita ou eliminação quando a versão de blob está ativada, sem necessidade de lógica de aplicação. Um snapshot é manual e orientado pela aplicação: cria-se explicitamente uma cópia num ponto no tempo quando a sua aplicação decide que é necessária.

Use o controlo de versões quando quiser proteção automática e contínua contra sobrescritas e eliminações acidentais ou maliciosas. Use snapshots quando quiser cópias intencionais de um determinado momento, como um ponto de controlo conhecido antes de uma atualização planeada. A Microsoft recomenda que pare de tirar snapshots dos blobs de bloco quando o versionamento estiver ativado.

Como funciona o versionamento de blobs

Uma versão captura o estado de um blob em um determinado ponto no tempo. Cada versão tem um ID de versão. Quando ativas o controlo de versões de blobs para uma conta de armazenamento, o Armazenamento do Azure cria automaticamente uma nova versão com um ID único quando crias um blob pela primeira vez e cada vez que o modificas.

Um ID de versão pode identificar a versão atual ou uma versão anterior. Um blob só pode ter uma versão atual de cada vez, o seu estado corrente. Um blob pode ter várias versões anteriores.

Quando você cria um novo 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 nova versão é criada para capturar o estado atualizado, e essa nova versão é a versão atual. Quando você exclui um blob, a versão atual do blob 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 seguinte mostra como as versões são criadas nas operações de escrita e como uma versão anterior pode ser promovida à versão atual:

As versões anteriores de blob são imutáveis, o que significa que não podes 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 de versão é o carimbo temporal em que o blob foi atualizado. Atribuis o ID da versão quando crias a versão.

Pode ler ou eliminar uma versão específica de um blob usando o seu ID de versão. Se não incluir o ID da versão, a operação tem como alvo a versão atual.

Quando realiza uma operação de escrita para criar ou modificar um blob, o Armazenamento do Azure devolve 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 que a operação de escrita criou.

O ID da versão mantém-se igual durante toda a vida útil da versão.

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

Quando ativa o controlo de versões de blobs, cada operação de escrita num 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 criar 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 torna-se uma versão anterior, e uma nova versão atual captura o blob atualizado.

O diagrama seguinte mostra como as operações de gravação afetam as versões de blobs. Para simplificar, os diagramas deste artigo mostram o ID da versão como um valor inteiro simples. Na realidade, o 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 ativa o controlo de versões de blobs numa conta de armazenamento, todas as operações de escrita em blobs de bloco desencadeiam a criação de uma nova versão, exceto a operação Put Block.

Para blobs de página e blobs de adição, apenas um subconjunto de operações de gravação aciona a criação de uma versão. Estas operações incluem:

• Inserir Blob
• Colocar Lista de Blocos
• Definir metadados de Blob
• Copiar Blob

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

• Put Page (blob de página)
• Bloco de acréscimo (blob de acréscimo)

Para captar as alterações dessas operações, crie um instantâneo manual. Para mais informações, veja instantâneos de blobs.

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 primeiro exclua o blob e todas as suas versões.

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

Quando realiza a operação Eliminar Blob sem especificar um ID de versão, a versão atual torna-se uma versão anterior, e já não existe uma versão atual. A operação preserva todas as versões anteriores existentes do blob.

O diagrama a seguir mostra o efeito de uma operação de exclusão em um blob versionado:

Para excluir uma versão específica de um blob, forneça a ID dessa versão na operação de exclusão. Se também ativar a eliminação recuperável de blobs na conta de armazenamento, o sistema mantém a versão até expirar o período de retenção da eliminação recuperável.

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

Camadas de acesso

Você pode mover qualquer versão de um blob de bloco, incluindo a versão atual, para um nível de acesso de blob diferente chamando a operação Definir Nível do Blob. Ao mover versões mais antigas de um blob para a camada fria ou de arquivo, é possível beneficiar de preços de capacidade mais baixos. Para obter mais informações, consulte Camadas de acesso Hot, Cool, Cold e Archive para blobs de dados.

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

Habilitar ou desativar o versionamento de blobs

Para instruções sobre como ativar ou desativar a versão de blob, consulte Ativar e gerir a versão de blob.

A desativação da versão de blob não elimina blobs, versões ou instantâneos existentes. Quando desativas o controlo de versões de blobs, não podes criar novas versões.

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

Pode ler ou eliminar versões usando o ID de versão depois de desativar o versioning. Você também pode listar as versões de um blob depois que o controle de versão for desativado.

A replicação de objetos depende do versionamento de blobs. Antes de desabilitar o controle de versão de blob, você deve excluir todas as políticas de replicação de objeto na conta. Para obter mais informações sobre replicação de objetos, consulte Replicação de objetos para blobs de bloco.

O diagrama a seguir mostra como modificar um blob após a desativação do controle de versão cria um blob que não é versionado. Todas as versões existentes associadas ao blob persistem.

Suporte de funcionalidades

O suporte para esta funcionalidade pode ser afetado ao ativar o Data Lake Storage Gen2, o protocolo Network File System (NFS) 3.0 ou o SSH File Transfer Protocol (SFTP). Se já ativou alguma destas funcionalidades, consulte suporte a funcionalidades de Armazenamento de Blobs em contas de Armazenamento Azure para avaliar o suporte desta funcionalidade.

O controle de versão de Blob está disponível para contas de armazenamento de Blob de uso geral padrão v2, Blob de bloco premium e contas de armazenamento de Blob legadas. Contas de armazenamento com um namespace hierárquico ativado para uso com o Azure Data Lake Storage não são atualmente suportadas.

A versão 2019-10-10 e superiores da API REST do Armazenamento do Azure suporta versionamento por blob.

O controlo de versões não é suportado para blobs que carrega utilizando as APIs do Data Lake Storage.

Autorizar operações em versões de blob

Pode autorizar o acesso às versões blob utilizando uma das seguintes abordagens:

• Use o controlo de acesso baseado em papéis do Azure (Azure RBAC) para conceder permissões a um principal de segurança do Microsoft Entra. A Microsoft recomenda o uso do Microsoft Entra ID para uma segurança superior e facilidade de uso. Para mais informações sobre o uso de Microsoft Entra ID com operações de blob, veja Autorizar o acesso a dados em Armazenamento do Azure.
• Utilize uma assinatura de acesso partilhado (SAS) para delegar o 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 numa versão específica. Para mais informações sobre assinaturas de acesso partilhado, consulte Conceder acesso limitado a recursos de Armazenamento do Azure usando assinaturas de acesso partilhado (SAS).
• Use as chaves de acesso à conta para autorizar operações contra versões blob usando a Chave Partilhada. Para obter mais informações, consulte Autorizar com chave compartilhada.

O controle de versão de Blob foi projetado para proteger seus dados contra exclusão acidental ou maliciosa. Para melhorar a proteção, excluir 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 eliminar uma versão do blob

A tabela seguinte mostra quais as ações RBAC do Azure que suportam a eliminação de um blob ou de uma versão do blob.

Parâmetros de assinatura de acesso compartilhado (SAS)

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

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

Considerações sobre a carga de trabalho existente

• Eliminar um blob já não liberta espaço. Quando ativas a versionação, eliminar um blob não remove os seus dados. A versão atual torna-se uma versão anterior que persiste e continua a incorrer em encargos. Cargas de trabalho que dependem de operações de apagamento para libertar espaço de armazenamento continuam a incorrer em encargos até que elimine explicitamente essas versões.

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

Interações entre funcionalidades

Eliminação suave

O controlo de versão de blobs e a eliminação suave de blobs fazem parte da configuração de proteção de dados recomendada para contas de armazenamento. Para mais informações sobre as recomendações da Microsoft para proteção de dados, consulte a visão geral da proteção de dados.

Sobrescrevendo um blob

Se ativares tanto a versão do blob como a soft delete do blob para uma conta de armazenamento, então sobrescrever um blob cria automaticamente uma nova versão anterior que reflete o estado do blob antes da operação de escrita. A nova versão não é eliminada logicamente e persiste até ser explicitamente eliminada. Nenhum instantâneo suavemente eliminado é criado.

Eliminar um blob ou versão

Se ativares tanto o controlo de versões como a eliminação suave de uma conta de armazenamento, ao apagar um blob, a versão atual do blob torna-se uma versão anterior. A operação não cria uma nova versão nem instantâneos eliminados de forma recuperável. O período de retenção de eliminação suave não se aplica ao blob eliminado.

A eliminação suave oferece proteção extra ao eliminar versões de blobs. Quando elimina uma versão anterior do blob, a operação elimina essa versão de forma recuperável. A versão de exclusão suave é preservada até que o período de retenção de exclusão suave termine, momento em que ela é excluída permanentemente.

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

Restaurando uma versão eliminada temporariamente

Utilize a operação Anular eliminação do Blob para restaurar versões eliminadas por soft delete durante o período de retenção de soft delete. A operação Undelete Blob sempre restaura todas as versões excluídas suavemente do blob. Não podes restaurar apenas uma versão apagada de forma suave.

Restaurar versões apagadas suavemente usando a operação Undelete Blob não promove nenhuma versão como a versão atual. Para restaurar a versão atual, primeiro restaure todas as versões excluídas por software e, em seguida, use a operação Copiar Blob para copiar uma versão anterior para uma nova versão atual.

Após o período de retenção de eliminação suave, o sistema apaga permanentemente quaisquer versões de blob com eliminação suave.

Instantâneos de blobs

Um snapshot de um blob é uma cópia apenas de leitura de um blob obtida num determinado momento. Os instantâneos de blobs e as versões de blobs são semelhantes, mas o utilizador ou a sua aplicação criam manualmente um instantâneo, enquanto uma versão de blob é criada automaticamente numa operação de escrita ou eliminação quando ativa o controlo de versões de blobs para a sua conta de armazenamento.

Snapshot de um blob quando o versionamento está ativado

Embora não seja recomendado, podes tirar um snapshot de um blob que também está versionado. Se não conseguir atualizar a sua aplicação para parar de tirar instantâneos de blobs ao ativar o versionamento, a sua aplicação pode suportar tanto instantâneos como versões.

Quando tiras um snapshot de um blob versionado, crias uma nova versão ao mesmo tempo que o snapshot é criado. Também crias uma nova versão atual quando tiras um snapshot.

O diagrama a seguir mostra o que acontece quando você tira um instantâneo de um blob versionado. No diagrama, as versões de blob e instantâneos com 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 carregados usando APIs do Data Lake Storage.

• Não protege contra a eliminação de contentores ou contas. O versionamento funciona apenas ao nível do blob. Eliminar um contentor remove todos os blobs e as suas versões. A recuperação após essa eliminação requer a eliminação recuperável do contentor. Proteger contra a eliminação da conta requer um bloqueio de recurso.

• As versões são imutáveis. Não podes 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. Não podes sobrescrever um blob com outro de tipo diferente enquanto tiver versões anteriores, a menos que primeiro elimines o blob e todas as suas versões.

• Nem todas as gravações 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 desativar o controlo de versões enquanto existirem políticas de replicação de objetos na conta. Deve eliminar primeiro todas as políticas de replicação de objetos.

• Undelete Blob Restaura todas as versões eliminadas de forma recuperável de um blob, não uma única. Não podes restaurar seletivamente uma versão. Undelete nunca promove uma versão à versão atual.

• Limite recomendado de 1.000 versões por blob. Exceder esse limite degrada o desempenho das listas de blobs.

Preços e faturação

Ao ativar a versão de blob, pode incorrer em custos adicionais de armazenamento de dados. Ao desenhar a sua aplicação, considere como estes custos podem acumular-se para manter os custos baixos.

É cobrado pelas versões de blob, como snapshots de blob, à mesma taxa que os dados ativos. A forma como és faturado pelas versões depende de definires explicitamente o nível para as versões atuais ou anteriores de um blob (ou snapshots). Para obter mais informações sobre camadas de blob, consulte Camadas de acesso quentes, frias, frios e de arquivamento para dados de blob.

Se não alterares o escalão de um blob ou versão, és cobrado por blocos únicos de dados nesse blob, nas suas versões e em quaisquer snapshots que esse blob possa ter. Para mais informações, consulte Faturação quando o escalão de blob não estiver explicitamente definido.

Se mudares o nível de um blob ou versão, és faturado pelo objeto inteiro, independentemente de o blob e a versão acabarem no mesmo tier outra vez. Para mais informações, consulte Faturação quando o nível de blob está explicitamente definido.

Para obter mais informações sobre detalhes de cobrança para instantâneos de blob, consulte Instantâneos de Blob.

Para contas de armazenamento que usam smart tier, paga-se por versões e snapshots com o conteúdo completo. Para mais informações, consulte Otimização de custos com a camada inteligente.

Faturação quando não defines explicitamente o nível de blob

Se não definires explicitamente o nível de blob para nenhuma das versões de um blob, és cobrado por blocos ou páginas únicas em todas as versões e por quaisquer snapshots que o blob possa ter. É cobrado pelos dados que são partilhados entre versões de blob apenas uma vez. Quando atualiza um blob, os dados na nova versão atual divergem dos dados armazenados em versões anteriores, por isso ser-lhe-á cobrado pelos dados únicos por bloco ou página.

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

O armazenamento por blobs não tem forma de determinar se dois blocos contêm dados idênticos. Cada bloco que carregas e confirmas é tratado como único, mesmo que tenha os mesmos dados e o mesmo ID de bloco. Como és cobrado por blocos únicos, lembra-te que atualizar um blob quando a versão está ativada resulta em blocos únicos extra e custos extra.

Quando ativa o controlo de versões de blobs, faça com que as operações de atualização em blobs de blocos atualizem o menor número possível de blocos. As operações de gravação que permitem um controle refinado sobre blocos são Put Block e Put Block List. O Put Block faseia 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, por isso, pode resultar em custos adicionais.

Os cenários seguintes demonstram como as cobranças se acumulam para um blob de bloco e as suas versões quando não se define explicitamente o tier 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, por isso só incorres em 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 o mesmo ID, ele não é o mesmo que o bloco 3 na versão anterior. Como resultado, a conta será 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 será 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 seus 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. Este cenário pode ocorrer se escrever para um blob usando a operação Put Blob , porque esta substitui todo o conteúdo do blob.

Faturação quando defines explicitamente o nível do blob

Se definires explicitamente o nível do blob para um blob, versão ou snapshot, pagas pelo comprimento total do conteúdo do objeto no novo tier, independentemente de partilhar blocos com um objeto do tier original. Também pagas pela extensão total do conteúdo da versão mais antiga no nível original. Para quaisquer outras versões ou snapshots anteriores que permaneçam no tier original, paga-se por blocos únicos que partilham, como descrito na Faturação quando o blob tier não está explicitamente definido.

Movendo um blob para uma nova camada

A tabela seguinte descreve o comportamento de faturação de um blob ou versão quando o move para um novo nível.

¹Se existirem outras versões ou instantâneos anteriores que não tenha movido do respetivo escalão original, essas versões ou instantâneos são faturados com base no número de blocos exclusivos que contêm, conforme descrito em Faturação quando o escalão do blob não está explicitamente definido.

O diagrama seguinte ilustra como os objetos são faturados quando se move um blob versionado para outro nível.

Não é possível anular a definição explícita do escalão de acesso para um blob, uma versão ou um instantâneo. Se moveres um blob para um novo nível e depois o voltares ao seu tier original, pagas pelo comprimento total do conteúdo do objeto mesmo que partilhe blocos com outros objetos do tier original.

As operações que definem explicitamente o nível hierárquico de um blob, uma versão ou um instantâneo incluem:

• Set Blob Tier (Definir Camada de Blob)
• Colocar Blob com camada especificada
• Colocar Lista de Bloqueios com camada especificada
• Copiar Blob com nível especificado

Excluindo um blob quando a exclusão suave está habilitada

Quando ativa a eliminação recuperável de blobs, paga por todas as entidades eliminadas de forma recuperável à mesma taxa aplicada aos dados ativos. Se apagares ou sobrescreveres uma versão atual para a qual definiste explicitamente o nível, pagas por quaisquer versões anteriores do blob eliminado de forma recuperável com base no tamanho total do conteúdo. Para mais informações sobre como o controlo de versões de blobs e a eliminação suave funcionam em conjunto, veja Interações com funcionalidades.

Monitorizar e resolver problemas

• A minha política de LCM não apaga versões quando espero: A idade de uma versão baseia-se na altura em que os dados foram originalmente escritos, não em quando se tornou uma versão anterior. O relógio começa na criação do blob, não na sobrescrição que o empurrou para o histórico de versões. Como resultado, um blob que permaneceu atual durante muito tempo antes de ser sobrescrito pode produzir uma versão anterior que já ultrapassa o teu daysAfterCreationGreaterThan limite no momento em que é criada, fazendo com que seja eliminado quase imediatamente. Por outro lado, versões de blobs recentemente criados podem persistir mais tempo do que o esperado. Para confirmar, verifique o carimbo temporal real de criação nas versões em vez de assumir que corresponde ao tempo de sobrescrição. Se precisar de basear a retenção no momento em que uma versão se tornou inatualizada ou pretender um controlo mais detalhado do que os limiares diários permitidos pela gestão do ciclo de vida, considere usar o Armazenamento do Azure Actions. Para mais informações, consulte Ações de Armazenamento.

• A minha fatura continua elevada depois de desativar as versões: As versões existentes permanecem até as apagares manualmente.

• Não consigo desativar a versionação. A replicação de objetos pode ser configurada na conta. Apague primeiro todas as políticas de replicação de objetos e depois desative o controlo de versões. Alternativamente, pode existir uma política de Imutabilidade (WORM) num contentor ou na conta, em que o versionamento não pode ser desativado.

Consulte também

• Habilitar e gerir o controlo de versões de blob
• Criando um instantâneo de um blob
• Eliminação suave para blobs
• Eliminação suave para contentores