Instantâneos de BLOB

Um snapshot é uma cópia somente leitura de um blob tirada em um ponto específico no tempo. Você não precisa ativar o recurso de snapshots de blob. Em vez disso, crie snapshots sob demanda usando a Snapshot Blob operação. Para mais informações, veja Operação de Blob Snapshot. Você pode automatizar a criação de snapshots usando scripts personalizados para capturar cópias pontuais de blobs em um cronograma ou antes ou depois de operações específicas.

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

Snapshots de blob são 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.

Snapshots x versões

Um snapshot é semelhante a uma versão em blob, mas as duas diferem em como são criadas e para o que são mais adequadas. 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. 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.

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 e em um ponto no tempo, como um checkpoint validado antes de uma atualização planejada, em vez de capturar cada alteração.

Como funcionam os snapshots

Um snapshot de um blob é idêntico ao seu blob base, exceto que o URI do blob possui um valor DateTime adicionado ao URI do blob para indicar o momento em que o snapshot foi tirado. Por exemplo, se um URI de blob de páginas for http://storagesample.core.blob.windows.net/mydrives/myvhd, o URI do instantâneo será semelhante a http://storagesample.core.blob.windows.net/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z.

Quando você cria um instantâneo de um blob, as propriedades do sistema são copiadas para o instantâneo com os mesmos valores. Os metadados do blob de base também são copiados no instantâneo, a menos que você especifique metadados separados para o instantâneo ao criá-lo. Depois de criar um instantâneo, você pode lê-lo, copiá-lo ou excluí-lo, mas não é possível modificá-lo. Quaisquer concessões associadas ao blob básico não afetam o instantâneo. Não é possível adquirir uma concessão em um instantâneo.

Um blob pode ter qualquer número de instantâneos. Snapshots persistem até que você os exclua explicitamente, seja de forma independente ou como parte de uma operação de Exclusão de Blob para o blob base. Você pode criar um snapshot de um blob no tier hot, cold ou cool. Você não pode criar um snapshot de um blob arquivado.

Snapshots são especialmente úteis para tipos e operações de blob que não são capturados pelo versionamento de blob. Como algumas operações de escrita, como Put Page (blobs de página) e Append Block (blobs de acréscimo), não criam versões de blob mesmo quando o controle de versão está ativado, snapshots fornecem uma forma de capturar o estado de um blob em um determinado momento ao usar essas APIs. Por exemplo, um arquivo VHD armazena as informações e o status atuais de um disco de VM. Você pode desanexar um disco de dentro da VM ou desligá-la, tirar um snapshot do arquivo VHD dela e, depois, usar esse snapshot para recuperar o arquivo VHD naquele momento e recriar a VM.

O diagrama a seguir mostra como os snapshots são criados e como um snapshot pode ser promovido para ser o blob atual:

Gerenciar e restaurar snapshots

Você pode criar, listar e excluir snapshots. Você também pode usar um snapshot para restaurar um blob base a um estado anterior. As seções seguintes descrevem cada operação e as ferramentas correspondentes.

Restaurar um blob de um instantâneo

Como você não pode modificar um snapshot, você restaura um blob base copiando um snapshot sobre ele. Chame a operação Copy Blob e especifique o URI do snapshot como fonte de cópia. Esse processo promove o estado do snapshot para se tornar o blob base atual, preservando os snapshots existentes do blob.

Listar instantâneos

Você pode enumerar os snapshots associados ao blob base para acompanhar seus snapshots atuais usando a operação List Blobs e especificando o valor snapshots no parâmetro include. Por padrão, uma solicitação de listagem de blobs não retorna snapshots. Defina include=snapshots para retornar todos os snapshots de cada blob junto com o blob base. Para mais informações, veja a Lista de Blobs. Você também pode usar o inventário de blobs do Armazenamento do Azure para gerar um relatório agendado dos blobs na sua conta, incluindo seus snapshots, definindo o includeSnapshots campo como true na definição da regra de inventário. Para mais informações, veja Blob Inventory.

Excluir instantâneos

Você deve deletar um snapshot explicitamente. Para deletar um snapshot individual, chame a operação Delete Blob e especifique o valor DateTime do snapshot no parâmetro de consulta do snapshot.

Você não pode deletar um blob base enquanto ele tem snapshots ativos. Para excluir um blob base e todos os seus snapshots juntos, chame Delete Blob com o x-ms-delete-snapshots cabeçalho definido como include. Para deletar apenas os snapshots e manter o blob base, defina o cabeçalho para only.

Gerencie snapshots com ferramentas

Você pode gerenciar snapshots usando o portal, CLI do Azure e Azure PowerShell.

$ctx = New-AzStorageContext -StorageAccountName <storage-account> -UseConnectedAccount

$blob = Get-AzStorageBlob -Container <container> `
    -Blob <blob> `
    -Context $ctx

$snapshot = $blob.ICloudBlob.Snapshot()
$snapshot.SnapshotTime

