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.
Um snapshot é uma cópia apenas de leitura de um blob tirada num momento específico. Não precisas de ativar a funcionalidade de snapshots de blob. Em vez disso, crie instantâneos sob demanda usando a Snapshot Blob operação. Para mais informações, consulte Operação de blob de instantâneo. Pode automatizar a criação de instantâneos usando scripts personalizados para capturar cópias de blobs num momento específico de forma agendada ou antes ou depois de operações específicas.
Configuração recomendada de proteção de dados
Os snapshots de blob são 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.
Instantâneos vs. versões
Um snapshot é semelhante a uma versão blob, mas as duas diferem na forma como são criadas e para o que são mais adequadas. 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. 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.
Use o controlo de versões quando quiser proteção automática e contínua contra sobrescritas e eliminações acidentais ou maliciosas. Utilize instantâneos quando quiser cópias intencionais de um determinado momento, como um ponto de verificação conhecido antes de uma atualização planeada, em vez de uma captura de todas as alterações.
Nota
Embora possas aproximar o comportamento de versionamento usando snapshots, a Microsoft recomenda o blob versioning para proteção automática contra sobrescrição e eliminação em contas FNS. Os snapshots são mais adequados para capturas deliberadas num determinado momento do que para proteção que capta todas as alterações. Para mais informações, consulte Blob versioning.
Como funcionam os instantâneos
Um snapshot de um blob é idêntico ao seu blob base, exceto que o URI do blob tem um valor DateTime adicionado ao URI do blob para indicar o momento em que o snapshot foi tirado. Por exemplo, se o URI de um blob de página for http://storagesample.core.blob.windows.net/mydrives/myvhd, o URI de um 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 do blob são copiadas para o instantâneo com os mesmos valores. Os metadados do blob de base também são copiados para o snapshot, a menos que você especifique metadados separados para o snapshot ao criá-lo. Depois de criar um instantâneo, você pode lê-lo, copiá-lo ou excluí-lo, mas não pode modificá-lo. Quaisquer concessões associadas ao blob base não afetam o snapshot. Não é possível adquirir uma concessão em um instantâneo.
Um blob pode ter qualquer número de instantâneos. Os snapshots persistem até serem explicitamente eliminados, seja de forma independente ou como parte de uma operação de Eliminar Blob para o blob base. Podes criar um instantâneo de um blob no nível quente, frio ou tépido. Não se pode criar um snapshot de um blob arquivado.
Importante
Ter um grande número de instantâneos por blob pode aumentar a latência nas operações de listagem de blob. A Microsoft recomenda manter menos de 1.000 snapshots por blob. Pode usar a gestão do ciclo de vida para eliminar automaticamente snapshots antigos. Para mais informações sobre gestão do ciclo de vida, consulte Otimizar custos automatizando os níveis de acesso ao Armazenamento de Blobs do Azure.
Os snapshots são especialmente úteis para tipos e operações de blob que não são capturados pelo controlo de versões de blobs. Como algumas operações de escrita, como Put Page (blobs de página) e Append Block (blobs de anexação), não criam versões de blob mesmo quando a versionação está ativada, os snapshots fornecem uma forma de capturar o estado pontual de um blob ao usar estas APIs. Por exemplo, um ficheiro VHD armazena a informação e o estado atuais de um disco de uma VM. Pode desligar um disco dentro da VM ou desligar a VM, tirar um instantâneo do seu ficheiro VHD e, mais tarde, usar esse instantâneo para recuperar o ficheiro VHD nesse momento e recriar a VM.
O diagrama seguinte mostra como os snapshots são criados e como um snapshot pode ser promovido para ser o blob atual:
Gerir e restaurar snapshots
Pode criar, listar e eliminar snapshots. Também podes usar um snapshot para restaurar um blob base a um estado anterior. As secções seguintes descrevem cada operação e as ferramentas correspondentes.
Restaurar um blob a partir de um instantâneo
Como não podes modificar um snapshot, restauras um blob base copiando um snapshot por cima. Chame a operação Copy Blob e especifique o URI do snapshot como fonte de cópia. Este processo promove o estado do snapshot para se tornar o blob base atual, preservando os snapshots existentes do blob.
Listar instantâneos
Pode enumerar os snapshots associados ao blob base para acompanhar os seus snapshots atuais usando a operação List Blobs e especificando o valor snapshots no parâmetro include. Por defeito, um pedido para listar blobs não devolve snapshots. Defina include=snapshots para devolver todos os snapshots de cada blob juntamente com o blob base. Para mais informações, consulte Listar Blobs. 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 os seus snapshots, definindo o includeSnapshots campo como true na definição da regra de inventário. Para mais informações, consulte Blob Inventary.
Excluir instantâneos
Deve apagar explicitamente um snapshot. Para eliminar um snapshot individual, chame a operação Delete Blob e especifique o valor DateTime do snapshot no parâmetro de consulta do snapshot.
Não podes eliminar um blob base enquanto ele tiver snapshots ativos. Para eliminar um blob base e todos os seus snapshots juntos, chame Delete Blob com o x-ms-delete-snapshots cabeçalho definido para include. Para eliminar apenas os snapshots e manter o blob base, defina o cabeçalho para only.
Gerir snapshots com ferramentas
Pode gerir snapshots usando o portal, CLI do Azure e Azure PowerShell.
Para criar um instantâneo de um blob usando o portal do Azure, siga estes passos:
- No portal do Azure, navegue para a sua conta de armazenamento.
- Em Armazenamento de Dados, encontre a opção Containers e depois selecione o contentor que contém o blob.
- Seleciona o blob que queres fazer snapshot.
- No separador Visão Geral do blob, selecione Criar snapshot.
- Para visualizar os snapshots do blob, selecione o separador Snapshots . O separador lista cada snapshot juntamente com a data e hora em que foi capturado.
Suporte de funcionalidades
Esta funcionalidade não está ativada para contas Data Lake Storage Gen2. Além disso, o protocolo Network File System (NFS) 3.0, ou o SSH File Transfer Protocol (SFTP) poderá afetar o suporte a esta funcionalidade. Se ativar alguma destas funcionalidades, consulte o suporte à funcionalidade Armazenamento de Blobs nas contas do Armazenamento do Azure para avaliar o suporte a esta funcionalidade. Considere mecanismos alternativos. Exemplos incluem Soft delete para blobs, AzCopy e Vaulted Backup.
Interações entre funcionalidades
Versioning
Quando ativas a versionação, os snapshots são normalmente redundantes para blobs de blocos. Se ativares tanto o controlo de versões como os snapshots ao mesmo tempo, tirar um snapshot cria tanto um snapshot como uma nova versão. Este processo aumenta o número de objetos armazenados sem adicionar proteção. Para obter mais informações, consulte Versionamento de Blob.
Eliminação suave
A eliminação suave aplica-se a snapshots: quando elimina uma snapshot, esta fica eliminada de forma recuperável. Podes restaurá-lo durante o período de retenção usando o Undelete Blob. Além disso, a forma como crias e faturas pelos snapshots varia consoante se o controlo de versões está ativado. Quando o versionamento está desativado, sobrescrever um blob cria um instantâneo de eliminação suave. Quando o controlo de versões está ativado, cria-se uma nova versão em vez disso. Se definires explicitamente o escalão num blob de base, pagas o comprimento total do conteúdo por quaisquer versões anteriores ou instantâneos do blob eliminado temporariamente. Para detalhes sobre este comportamento de faturação, consulte a secção de Preços e faturação. Para mais informações sobre soft delete, veja Blob Soft Delete.
Replicação de objetos
Não se podem replicar snapshots. Apenas o blob base é replicado. Para mais informações, consulte Replicação de Objetos.
Gestão do ciclo de vida
A gestão do ciclo de vida pode direcionar e eliminar snapshots utilizando o subtipo de snapshot nas regras de política. Para mais informações, consulte Gestão do Ciclo de Vida.
Preços e faturação
Criar um snapshot, que é uma cópia somente leitura de um blob, pode resultar em cobranças extras de armazenamento de dados para a sua conta. Ao desenhar a sua aplicação, esteja atento a como estes encargos podem acumular-se para minimizar custos.
Os instantâneos de blob, tal como as versões de blob, são cobrados a uma taxa idêntica à dos dados ativos. A forma como és faturado pelos snapshots depende de definires explicitamente o tier para o blob base ou para qualquer um dos seus snapshots (ou versões). Para mais informações sobre camadas de blob, consulte Camadas de acesso para dados de blob.
Se não alterares o nível de um blob ou snapshot, és cobrado por blocos únicos de dados nesse blob, os seus snapshots e quaisquer versões que possa ter. Para mais informações, veja Faturamento quando a camada de blob não foi explicitamente definida.
Se mudares o tier de um blob ou snapshot, és faturado por todo o objeto, independentemente de o blob e o snapshot estarem novamente no mesmo tier. Para obter mais informações, consulte Faturamento quando há definição explícita da camada de blob.
Para contas de armazenamento que utilizam o "smart tier", as versões e snapshots são cobrados pelo tamanho completo do conteúdo. Para mais informações, consulte Otimização de custos com a camada inteligente.
Para mais informações sobre os detalhes de faturação das versões de blob, consulte Versionamento de Blob.
Minimize os custos com o gerenciamento de snapshots
Para evitar custos extra, gere cuidadosamente os seus snapshots. Siga estas melhores práticas para ajudar a minimizar os custos incorridos pelo armazenamento dos seus snapshots:
- Exclua e recrie instantâneos associados a um blob sempre que atualizar o blob, mesmo que esteja a atualizá-lo com dados idênticos, a menos que o design da aplicação exija que mantenha instantâneos. Ao eliminar e recriar os snapshots do blob, garante que o blob e os snapshots não divirjam.
- Se você estiver mantendo instantâneos para um blob, evite chamar métodos que substituam o blob inteiro quando você atualizar o blob. Em vez disso, atualize o menor número possível de blocos para manter os custos baixos.
Faturação quando não defines explicitamente o nível de blob
Se não definires explicitamente o nível do blob para um blob base ou para qualquer um dos seus snapshots, pagas por blocos ou páginas únicas em todo o blob, nos seus snapshots e em quaisquer versões que possa ter. Paga-se por dados que um blob e os seus snapshots partilham apenas uma vez. Quando atualizas um blob, os dados num blob base divergem dos dados armazenados nos seus snapshots, e pagas por dados únicos por bloco ou página.
Quando substitues um bloco dentro de um blob de blocos, depois pagas 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 tem no snapshot. Depois de fizeres commit do bloco novamente, ele diverge do seu equivalente no snapshot, e pagas pelos seus dados. A mesma regra aplica-se a uma página num blob de página que é atualizada 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 pagas por blocos únicos, lembra-te de que atualizar um blob quando esse blob tem instantâneos ou versões resulta em blocos únicos adicionais e custos adicionais.
Quando um blob tem instantâneos, deve-se chamar operações de atualização em blobs de bloco para que 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 os seus snapshots quando não se define explicitamente o tier do blob.
Cenário 1
No cenário 1, o blob base não foi atualizado depois que o instantâneo foi tirado, portanto, as cobranças são incorridas apenas para os blocos exclusivos 1, 2 e 3.
Cenário 2
No cenário 2, o blob base foi atualizado, mas o instantâneo não. O bloco 3 foi atualizado e, embora contenha os mesmos dados e a mesma ID, não é o mesmo que o bloco 3 no instantâneo. Como resultado, a conta é faturada por quatro blocos.
Cenário 3
No cenário 3, o blob base foi atualizado, mas o instantâneo não. O bloco 3 foi substituído pelo bloco 4 no blob base, mas o instantâneo ainda reflete o bloco 3. Como resultado, a conta é faturada por quatro blocos.
Cenário 4
No cenário 4, o blob base foi completamente atualizado e não contém nenhum de seus blocos originais. Como resultado, a conta é cobrada por todos os oito blocos exclusivos.
Gorjeta
Para manter os custos baixos, evite chamar métodos que sobrescrevem todo o blob. Em vez disso, atualize os blocos individuais.
Faturação quando defines explicitamente o nível do blob
Se definires explicitamente o nível do blob para um blob, snapshot ou versão, 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. Paga-se por blocos únicos em quaisquer versões ou snapshots que permaneçam no tier original, como descrito na Faturação quando o tier blob 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 snapshot quando o move para um novo nível.
| Quando defines explicitamente o nível do blob em... | Então você é cobrado por... |
|---|---|
| Um blob de base com um instantâneo | O blob de base na nova camada e o instantâneo mais antigo na camada original, além de quaisquer blocos exclusivos em outros instantâneos.1 |
| Um blob de base com uma versão anterior e um instantâneo | O blob base no novo nível, a versão mais antiga no nível original e o snapshot mais antigo no tier original, mais quaisquer blocos únicos noutras versões ou snapshots. 1 |
| Um instantâneo | O snapshot na nova camada e o blob base na camada original, além de quaisquer blocos exclusivos em outros snapshots.1 |
1 Se houver outras versões ou instantâneos anteriores que não foram movidos do respetivo tier original, paga com base no número de blocos únicos que contêm, como descrito na Faturação quando o tier de blob não está explicitamente definido.
O diagrama seguinte ilustra como os objetos são faturados quando se move um blob com snapshots para um nível 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 a camada de um blob, versão ou 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 o soft delete do blob está ativado, se apagar ou sobrescrever um blob de base para o qual definiu explicitamente o nível, paga pelo comprimento total do conteúdo de quaisquer versões anteriores ou instantâneos do blob eliminado temporariamente. 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.
A tabela a seguir descreve o comportamento de cobrança de um blob excluído suavemente, dependendo se o controle de versão está habilitado ou desabilitado. Quando o controle de versão está habilitado, uma nova versão é criada quando um blob é excluído suavemente. Quando o controlo de versão está desativado, a eliminação temporária de um blob cria um instantâneo de eliminação temporária.
| Quando você substitui um blob base com sua camada explicitamente definida... | Então você é cobrado por... |
|---|---|
| Se a exclusão suave de blobs e o controlo de versões estiverem ambos ativados | Todas as versões existentes com conteúdo completo, independentemente do nível. |
| Se o blob soft delete estiver habilitado, mas o controle de versão estiver desabilitado | Todos os snapshots de exclusão suave existentes em todo o comprimento do conteúdo, independentemente da camada. |
Limitações conhecidas
Não podes criar snapshots para blobs no escalão de acesso de arquivo.
O suporte ao snapshot de contas Data Lake Gen2 já não aceita novos clientes. Em vez disso, usa blob soft delete, AzCopy ou Vaulted Backup.
Não podes eliminar um blob enquanto tiver snapshots ativos, a menos que incluas
x-ms-delete-snapshotsna chamada de eliminação.A replicação de objetos não replica snapshots.
Não podes modificar snapshots após a criação.
Não é possível adquirir uma concessão em um instantâneo.
Monitorizar e resolver problemas
Não consigo apagar o meu blob base: o blob tem snapshots ativos. Utilize Delete Blob com
x-ms-delete-snapshots: includepara apagar ambos simultaneamente.O meu snapshot desapareceu depois de apagar o blob base: Eliminar o blob base apaga permanentemente snapshots, a menos que o blob soft delete esteja ativado. Ativar a eliminação suave para proteger contra eliminação acidental.
Os meus custos de snapshot são mais altos do que o esperado: Se mudares explicitamente o nível de acesso do blob, pagas pelo comprimento total do conteúdo em vez de apenas blocos únicos. Evite alterações explícitas de níveis em blobs com snapshots ativos sempre que possível.
Visualização e inventariação de snapshots: No portal, os snapshots aparecem sob o blob no Storage Browser quando está ativado o Mostrar snapshots de blob . Para inventariar a contagem de snapshots e o uso de armazenamento numa conta, use o Armazenamento do Azure Blob Inventory e a métrica BlobCapacity no Azure Monitor.