Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Você pode habilitar o controle de versão de armazenamento de Blob para manter automaticamente as 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.
Atenção
Depois de habilitar o controle de versão de blob para uma conta de armazenamento, cada operação de gravação em um blob nessa conta resulta na criação de uma nova versão. Por esta razão, ativar a versão de blob pode resultar em custos adicionais. Para minimizar os custos, use uma política de gerenciamento do ciclo de vida para excluir automaticamente as versões antigas. Para mais informações sobre gestão do ciclo de vida, consulte Otimize custos automatizando Armazenamento de Blobs do Azure camadas de acesso.
Como funciona o versionamento de blobs
Uma versão captura o estado de um blob em um determinado ponto no tempo. Cada versão é identificada com um ID de versão. Quando a versão de blob está ativada para uma conta de armazenamento, o Armazenamento do Azure cria automaticamente uma nova versão com um ID único quando um blob é criado pela primeira vez e cada vez que o blob é posteriormente modificado.
Um ID de versão pode identificar a versão atual ou uma versão anterior. Um blob pode ter apenas uma versão atual de cada vez.
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 a seguir mostra como as versões são criadas em operações de gravação e como uma versão anterior pode ser promovida para ser a versão atual:
Importante
Ter um grande número de versões por cada blob pode aumentar a latência das operações de listagem de blobs. A Microsoft recomenda manter menos de 1000 versões por blob. Você pode usar o gerenciamento do ciclo de vida para excluir automaticamente as versões antigas. Para mais informações sobre gestão do ciclo de vida, consulte Otimize custos automatizando Armazenamento de Blobs do Azure camadas de acesso.
As versões de blob são imutáveis. Não é possível modificar o conteúdo ou os metadados de uma versão de blob existente.
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.
Importante
A versão por blob não pode ajudar a recuperar da eliminação acidental de uma conta ou contentor de armazenamento. Para evitar a exclusão acidental da conta de armazenamento, configure um bloqueio no recurso da conta de armazenamento. Para mais informações sobre como bloquear uma conta de armazenamento, veja Aplicar um bloqueio de Azure Resource Manager a uma conta de armazenamento.
ID da versão
Cada versão do blob tem um ID de versão único. O valor do identificador da versão corresponde à data/hora 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 chama uma operação de escrita para criar ou modificar um blob, 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 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.
Nota
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:
As operações a seguir não acionam a criação de uma nova versão. Para capturar alterações destas operações, tire um instantâneo manual:
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 você chama a operação Excluir Blob sem especificar uma 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 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 escalão adequado, utilize a gestão do ciclo de vida de blobs. Para mais informações sobre gestão do ciclo de vida, consulte Gerir o ciclo de vida do armazenamento Azure Blob.
Habilitar ou desativar o versionamento de blobs
Para saber como ativar ou desativar o controlo de versão de blob, consulte Ativar e gerir o controlo de versão de blobs.
A desativação da versão de blob não elimina blobs, versões ou instantâneos existentes. Quando desativares a versão de blobs, as versões existentes continuarão acessíveis na tua conta de armazenamento. Nenhuma nova versão é criada posteriormente.
Depois que o controle de versão é desativado, 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.
Controle de versão de blob e exclusã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 o versionamento de blob e a eliminação suave de blob estiverem habilitados para uma conta de armazenamento, então a substituição de um blob criará automaticamente uma nova versão. A nova versão não é excluída suavemente e não é removida quando o período de retenção de exclusão suave expira. Nenhum instantâneo suavemente eliminado é criado.
Eliminar um blob ou versão
Se ativares a versão e o soft delete numa 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 apaga instantâneos suavemente. 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 em blob. Quando apagas uma versão anterior do blob, essa versão é eliminada de forma suave. A versão apagada suavemente é preservada até ao fim do período de retenção de eliminação suave, e depois é eliminada permanentemente.
Para excluir uma versão anterior de um blob, chame a operação Excluir Blob e especifique o ID da versão.
O diagrama a seguir mostra o que acontece quando se elimina um blob ou uma versão de blob.
Restaurando uma versão eliminada temporariamente
Você pode usar a operação Undelete Blob para restaurar versões excluídas por software durante o período de retenção de exclusão suave. 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.
O diagrama seguinte mostra como restaurar versões de blob eliminadas de forma recuperável através da operação Undelete Blob e como restaurar a versão atual do blob através da operação Copy Blob.
Após o término do período de retenção de eliminação suave, quaisquer versões de blob com eliminação suave são eliminadas permanentemente.
Versionamento de blob e instantâneos de blob
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 cria manualmente um instantâneo, enquanto uma versão de blob é criada automaticamente durante uma operação de escrita ou eliminação quando ativa o controlo de versões de blobs para a sua conta de armazenamento.
Importante
A Microsoft recomenda que, depois de ativar o versionamento de blobs, também atualize a sua aplicação para deixar de criar instantâneos dos blocos de dados. Se ativares a versão da tua conta de armazenamento, ela captura e preserva todas as atualizações e eliminações de blocos ao usar versões. Tirar snapshots não oferece qualquer proteção adicional aos dados do blob de bloco se a versão do blob estiver ativada, e pode aumentar os custos e a complexidade da aplicação.
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 tira um snapshot de um blob versionado, cria uma nova versão ao mesmo tempo que cria o snapshot. 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.
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.
| Descrição | Operação do serviço Blob | É necessária uma ação de dados do Azure RBAC | Suporte de funções incorporado no Azure |
|---|---|---|---|
| Excluindo a versão atual | Excluir Blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete | Contribuidor de Dados de Armazenamento de Blobs |
| Eliminar uma versão anterior | Excluir Blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action | Proprietário de Dados de Blobs de Armazenamento |
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.
| Permissão | Símbolo URI | Operações permitidas |
|---|---|---|
| Suprimir | x | Eliminar uma versão de blob. |
Preços e faturação
Ativar a versão de blob pode resultar em custos adicionais de armazenamento de dados na sua conta. Ao desenhar a sua aplicação, esteja atento a como estes encargos podem acumular-se para minimizar custos.
As versões de blobs, tal como os instantâneos de blobs, são faturadas à mesma taxa que os dados ativos. A forma como pagas 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 mudares o nível de um blob ou versão, pagas por blocos únicos de dados nesse blob, as suas versões e quaisquer snapshots que 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, pagas pelo objeto inteiro, independentemente de o blob e a versão acabarem por voltar a estar no mesmo nível. Para mais informações, consulte Faturação quando o nível de blob está explicitamente definido.
Nota
Ativar a versão para dados frequentemente sobrescritos pode aumentar as cargas de capacidade de armazenamento e a latência durante as operações de listagem. Para atenuar essas preocupações, armazene dados que são frequentemente sobrescritos em uma conta de armazenamento separada, com o controle de versão desativado.
Habilitar versões em contas de armazenamento cujo backup é feito com freqüência pode acionar cobranças de recuperação de dados quando as versões são armazenadas em camadas de acesso frio ou frio.
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 do blob para nenhuma das versões de um blob, pagas pelos blocos ou páginas exclusivos existentes em todas as versões e por quaisquer instantâneos que o blob possa ter. Paga-se por dados partilhados entre versões de blob apenas uma vez. Quando atualiza um blob, os dados da nova versão atual diferem dos dados armazenados nas versões anteriores, e paga pelos dados exclusivos de cada bloco ou página.
Quando substitui um bloco dentro de um bloco de blocos, paga 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 da versão anterior. Depois de confirmares o bloco novamente, ele diverge do seu equivalente na versão anterior, e pagas 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. Uma vez que paga por blocos únicos, tenha em conta que atualizar um blob quando o controlo de versões está ativado resulta em mais blocos únicos e custos adicionais.
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. 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, atualiza-se um bloco (bloco 3 no diagrama) no blob. 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. Consequentemente, paga por quatro blocos.
Cenário 3
No cenário 3, atualizas o blob, mas não atualizas a versão. Substitues o bloco 3 pelo bloco 4 no blob atual, mas a versão anterior ainda reflete o bloco 3. Como resultado, paga por quatro blocos.
Cenário 4
No cenário 4, atualiza-se completamente a versão atual e ela não contém nenhum dos seus blocos originais. Como resultado, pagas 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 a camada de blob está explicitamente definida
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, mesmo que partilhe 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.
| Quando defines o nível do blob... | Então você é cobrado por... |
|---|---|
| Explicitamente em uma versão, seja atual ou anterior | A extensão total do conteúdo dessa versão. As versões que não têm uma camada explicitamente definida são cobradas apenas por blocos exclusivos.1 |
| Para arquivar | O comprimento total do conteúdo de todas as versões e instantâneos.1. |
1Se 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 a seguir ilustra como os objetos são cobrados quando um blob versionado é movido para uma camada diferente.
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 apagar ou sobrescrever uma versão atual que tenha um tier explicitamente definido, paga por quaisquer versões anteriores do blob soft-deleted com o conteúdo completo. Para obter mais informações sobre como a gestão de versões de blobs e a eliminação reversível funcionam juntos, consulte Gestão de versões de blobs e eliminação reversível.
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 controlo de versões não é suportado para blobs que carrega utilizando as APIs do Data Lake Storage.