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.
A restauração num momento no tempo protege contra eliminação ou corrupção acidental, permitindo restaurar os dados do blob de bloco para um estado anterior. Esta funcionalidade é útil em cenários em que um utilizador ou uma aplicação apaga acidentalmente dados ou quando um erro de aplicação corrompe dados. A restauração para um ponto no tempo também permite cenários de teste que exigem a reversão de um conjunto de dados para um estado conhecido antes de executar testes adicionais.
A restauração em ponto no tempo suporta contas de armazenamento v2 de uso geral apenas no nível padrão de desempenho. Só podes restaurar apenas dados nos níveis de acesso quente e frio usando o restauro para um ponto anterior no tempo. O restauro para um ponto no tempo não é atualmente suportado em contas que têm um espaço de nomes hierárquico.
Para saber como habilitar a restauração point-in-time para uma conta de armazenamento, consulte Executar uma restauração point-in-time em dados de blob de bloco.
Configuração recomendada de proteção de dados
A restauração pontual faz parte de uma estratégia abrangente de proteção de dados e baseia-se em três outras funcionalidades que deve ativar primeiro: eliminação suave de blobs, versionamento de blob e fluxo de alterações. A restauração pontual adiciona recuperação a nível de contentor por cima destas funcionalidades, permitindo reverter um conjunto de blobs de blocos para um estado anterior em vez de restaurar objetos um de cada vez.
A restauração em ponto no tempo protege contra corrupção de dados e eliminação acidental de blobs, mas não protege contra a eliminação de um contentor ou conta de armazenamento. Para proteção contra a eliminação de contentores, ative a Eliminação Suave ao Nível do Contentor. Para proteção ao nível da conta, ative o Azure Backup. Para saber mais sobre as recomendações do Azure para proteção de dados, consulte Visão Geral da Proteção de Dados.
Como funciona a restauração para um ponto no tempo
Para permitir a restauração pontual, crie uma política de gestão para a conta de armazenamento e especifique um período de retenção. Durante o período de retenção, pode restaurar blobs de bloco do estado atual para um estado num momento anterior.
Para iniciar uma restauração point-in-time, chame a operação Restaurar intervalos de Blob e especifique um ponto de restauração no horário UTC. Pode especificar intervalos lexicográficos de nomes de contêiner e blob para restaurar ou omitir o intervalo para restaurar todos os contêineres na conta de armazenamento. Cada operação de restauração suporta até 10 intervalos lexicográficos.
O Armazenamento do Azure analisa todas as alterações feitas aos blobs especificados entre o ponto de restauro solicitado, especificado em tempo UTC, e o momento presente. A operação de restauração é atómica, portanto, ou é concluída com êxito, restaurando completamente todas as alterações, ou falha. Se houver blobs que não possam ser restaurados, a operação falha e as operações de leitura e escrita nos contentores afetados retomam.
O diagrama a seguir mostra como a restauração point-in-time funciona. Um ou mais contentores ou intervalos de blobs são restaurados para o estado em que se encontravam há n dias, em que n é menor ou igual ao período de retenção definido para o restauro point-in-time. O efeito é reverter operações de gravação e exclusão que aconteceram durante o período de retenção.
Só pode executar uma operação de restauro numa conta de armazenamento de cada vez. Não podes cancelar uma operação de restauro depois de estar em andamento, mas podes realizar uma segunda operação de restauro para desfazer a primeira.
A operação Restore Blob Ranges retorna uma ID de restauração que identifica exclusivamente a operação. Para verificar o status de uma restauração point-in-time, chame a operação Get Restore Status com o ID de restauração retornado da operação Restore Blob Ranges .
Importante
Quando executar uma operação de restauração, o Armazenamento do Azure bloqueia as operações de dados nos blobs nos intervalos que estão a ser restaurados durante a operação. As operações de leitura, gravação e exclusão estão bloqueadas no local principal. Por esta razão, operações como listar contentores no portal Azure podem não funcionar como esperado enquanto a operação de restauro está em curso.
Se a conta de armazenamento for geo-replicada, as operações de leitura a partir da localização secundária podem prosseguir durante a operação de restauro.
Atenção
A restauração point-in-time oferece suporte à restauração contra operações que atuaram apenas em blobs de bloco. Não podes restaurar operações que atuaram sobre contentores. Por exemplo, se apagar um contentor da conta de armazenamento ao invocar a operação Eliminar Contentor, não pode restaurar esse contentor utilizando uma operação de restauro para um ponto anterior no tempo. Em vez de apagar um contentor inteiro, apaga os blobs individuais se quiseres restaurá-los mais tarde.
Pré-requisitos e configuração
Para usar o restauro para um ponto anterior no tempo, ative as seguintes funcionalidades do Armazenamento do Azure antes de ativar o restauro para um ponto anterior no tempo:
Para saber mais sobre as recomendações da Microsoft para proteção de dados, consulte Visão geral da proteção de dados.
Atenção
Depois de ativar a versão de blob para uma conta de armazenamento, cada operação de escrita num blob nessa conta cria 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 obter mais informações sobre o gerenciamento do ciclo de vida, consulte Otimizar custos automatizando as camadas de acesso do Armazenamento de Blobs do Azure.
Período de retenção para restauro num ponto anterior no tempo
Quando ativar a restauração pontual para uma conta de armazenamento, especifique um período de retenção. Podes restaurar blobs de blocos na tua conta de armazenamento durante o período de retenção.
O período de retenção começa alguns minutos depois de ativar a recuperação para um ponto no tempo. Não podes restaurar os blobs a um estado antes do início do período de retenção. Por exemplo, se ativou a restauração point-in-time em 1 de maio com uma retenção de 30 dias, em 15 de maio poderá restaurar até um máximo de 15 dias no passado. Em 1 de junho, pode restaurar dados com antiguidade entre 1 e 30 dias.
O período de retenção para restauração point-in-time deve ser pelo menos um dia menor do que o período de retenção especificado para exclusão suave. Por exemplo, se o período de retenção de eliminação suave for definido para sete dias, então o período de retenção de restauro pontual pode ser entre 1 e 6 dias.
Nota
O período de retenção especificado para a restauração point-in-time não tem efeito sobre a retenção de versões de blob. As versões de Blob são mantidas até serem explicitamente excluídas. Para otimizar os custos excluindo ou movendo para camadas versões mais antigas, crie uma política de gestão do ciclo de vida. Para obter mais informações, consulte Otimizar custos gerindo automaticamente o ciclo de vida dos dados.
O tempo necessário para restaurar um conjunto de dados baseia-se no número de operações de gravação e eliminação efetuadas durante o período de recuperação. Por exemplo, uma conta com 1 milhão de blobs com 3.000 blobs adicionados por dia e 1.000 blobs eliminados por dia requer cerca de duas horas para restaurar para um ponto no tempo de há 30 dias. Um período de retenção e restauração de mais de 90 dias no passado não é recomendado para uma conta com esta taxa de alteração.
Permissões para restauração point-in-time
Para iniciar uma operação de restauro, um cliente deve ter permissões de escrita para todos os contentores na conta de armazenamento. Para conceder permissões para autorizar uma operação de restauro usando o Microsoft Entra ID, atribua o papel Storage Account Contributor ao principal de segurança ao nível da conta de armazenamento, grupo de recursos ou subscrição.
Suporte a funcionalidades
O suporte para esse recurso pode ser afetado pela habilitação do Data Lake Storage Gen2, do protocolo NFS (Network File System) 3.0 ou do SSH File Transfer Protocol (SFTP). Se você habilitou qualquer um desses recursos, consulte suporte à funcionalidade Armazenamento de Blobs em contas do Armazenamento do Azure para avaliar o suporte para esse recurso.
Interações entre funcionalidades
A restauração em determinado momento depende de várias outras funcionalidades de proteção de dados e interage com elas de formas que podem complicar a restauração. Revise as informações seguintes antes de ativar a restauração num ponto no tempo.
Controlo de versões de blobs, soft delete e feed de alterações (pré-requisitos obrigatórios): Deve ativar as três funcionalidades antes de poder ativar o restauro para um ponto no tempo. Este requisito tem efeitos a jusante: cada operação de escrita cria uma nova versão do blob, o que pode aumentar os custos de armazenamento porque os blobs versionados persistem até serem explicitamente eliminados. O período de retenção do restauro para um ponto no tempo tem de ser definido para, pelo menos, menos um dia do que os períodos de retenção de soft delete e change feed. A faturação de um restauro baseia-se na quantidade de dados do feed de alterações processados.
Políticas de imutabilidade: Pode iniciar uma restauração numa conta com políticas de imutabilidade, mas a operação de restauro não modifica blobs protegidos por uma política. Como resultado, os dados restaurados podem não refletir um estado consistente para o momento solicitado.
Snapshots: Uma operação de restauro não cria nem apaga snapshots. Apenas o blob base (versão atual) é restaurado ao seu estado anterior.
Failover gerido pelo cliente: Realizar um failover gerido pelo cliente redefine o ponto de restauro mais cedo possível para a conta de armazenamento. Após um failover, não se pode restaurar para um ponto anterior ao failover. Para mais detalhes, veja Inconsistências do restauro para um ponto no tempo.
Limitações conhecidas
A restauração point-in-time para blobs de bloco tem as seguintes limitações e problemas conhecidos:
Só pode restaurar blobs de bloco numa conta de armazenamento v2 padrão de uso geral como parte de uma operação de restauro em determinado momento. Não podes restaurar blobs de anexação, blobs de página ou blobs de blocos premium.
Se apagares um contentor durante o período de retenção, a operação de restauro para um ponto no tempo não restaura esse contentor. Se você tentar restaurar um intervalo de blobs que inclua blobs em um contêiner excluído, a operação de restauração point-in-time falhará. Para saber mais sobre como proteger contêineres contra exclusão, consulte Exclusão suave para contêineres.
Se um blob se mover entre os níveis quente e frio no período entre o momento presente e o ponto de restauro, a operação de restauro restaura o blob ao seu tier anterior.
Não há suporte para a restauração de blobs de bloco na camada de arquivamento. Por exemplo, se um blob na camada quente tiver sido movido para a camada de arquivo morto há dois dias e uma operação de restauro restaurar para um ponto no tempo de há três dias, o blob não será restaurado para a camada quente. Para restaurar um blob arquivado, primeiro mova-o para fora da camada de arquivamento. Para obter mais informações, consulte Visão geral da reidratação de blob da camada de arquivamento.
Não há suporte para operações de restauração parcial. Portanto, se um contêiner tiver blobs arquivados, toda a operação de restauração falhará porque a restauração de blobs de bloco na camada de arquivamento não é suportada.
Um bloco que carrega usando Put Block ou Put Block from URL, mas sobre o qual não efetua commit usando Put Block List, não faz parte de um blob e, por isso, não é restaurado como parte de uma operação de restauro.
Se incluir um blob com um arrendamento ativo no intervalo a restaurar, e se a versão atual do blob arrendado for diferente da versão anterior no carimbo temporal fornecido para o PITR, a operação de restauro falha atomicamente. Interrompa quaisquer leases ativos antes de iniciar a operação de restauração.
A restauração point-in-time não tem suporte para namespaces hierárquicos ou operações por meio do Armazenamento Azure Data Lake.
A restauração point-in-time não é suportada quando a propriedade AllowedCopyScope da conta de armazenamento está definida para restringir o escopo da cópia ao mesmo locatário do Microsoft Entra ou rede virtual. Para obter mais informações, consulte Sobre o escopo permitido para operações de cópia (visualização).
A restauração num dado momento não é suportada quando a imutabilidade ao nível da versão está ativada numa conta de armazenamento ou num contentor numa conta. Para obter mais informações sobre imutabilidade no nível da versão, consulte Configurar políticas de imutabilidade para versões de blob.
Resolução de problemas e monitorização
Não consigo ativar o PITR: o PITR requer pré-requisitos de soft delete para blobs, versionamento de blobs e change feed. Verifique se estes pré-requisitos estão ativados.
Não consigo restaurar ao meu tempo alvo: o PITR exige que o carimbo temporal do alvo esteja dentro da janela de retenção configurada. Verifica se o tempo de restauração está dentro do período de retenção.
A minha restauração do PITR está a demorar demasiado: a duração do PITR depende do volume de dados e do âmbito da restauração. Verifica se o âmbito está correto (contentor ou conjunto de objetos). Atualmente, não há forma de monitorizar o progresso da restauração do PITR. Se uma restauração parecer parada ou demorar mais do que espera, abra um pedido de suporte no portal Azure.
PITR concluído mas os meus dados continuam em falta: o PITR restaura para um ponto no tempo e âmbito da restauração selecionados. Verifica se selecionaste a conta, o contentor, o caminho e o carimbo temporal corretos.
O meu custo de armazenamento aumentou depois de ativar o PITR: PITR com versionamento e retenção aumenta os dados armazenados ao longo do tempo. Verifique se as regras do ciclo de vida e as definições de retenção estão otimizadas.
Importante
Se restaurar blobs de blocos para um ponto anterior a 22 de setembro de 2020, as limitações de pré-visualização para restauração pontual no tempo estão em vigor. A Microsoft recomenda que escolha um ponto de restauração igual ou posterior a 22 de setembro de 2020 para aproveitar o recurso de restauração point-in-time disponível em geral.
Preços e faturação
Não há cobrança para habilitar o restauro point-in-time. No entanto, ativar a restauração pontual também possibilita a versão de blobs, a eliminação suave e o feed de alterações, cada um dos quais pode resultar em custos adicionais.
A faturação das operações de restauro em ponto no tempo baseia-se na quantidade de dados do feed de alterações processados para a restauração. Também paga por quaisquer transações de armazenamento envolvidas no processo de restauro.
Para obter mais informações sobre preços para restauração point-in-time, consulte preços de blobs de blocos.