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.
Enquanto um blob estiver na camada de acesso ao arquivo, esse blob é considerado offline e não pode ser lido ou modificado. Para ler ou modificar dados em um blob arquivado, você deve primeiro reidratar o blob para uma camada online, a camada quente ou fria. Há duas opções para reidratar um blob armazenado na camada de arquivamento:
Copiar um blob arquivado para uma camada online: você pode reidratar um blob arquivado copiando-o para um novo blob na camada quente ou fria com a operação Copiar Blob .
Alterar a camada de acesso de um blob arquivado para uma camada online: é possível reidratar um blob arquivado para a camada quente ou fria, alterando sua camada através da Operação Definir Camada de Blob.
Importante
Os snapshots e as versões anteriores não podem ser reidratados de volta para as camadas quente ou fria depois de serem movidos para a camada de arquivamento. Para aceder dados de um instantâneo arquivado ou de uma versão anterior, deve copiá-los para um novo blob numa camada online (Hot ou Cool) usando a operação de cópia de blobs. Não há suporte para reidratação direta de snapshots ou versões anteriores.
A reidratação de um blob da camada de arquivamento pode levar várias horas para ser concluída. A Microsoft recomenda o arquivamento de blobs maiores para um desempenho ideal durante a reidratação. A reidratação de um grande número de pequenas bolhas pode exigir tempo extra devido à sobrecarga de processamento em cada blob. Um máximo de 10 GiB por conta de armazenamento pode ser reidratado por hora com recuperação prioritária.
Para saber como reidratar um blob arquivado para uma camada online, consulte Reidratar um blob arquivado para uma camada online.
Prioridade de reidratação
Quando se reidrata um blob, é possível definir a prioridade para a operação de reidratação através do cabeçalho opcional x-ms-rehydrate-priority numa operação Definir Nível de Blob ou Copiar Blob. As opções prioritárias de reidratação incluem:
- Prioridade padrão: a solicitação de reidratação é processada na ordem em que foi recebida e pode levar até 15 horas para ser concluída para objetos com menos de 10 GB de tamanho.
- Alta prioridade: a solicitação de reidratação é priorizada em relação às solicitações de prioridade padrão e pode ser concluída em menos de uma hora para objetos com menos de 10 GB de tamanho.
Para verificar a prioridade de reidratação enquanto a operação de reidratação está em andamento, chame Obter propriedades de blob para retornar o valor do x-ms-rehydrate-priority cabeçalho. A propriedade de prioridade de reidratação retorna Standard ou High.
A prioridade padrão é a opção de reidratação padrão. Uma reidratação de alta prioridade é mais rápida, mas também custa mais do que uma reidratação de prioridade padrão. Uma reidratação de alta prioridade pode levar mais de uma hora, dependendo do tamanho da bolha e da demanda atual. A Microsoft recomenda que a reidratação de alta prioridade seja reservada para situações de emergência na restauração de dados.
Enquanto uma operação de reidratação de prioridade padrão estiver pendente, você pode atualizar a configuração de prioridade de reidratação de um blob para High para reidratar esse blob mais rapidamente. Por exemplo, se estiver a reidratar um grande número de blobs em grandes quantidades, pode especificar prioridade padrão para todos os blobs para a operação inicial e, em seguida, aumentar a prioridade para Alta para blobs individuais que precisem ser disponibilizados online mais rapidamente, até ao limite de 10 GiB por hora.
Importante
O limite de 10 GiB/hora aplica-se ao nível da conta de armazenamento, não por blob. Embora prazos como "até 15 horas" para prioridade padrão possam ser aplicados a blobs individuais em condições ideais, eles não são dimensionados linearmente para operações em massa. Os clientes que reidratam grandes volumes de dados devem esperar durações mais longas e planejar de acordo. A largura de banda é partilhada por todos os blobs que estão a ser reidratados dentro da mesma conta, e ultrapassar o limite horário pode causar restrições ou atrasos prolongados. Para obter um desempenho ideal, considere agrupar pedidos de reidratação e monitorizar a atividade ao nível da conta.
A configuração de prioridade de reidratação não pode ser reduzida de Alto para Padrão para uma operação pendente. Lembre-se de que atualizar a configuração de prioridade de reidratação pode ter um impacto na cobrança.
Para saber como definir e atualizar a configuração de prioridade de reidratação, consulte Reidratar um blob arquivado em uma camada online.
Para obter mais informações sobre as diferenças de preços entre solicitações de reidratação de prioridade padrão e de alta prioridade, consulte Preços para o Armazenamento de Blobs do Azure.
Copiar um blob arquivado para uma camada online
A primeira opção para mover um blob da camada de arquivo para uma camada online é copiar o blob arquivado para um novo blob de destino que esteja na camada quente, fria ou fria. Você pode usar a operação Copiar Blob para copiar o blob. Quando você copia um blob arquivado para um novo blob em uma camada online, o blob de origem permanece inalterado na camada de arquivamento.
Você deve copiar o blob arquivado para um novo blob com um nome diferente ou para um contêiner diferente. Não é possível substituir o blob de origem copiando para o mesmo blob.
Ao copiar um blob da camada de arquivo para uma camada online, você pode evitar a taxa de exclusão antecipada que é avaliada se você alterar a camada de um blob da camada de arquivamento antes que o período de 180 dias necessário expire. Para obter mais informações, consulte Nível de Acesso ao Arquivo.
Essa opção também pode fazer sentido se houver uma política de gerenciamento do ciclo de vida em vigor para a conta de armazenamento e a daysAfterLastTierChangeGreaterThan condição não for adicionada a cada tierToArchive ação da política. Nesse caso, reidratar um blob com a operação Definir Camada de Blob pode resultar em um cenário em que a política de ciclo de vida move o blob de volta para a camada de arquivamento após a reidratação, porque a data da última modificação está além do limite estabelecido pela política. Uma operação de cópia deixa o blob de origem na camada de arquivo e cria um novo blob com um nome diferente e um novo tempo de última modificação, portanto, não há risco de que o blob reidratado seja movido de volta para a camada de arquivo pela política de ciclo de vida.
A cópia de um blob da camada de arquivo pode levar horas para ser concluída, dependendo da prioridade de reidratação selecionada. Nos bastidores, uma operação de cópia de blob lê o seu blob de origem arquivado para criar um novo blob online na camada de destino selecionada. O novo blob pode estar visível ao listar os blobs no contentor principal antes que a operação de reidratação seja concluída, mas a sua camada será definida como 'arquivo'. Os dados não estarão disponíveis até que a operação de leitura do blob de origem na camada de arquivo seja concluída e o conteúdo do blob tenha sido gravado no novo blob de destino numa camada online. O novo blob é uma cópia independente, portanto, modificá-lo ou excluí-lo não afeta o blob de origem na camada de arquivamento.
Para saber como reidratar um blob copiando-o para uma camada online, consulte Reidratar um blob com uma operação de cópia.
Importante
Não exclua o blob de origem até que a reidratação tenha sido concluída com êxito. Se o blob de origem for excluído, o blob de destino pode não concluir a cópia. Você pode manipular o evento que é gerado quando a operação de cópia é concluída para saber quando é seguro excluir o blob de origem. Para obter mais informações, consulte Manipular um evento durante a reidratação de blobs.
Antes da versão de serviço 2021-02-12, a reidratação de um blob arquivado copiando-o para uma camada de destino online era suportada apenas na mesma conta de armazenamento. A partir da versão 2021-02-12 e posterior, você também pode reidratar copiando o blob para uma conta de armazenamento diferente na mesma região. A partir da versão de serviço 2021-02-12, você pode reidratar um blob arquivado copiando-o para uma conta de armazenamento diferente, desde que a conta de destino esteja na mesma região da conta de origem. A reidratação entre contas de armazenamento permite segregar os dados de produção dos dados de backup, mantendo-os em contas separadas. Isolar os dados arquivados em uma conta separada também pode ajudar a reduzir os custos da reidratação não intencional.
O blob de destino para a operação de cópia deve estar em uma camada online (quente ou fria). Não é possível copiar um blob arquivado para um blob de destino que também esteja na camada de arquivamento.
A tabela a seguir mostra o comportamento de uma operação de cópia de blob, dependendo das camadas do blob de origem e destino.
| Fonte de camada quente | Fonte de nível fixe | Origem da camada de arquivamento | |
|---|---|---|---|
| Destino de nível superior | Suportado | Suportado | Suportado em contas na mesma região com a versão 2021-02-12 e posterior. Suportado na mesma conta de armazenamento apenas para versões anteriores. Requer reidratação blob. |
| Destino de moda | Suportado | Suportado | Suportado em contas na mesma região com a versão 2021-02-12 e posterior. Suportado na mesma conta de armazenamento apenas para versões anteriores. Requer reidratação blob. |
| Destino da camada de arquivamento | Suportado | Suportado | Não suportado |
Reidratar a partir de uma região secundária
Se configuraste a tua conta de armazenamento para usar armazenamento com redundância geográfica de acesso de leitura (RA-GRS), podes usar a operação Copiar Blob para reidratar blobs na região secundária para outra conta de armazenamento localizada nessa mesma região. Consulte Reidratar a partir de uma região secundária.
Para saber mais sobre como obter acesso de leitura a regiões secundárias, consulte Acesso de leitura a dados na região secundária.
Alterar a camada de acesso de um blob para uma camada online
A segunda opção para reidratar um blob da camada de arquivo para uma camada online é alterar a camada do blob chamando set Blob Tier. Com essa operação, você pode alterar a camada do blob arquivado para quente ou frio.
Depois que uma solicitação Definir Camada de Blob for iniciada, ela não poderá ser cancelada. Durante a operação de reidratação, a configuração da camada de acesso do blob continua a aparecer como arquivada até que o processo de reidratação seja concluído. Quando a operação de reidratação é concluída, a propriedade da camada de acesso do blob é atualizada para refletir a nova camada.
Para saber como reidratar um blob alterando sua camada para uma camada online, consulte Reidratar um blob alterando sua camada.
Atenção
Alterar a camada de um blob não afeta sua hora da última modificação. Se houver uma política de gerenciamento do ciclo de vida em vigor para a conta de armazenamento, a reidratação de um blob com Definir Nível de Blob pode resultar em um cenário em que a política de ciclo de vida move o blob de volta para a camada de arquivamento após a reidratação, porque o último tempo modificado está além do limite definido para a política.
Para evitar esse cenário, adicione a daysAfterLastTierChangeGreaterThan condição à tierToArchive ação da política. Como alternativa, você pode reidratar o blob arquivado copiando-o, conforme descrito na seção Copiar um blob arquivado para uma camada online . A execução de uma operação de cópia cria uma nova instância do blob com uma hora atualizada da última modificação, portanto, não acionará a política de gerenciamento do ciclo de vida.
Verificar o estado de uma operação de reidratação de bolha
Durante a operação de reidratação do blob, você pode chamar a operação Obter propriedades do blob para verificar seu status. Para saber como verificar o estado de uma operação de reidratação, consulte Verificar o estado de uma operação de reidratação.
Manipular um evento na reidratação de blob
A reidratação de um blob arquivado pode levar até 15 horas, e é ineficiente pesquisar repetidamente Get Blob Properties para determinar se a reidratação está completa. A Microsoft recomenda que você use a Grade de Eventos do Azure para capturar o evento que é acionado quando a reidratação é concluída para melhor desempenho e otimização de custos.
O Azure Event Grid levanta o evento Microsoft.Storage.BlobTierChanged na conclusão da reidratação do blob:
- O
Microsoft.Storage.BlobTierChangedevento é ativado quando o nível de um blob é alterado. No contexto da reidratação de blob, este evento é acionado quando a camada de acesso de um blob de destino é alterada com êxito da camada de arquivo para uma camada online (camada quente, morna ou fria). Podes usar a operação Set Blob Tier para alterar o nível de acesso de um blob arquivado.
Quando utilizas a operação Copiar Blob para copiar um blob do nível Archive para um novo blob de destino num nível online (nível quente, intermédio ou frio) para reidratação:
Um
Microsoft.Storage.BlobCreatedevento é ativado assim que a operação de cópia começa, com o nível do blob definido como Arquivar.Depois de o blob ser copiado com sucesso e reidratado para o tier online alvo, é lançado um
Microsoft.Storage.BlobTierChangedevento, indicando a mudança de tier do Archive para o tier online especificado.
Para saber como capturar um evento na reidratação e enviá-lo para um manipulador de eventos do Azure Function, consulte Executar uma função do Azure em resposta a um evento de reidratação de blob.
Para mais informações sobre o manuseio de eventos de Armazenamento de Blob, consulte Reagindo a eventos no Armazenamento de Blob do Azure e Armazenamento de Blob do Azure como origem de Event Grid.
Preços e faturação
Uma operação de reidratação com Set Blob Tier é cobrada por transações de leitura de dados e pelo volume de recuperação dos dados. Uma reidratação de alta prioridade tem custos de operação e recuperação de dados mais altos em comparação com a prioridade padrão. Reidratação de alta prioridade aparece como um item separado na sua fatura. Se uma solicitação de alta prioridade para retornar um blob arquivado com menos de 10 GB de tamanho demorar mais de cinco horas, não será cobrada a taxa de recuperação de alta prioridade. No entanto, continuam a aplicar-se taxas de recuperação normais. Para obter uma estimativa de custo de exemplo, consulte Estimativa de custo: mover dados para fora do armazenamento de arquivamento.
A cópia de um blob arquivado para uma camada online com o Blob de Cópia é cobrada pelas transações de leitura de dados e pelo tamanho da recuperação de dados. A criação do blob de destino em uma camada online é cobrada por transações de gravação de dados. As taxas de exclusão antecipada não se aplicam quando você copia para um blob online porque o blob de origem permanece inalterado na camada de arquivamento. Aplicam-se taxas de recuperação de alta prioridade se selecionadas. Para obter uma estimativa, veja Estimativa de custo: recuperar dados do armazenamento de arquivo para análise.
Os blobs na camada de arquivamento devem ser armazenados por um período mínimo de 180 dias. Excluir ou alterar a camada de um blob arquivado antes do período de 180 dias incorre em uma taxa de exclusão antecipada. Por exemplo, se um blob for movido para a camada de arquivamento e, em seguida, eliminado ou movido para a camada quente após 45 dias, será cobrada uma taxa de exclusão antecipada equivalente a 135 (180 menos 45) dias de armazenamento desse blob na camada de arquivamento. Para obter mais informações, consulte Nível de Acesso ao Arquivo.
Para obter mais informações sobre preços para blobs de bloco e reidratação de dados, consulte Preços do Armazenamento do Azure. Para obter mais informações sobre taxas de transferência de dados de saída, consulte Detalhes de preços de transferências de dados.