Restaurar um banco de dados de um backup na Instância Gerenciada de SQL do Azure

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo fornece etapas para recuperar um banco de dados de um backup na Instância Gerenciada de SQL do Azure. Para o Banco de Dados SQL do Azure, confira Restaurar um banco de dados de um backup no Banco de Dados SQL do Azure.

Visão geral

Os backups de banco de dados automatizados ajudam a proteger seus bancos de dados contra erros de usuários e aplicativos, exclusão acidental de banco de dados e interrupções prolongadas. Essa funcionalidade interna está disponível para todas as camadas de serviço e tamanhos da computação. As seguintes opções estão disponíveis para a recuperação de banco de dados por meio de backups automatizados:

  • Crie um banco de dados na mesma instância gerenciada, recuperado em um momento específico do período de retenção.
  • Crie um banco de dados na mesma instância gerenciada ou em outra instância gerenciada, recuperado em um momento específico do período de retenção.
  • Crie um banco de dados na mesma instância gerenciada ou em outra instância gerenciada, recuperado no momento da exclusão de um banco de dados excluído.
  • Crie um banco de dados em qualquer instância gerenciada na mesma assinatura ou em uma outra assinatura no mesmo locatário e na mesma região, recuperado até o ponto dos backups mais recentes.

Se você tiver configurado a LTR (retenção de longo prazo), também será possível criar um banco de dados com base em qualquer backup de retenção de longo prazo em qualquer instância.

Importante

Não é possível substituir um banco de dados existente durante a restauração.

Tempo de recuperação

Diversos fatores afetam o tempo de recuperação para restaurar um banco de dados por meio de backups de banco de dados automatizados:

  • O tamanho do banco de dados
  • O tamanho da computação do banco de dados
  • O número de logs de transações envolvidos
  • A quantidade de atividade que precisa ser repetida para recuperar até o ponto de restauração
  • A largura de banda de rede se a restauração for para uma região diferente
  • O número de solicitações de restauração simultâneas que são processadas na região de destino

Para um banco de dados muito grande ou muito ativo, a restauração pode levar várias horas. Uma interrupção prolongada em uma região pode causar um alto número de solicitações de restauração geográfica para recuperação de desastres. Quando houver muitas solicitações, o tempo de recuperação dos bancos de dados individuais poderá aumentar. A maioria das restaurações de banco de dados é concluída em menos de 12 horas.

Dica

Para a Instância Gerenciada de SQL do Azure, as atualizações do sistema têm precedência sobre as restaurações de banco de dados em andamento. Se houver uma atualização de sistema para a Instância Gerenciada de SQL, todas as restaurações pendentes serão suspensas e retomadas após a aplicação da atualização. Esse comportamento do sistema pode prolongar o tempo de restaurações e pode ser especialmente impactante para restaurações de longa execução.

Para obter um tempo previsível de restaurações de banco de dados, considere configurar janelas de manutenção a fim de permitir o agendamento de atualizações do sistema em dias e horas específicos. Considere também executar restaurações de banco de dados fora da janela de manutenção agendada.

Permissões

Para recuperações com base em backups automatizados, o seguinte é necessário:

  • Um membro com a função de Colaborador do SQL Server ou da Instância Gerenciada de SQL (dependendo do destino de recuperação) na assinatura
  • O proprietário da assinatura

Para obter mais informações, confira Funções internas do Azure RBAC.

Você pode usar o portal do Azure, o PowerShell ou a API REST para a recuperação. Não é possível usar o T-SQL.

Restauração em um momento determinado

É possível restaurar um banco de dados para um momento anterior. A solicitação pode especificar qualquer camada de serviço ou tamanho da computação para o banco de dados restaurado. Verifique se você tem recursos suficientes na instância para a qual está restaurando o banco de dados.

Quando a restauração é concluída, ela cria um banco de dados na instância de destino, seja a mesma instância ou outra. O banco de dados restaurado é cobrado a taxas normais com base no tamanho da computação e na camada de serviço. Você não incorrerá em encargos até que a restauração do banco de dados seja concluída.

Um banco de dados geralmente é restaurado para um ponto anterior para fins de recuperação. Você poderá tratar o banco de dados restaurado como um substituto do banco de dados original ou usá-lo como uma fonte de dados para atualizar o banco de dados original.

Importante