$blob.ICloudBlob.Container.ListBlobs(<blob>, $true, "Snapshots")

az storage blob snapshot --account-name <storage-account> \
    --container-name <container> \
    --name <blob> \
    --auth-mode login

az storage blob list --account-name <storage-account> \
    --container-name <container> \
    --prefix <blob> \
    --include s \
    --auth-mode login

Suporte a recursos

Esse recurso não está ativado para contas do Data Lake Storage Gen2. Além disso, o protocolo Network File System (NFS) 3.0, ou o SSH File Transfer Protocol (SFTP) podem impactar o suporte a esse recurso. Se você ativar alguma dessas capacidades, consulte suporte a recursos do Armazenamento de Blobs em contas do Armazenamento do Azure para avaliar o suporte a esse recurso. Considere mecanismos alternativos. Exemplos incluem Soft delete para blobs, AzCopy e Vaulted Backup.

Interações entre funcionalidades

Versioning

Quando você ativa o versionamento, snapshots geralmente são redundantes para blobs de bloco. Se você ativar tanto a versão quanto os snapshots ao mesmo tempo, tirar um snapshot gera tanto um snapshot quanto uma nova versão. Esse processo aumenta o número de objetos armazenados sem adicionar proteção. Para obter mais informações, consulte controle de blob.

Exclusão suave

A soft delete se aplica a snapshots: quando você exclui um snapshot, ele se torna excluído temporariamente. Você pode restaurá-lo durante o período de retenção usando o Undelete Blob. Além disso, a forma como você cria e fatura pelos snapshots varia dependendo se a versão está ativada. Quando o versionamento está desativado, sobrescrever um blob cria um snapshot de exclusão reversível. Quando o controle de versão está ativado, ela cria uma nova versão em vez disso. Se você definir explicitamente o nível em um blob base, paga o conteúdo total por versões anteriores ou snapshots do blob deletado de forma soft. Para detalhes sobre esse comportamento de faturamento, veja a seção Preços e faturamento. Para mais informações sobre soft delete, veja Blob Soft Delete.

Replicação de objeto

Você não pode replicar snapshots. Apenas o blob base é replicado. Para mais informações, veja Replicação de Objetos.

Gerenciamento do ciclo de vida

O gerenciamento do ciclo de vida pode selecionar e excluir snapshots usando o subtipo snapshot nas regras de política. Para mais informações, veja Gerenciamento do Ciclo de Vida.

Preços e cobrança

Criar um instantâneo, que é uma cópia somente leitura de um blob, pode resultar em encargos extras de armazenamento de dados para sua conta. Ao projetar sua aplicação, esteja atento a como essas cobranças podem se acumular para minimizar custos.

Instantâneos de BLOB, como versões de BLOB, são cobrados na mesma taxa que os dados ativos. Como você é cobrado pelos snapshots depende se você define explicitamente o tier para o blob base ou para qualquer um de seus snapshots (ou versões). Para obter mais informações sobre camadas de blob, confira Camadas de acesso para dados de blob.

Se você não alterar a camada de acesso de um blob ou snapshot, será cobrado pelos blocos de dados exclusivos nesse blob, em seus snapshots e em quaisquer versões que ele possa ter. Para obter mais informações, confira Cobrança quando a camada de blob não tiver sido definida explicitamente.

Se você mudar o tier de um blob ou snapshot, você é cobrado por todo o objeto, independentemente de o blob e o snapshot estarem eventualmente no mesmo tier novamente. Para obter mais informações, consulte cobrança quando a camada de blob foi definida explicitamente.

Para contas de armazenamento que utilizam a camada inteligente, as versões e os instantâneos são cobrados pelo comprimento total do conteúdo. Para obter mais informações, consulte Otimizar custos com a camada inteligente.

Para obter mais informações sobre detalhes de cobrança para versões de blob, consultecontrole de versões de blob.

Minimizar os custos com gerenciamento de instantâneos

Para evitar custos extras, gerencie suas fotos com cuidado. Siga estas melhores práticas para ajudar a minimizar os custos do armazenamento dos seus snapshots:

• Exclua e recrie instantâneos associados a um blob sempre que você atualizar o blob, mesmo que esteja atualizando com dados idênticos, a menos que o design do aplicativo exija que você mantenha instantâneos. Ao deletar e recriar os snapshots do blob, você garante que o blob e os snapshots não diverjam.
• Se você estiver mantendo instantâneos para um blob, evite chamar métodos que substituam todo o blob ao atualizar o blob. Em vez disso, atualize o menor número possível de blocos para manter os custos baixos.

Faturamento quando você não especifica explicitamente a camada de blob

Se você não definir explicitamente o nível do blob para um blob base ou qualquer um de seus snapshots, você paga por blocos ou páginas únicas espalhados pelo blob, seus snapshots e quaisquer versões que ele possa ter. Você paga por dados que um blob e seus snapshots compartilham apenas uma vez. Quando você atualiza um blob, os dados em um blob base divergem dos dados armazenados em seus snapshots, e você paga por dados únicos por bloco ou página.