Não é possível executar uma restauração pontual em um banco de dados geográfico secundário. Você só pode fazer isso em um banco de dados primário.

  • Substituição de banco de dados

    Para que o banco de dados restaurado seja um substituto do banco de dados original, especifique o tamanho de computação e a camada de serviço do original. Você pode então renomear o banco de dados original e dar ao banco de dados restaurado o nome original usando o comando ALTER DATABASE no T-SQL.

  • Recuperação de dados

    Para recuperar dados do banco de dados restaurado a fim de se recuperar de um erro de usuário ou aplicativo, é necessário gravar e executar um script de recuperação de dados que extraia dados do banco de dados restaurado e seja aplicado ao banco de dados original. Embora a operação de restauração possa levar muito tempo para ser concluída, o banco de dados de restauração fica visível na lista de bancos de dados durante todo o processo de restauração.

    Ao excluir o banco de dados durante a restauração, a operação de restauração é cancelada. Você não será cobrado por restaurações incompletas do banco de dados.

Para fazer uma restauração pontual de um banco de dados em Instância Gerenciada de SQL usando o portal do Azure, acesse o banco de dados no portal e escolha Restaurar. Como alternativa, você pode abrir a página de visão geral da Instância Gerenciada de SQL de destino e selecionar + Novo banco de dados na barra de ferramentas para abrir a página Criar banco de dados gerenciados do SQL do Azure.

Captura de tela que mostra o painel de visão geral da Instância Gerenciada de SQL no portal do Azure, com a adição de um novo banco de dados selecionado.

Forneça detalhes da instância gerenciada de destino na guia Básico e escolha um tipo de backup na guia Fonte de dados.

Captura de tela do portal do Azure que mostra a guia fonte de dados da página Criar banco de dados gerenciado do SQL do Azure, com a restauração pontual selecionada.

Para obter mais detalhes, examine o artigo Restauração Pontual.

Restauração de banco de dados excluído

Você pode restaurar um banco de dados excluído até a hora de exclusão ou um momento anterior, na mesma instância ou em outra instância que não seja a de origem. A instância de destino pode estar na mesma assinatura ou em uma assinatura diferente da instância de origem. Para restaurar um banco de dados excluído, crie um novo banco de dados do backup.

Importante

Não é possível restaurar uma instância gerenciada excluída. Se você excluir uma instância gerenciada, todos os bancos de dados também serão excluídos e não poderão ser restaurados para o tempo de exclusão ou um ponto anterior no tempo. Se você configurou a retenção de longo prazo (LTR), ainda poderá restaurar um banco de dados da instância excluída para outra instância e para um ponto anterior no tempo quando o backup LTR foi feito.

Para recuperar um banco de dados usando o portal do Azure, abra a página de visão geral da instância gerenciada e selecione Backups. Opte por mostrar os backups Excluídos e selecione Restaurar ao lado do backup excluído que deseja recuperar para abrir a página Criar Banco de Dados Gerenciado SQL do Azure. Forneça os detalhes da instância gerenciada de destino na guia Informações Básicas e os detalhes da instância gerenciada de origem na guia Fonte de dados. Defina as configurações de retenção na guia Configurações adicionais.

Captura de tela do portal do Azure, página Backups da Instância Gerenciada de SQL, que mostra os bancos de dados excluídos e a seleção da ação Restaurar.

Dica

Pode demorar muitos minutos para que os bancos de dados excluídos recentemente apareçam na página Bancos de dados excluídos do portal do Azure ou para exibir os bancos de dados excluídos usando a linha de comando.

Restauração geográfica

Importante

  • A restauração geográfica está disponível somente para instâncias gerenciadas configuradas com o armazenamento de backup com redundância geográfica. Se você não estiver usando backups replicados geograficamente para um banco de dados, poderá alterar isso configurando a redundância de armazenamento de backup.
  • É possível executar a restauração geográfica somente em instâncias gerenciadas que residem na mesma assinatura.

A restauração geográfica é a opção de recuperação padrão quando o banco de dados não estiver disponível devido a um incidente na região de hospedagem. É possível restaurar o banco de dados em uma instância em qualquer outra região. É possível restaurar um banco de dados em qualquer instância gerenciada em qualquer região do Azure com base nos backups replicados geograficamente mais recentes. A restauração geográfica usa um backup de replicação geográfica como origem. É possível solicitar uma restauração geográfica mesmo quando uma interrupção tornou o banco de dados ou o datacenter inacessível.

Há um atraso entre o momento em que um backup é realizado e quando ele é replicado geograficamente para um blob do Azure em uma região diferente. Como resultado, o banco de dados restaurado pode ter até uma hora de atraso em relação ao banco de dados original. A ilustração a seguir mostra uma restauração do banco de dados desde o último backup disponível em outra região.

Ilustração da restauração de um banco de dados entre regiões para fins de restauração geográfica.

No portal do Azure, você pode restaurar um backup com replicação geográfica em uma instância existente ou criar uma instância gerenciada e selecionar um backup de restauração geográfica disponível. O banco de dados recém-criado contém os dados de backup da restauração geográfica.