Quando você substitui um bloco dentro de um blob de blocos, depois paga 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 possui no instantâneo. Depois que você faz commit do bloco novamente, ele diverge do seu equivalente no snapshot, e você paga pelos dados dele. A mesma regra se aplica a uma página em um blob de páginas que é atualizada 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ê paga por blocos únicos, lembre-se de que atualizar um blob quando esse blob tem snapshots ou versões resulta em blocos únicos extras e cobranças extras.

Quando um blob tem instantâneos, chame operações de atualização em blob de blocos para que eles atualizem o menor número mínimo 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. 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 se acumulam para um blob de blocos e seus snapshots quando você não define explicitamente o tier do blob.

Cenário 1

No cenário 1, o blob de base não foi atualizado após a tomada do instantâneo, portanto, os encargos são incorridos apenas para os blocos exclusivos 1, 2 e 3.

Cenário 2

No cenário 2, o blob de base foi atualizado, mas o instantâneo não. O bloco 3 foi atualizado e, embora contenha os mesmos dados e a mesma ID, ele não é o mesmo que o bloco 3 no instantâneo. Como resultado, a conta é cobrada por quatro blocos.

Cenário 3

No cenário 3, o blob de base foi atualizado, mas o instantâneo não. O bloco 3 foi substituído pelo bloco 4 no blob de base, mas o instantâneo ainda reflete o bloco 3. Como resultado, a conta é cobrada por quatro blocos.

Cenário 4

No cenário 4, o blob de base foi totalmente atualizado e não contém nenhum dos seus blocos originais. Como resultado, a conta é cobrada por todos os oito blocos exclusivos.

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

Se você definir explicitamente o nível do blob para um blob, snapshot ou versão, 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 pelo tamanho total do conteúdo da versão mais antiga no nível original. Você paga por blocos únicos em quaisquer versões ou snapshots que permaneçam no tier original, como descrito em Faturamento quando o tier blob não está explicitamente definido.

Como mover um blob para uma nova camada

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

¹ Se houver outras versões ou snapshots anteriores que você não moveu do tier original, você paga com base no número de blocos únicos que eles contêm, como descrito em Faturamento quando o tier de blob não está explicitamente definido.

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

Você não pode desfazer a definição explícita do tier para 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

Quando o soft delete do blob está ativado, se você excluir ou sobrescrever um blob base para o qual você definiu explicitamente a camada, você paga pelo comprimento total do conteúdo de quaisquer versões anteriores ou instantâneos do blob excluído temporariamente. Para mais informações sobre como a versão de blob e a soft delete funcionam juntas, veja Interações com funcionalidades.

A tabela a seguir descreve o comportamento de cobrança de um blob excluído de maneira temporária se o controle de versão estiver habilitado ou desabilitado. Quando o controle de versão estiver habilitado, uma nova versão será criada quando um blob for excluído de maneira temporária. Quando o controle de versão estiver desabilitado, a exclusão temporária de um blob criará um instantâneo de exclusão temporária.

Limitações conhecidas

• Você não pode criar snapshots para blobs na camada de acesso de arquivamento.

• O suporte ao snapshot de contas do Data Lake Gen2 não aceita mais novos clientes. Em vez disso, use blob soft delete, AzCopy ou Vaulted Backup.

• Você não pode deletar um blob enquanto ele tiver snapshots ativos, a menos que inclua x-ms-delete-snapshots na chamada de exclusão.

• Replicação de objetos não replica snapshots.

• Você não pode modificar snapshots após a criação.

• Não é possível adquirir uma concessão em um instantâneo.

Monitoramento e solução de problemas

• Não consigo deletar meu blob base: o blob tem snapshots ativos. Use Delete Blob com x-ms-delete-snapshots: include para apagar ambos simultaneamente.

• Meu snapshot desapareceu depois que deletei o blob base: Excluir o blob base apaga permanentemente snapshots, a menos que o blob soft delete esteja ativado. Ative a exclusão suave para proteger contra exclusão acidental.

• Meus custos de snapshot são maiores do que o esperado: se você mudar explicitamente o nível de acesso do blob, paga pelo tamanho total do conteúdo, e não apenas pelos blocos únicos. Evite mudanças explícitas de tier em blobs com snapshots ativos sempre que possível.

• Visualização e inventário de snapshots: No portal, snapshots aparecem sob o blob no Storage Browser quando o Show blob snapshots está ativado. Para inventariar o número de snapshots e o uso de armazenamento em toda a conta, use o Armazenamento do Azure Blob Inventory e a métrica BlobCapacity no Azure Monitor.

Próximas etapas

• Controle de versão de blobs

• Criar e gerenciar um instantâneo de blob no .NET

• Faça backup dos discos não gerenciados de VM do Azure com instantâneos incrementais