Para fazer a restauração em uma instância existente, siga as etapas descritas em Restauração pontual e escolha as instâncias de origem e destino apropriadas para restaurar seu banco de dados para a instância pretendida.

Para a restauração geográfica em uma nova instância usando o portal do Azure, siga estas etapas:

  1. Acesse sua nova instância gerenciada de SQL do Azure.
  2. Selecione Novo banco de dados.
  3. Insira um nome de banco de dados.
  4. Em Fonte de dados, escolha o tipo apropriado de backup e forneça detalhes da fonte de dados.
  5. Selecione um backup na lista de backups de restauração geográfica disponíveis.

Depois do processo de criação de um banco de dados de instância, ele conterá o backup de restauração geográfica restaurado.

Considerações sobre restauração geográfica

A restauração geográfica é a solução de recuperação de desastre mais básica disponível na Instância Gerenciada de SQL do Azure. Ela depende de backups replicados geograficamente criados automaticamente em uma região secundária (emparelhada). Aqui estão algumas considerações sobre a restauração geográfica:

  • O RPO (objetivo de ponto de recuperação) é de até 1 hora.
  • Os processos de restauração (objetivo de tempo de recuperação – RTO) geralmente levam menos de 12 horas, mas podem variar com base no tamanho e na atividade do banco de dados, de modo que a restauração pode se estender além desse período.
  • A região secundária (emparelhada) é a configuração de armazenamento do Azure para a região primária. Não é possível alterar a região secundária.
  • Os bancos de dados recém-criados/restaurados podem não aparecer imediatamente como restauráveis em outras regiões devido a um atraso no preenchimento de novos dados. Se os clientes não virem os backups dos novos bancos de dados, eles deverão antecipar um período de espera de até 24 horas.

É essencial reconhecer que a restauração geográfica serve como uma solução apropriada de recuperação de desastres para aplicativos com bancos de dados relativamente pequenos que não são críticos para as atividades de negócios. Para os aplicativos comercialmente críticos que exigem bancos de dados grandes e precisam garantir a continuidade dos negócios, use grupos de failover. Esse recurso oferece um RPO e um RTO muito menores, e a capacidade é sempre garantida.

Para obter mais informações sobre as opções de continuidade dos negócios, confira Visão geral de continuidade de negócios.

Limitações

Considere as seguintes limitações ao trabalhar com backups e a Instância Gerenciada de SQL do Azure:

  • A restauração geográfica de um banco de dados só pode ser executada em uma instância na mesma assinatura que a instância gerenciada do SQL de origem.
  • Backups nativos obtidos em bancos de dados da Instância Gerenciada de SQL do Azure só poderão ser restaurados para o SQL Server 2022 (local ou em uma máquina virtual), se a Instância Gerenciada de SQL de origem tiver se registrado no ciclo de recursos de novembro de 2022.
  • Os bancos de dados da Instância Gerenciada de SQL do Azure são criptografados com TDE por padrão. Quando o banco de dados de origem usa uma CMK (chave gerenciada pelo cliente) como o protetor TDE, para restaurar seu banco de dados para uma instância diferente da Instância Gerenciada de SQL de origem, a instância de destino precisa ter acesso à mesma chave usada para criptografar o banco de dados de origem no Azure Key Vault, ou você precisa desabilitar a criptografia TDE no banco de dados de origem antes de fazer o backup.
  • Você pode somente acompanhar o progresso do processo da restauração usando as exibições de gerenciamento dinâmico sys.dm_exec_requests e sys.dm_operation_status.
  • Quando as políticas de ponto de extremidade de serviço são habilitadas na Instância Gerenciada de SQL do Azure, a colocação de uma política de ponto de extremidade de serviço em uma sub-rede impede PITR (restaurações pontuais) de instâncias em sub-redes diferentes.
  • O RPO (objetivo de ponto de recuperação) é de até 1 hora.
  • O RTO (objetivo de tempo de recuperação) é de aproximadamente 12 horas, mas pode variar com base no tamanho do banco de dados e a atividade pode se estender além desse período.
  • A região secundária (emparelhada) não pode ser alterada.
  • Os bancos de dados recém-criados/restaurados podem não aparecer imediatamente como restauráveis em outras regiões devido a um atraso no preenchimento de novos dados. Até 24 horas podem ser necessárias para que os backups de novos bancos de dados se tornem visíveis.
  • O número máximo de bancos de dados que você pode restaurar em paralelo é 200 por assinatura única. Em alguns casos, é possível aumentar esse limite via tíquete de suporte.