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

  • Artigo

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

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

Descrição geral

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

  • Crie um novo banco de dados na mesma instância gerenciada, recuperado para um point-in-time especificado dentro do período de retenção.
  • Crie um novo banco de dados na mesma instância gerenciada ou em uma instância gerenciada diferente, recuperada para um point-in-time especificado dentro do período de retenção.
  • Crie um banco de dados na mesma instância gerenciada ou em uma instância gerenciada diferente, recuperado até o tempo de exclusão de um banco de dados excluído.
  • Crie um novo banco de dados em qualquer instância gerenciada na mesma assinatura ou em uma assinatura diferente no mesmo locatário e na mesma região, recuperada até o ponto dos backups mais recentes.

Se você configurou a retenção de longo prazo (LTR), também poderá criar um novo banco de dados a partir de qualquer backup de retenção de longo prazo em qualquer instância.

Importante

Não pode substituir uma base de dados existente durante o restauro.

Tempo de recuperação

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

  • O tamanho da base de dados
  • O tamanho de 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 da rede se a restauração for para uma região diferente
  • O número de solicitações de restauração simultâneas processadas na região de destino

Para uma base de dados grande ou muito ativa, o restauro pode demorar várias horas. Uma interrupção prolongada em uma região pode causar um grande número de solicitações de restauração geográfica para recuperação de desastres. Quando existem muitos pedidos, o tempo de recuperação de bases de dados individuais pode aumentar. A maioria dos restauros de bases de dados é concluída em menos de 12 horas.

Gorjeta

Para a Instância Gerenciada SQL do Azure, as atualizações do sistema têm precedência sobre as restaurações de banco de dados em andamento. Se existir uma atualização do sistema para o SQL Managed Instance, todos os restauros pendentes serão suspensos e, em seguida, retomados após a aplicação da atualização. Este comportamento do sistema pode prolongar o tempo dos restauros e pode afetar especialmente os restauros de execução prolongada.

Para obter uma hora previsível dos restauros de bases de dados, considere configurar janelas de manutenção que permitam o agendamento de atualizações do sistema num dia e hora específicos. Considere também executar restauros de bases de dados fora da janela de manutenção agendada.

Permissões

Para recuperar usando backups automatizados, você deve ser:

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

Para obter mais informações, consulte Azure RBAC: funções internas.

Você pode recuperar usando o portal do Azure, o PowerShell ou a API REST. Não é possível usar o Transact-SQL.

Restauro para um ponto anterior no tempo

Você pode restaurar um banco de dados para um ponto anterior no tempo. O pedido pode especificar qualquer escalão de serviço ou tamanho da computação para a base de dados restaurada. 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 novo banco de dados na instância de destino, seja a mesma instância ou uma instância diferente. O banco de dados restaurado é cobrado a taxas normais, com base em sua camada de serviço e tamanho de computação. Você não incorre em cobranças até que a restauração do banco de dados seja concluída.

Geralmente, você restaura um banco de dados para um ponto anterior para fins de recuperação. Você pode tratar o banco de dados restaurado como um substituto para o banco de dados original ou usá-lo como uma fonte de dados para atualizar o banco de dados original.

Importante

Não pode fazer um restauro para um ponto anterior no tempo numa base de dados secundária georreplicada. Só o pode fazer numa base de dados primária.

  • Substituição da base de dados

    Se desejar que o banco de dados restaurado substitua o banco de dados original, especifique o tamanho de computação e a camada de serviço do banco de dados original. Em seguida, você pode 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

    Se você planeja recuperar dados do banco de dados restaurado para se recuperar de um erro de usuário ou aplicativo, precisará escrever e executar um script de recuperação de dados que extraia dados do banco de dados restaurado e se aplica 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.

    Se você excluir o banco de dados durante a restauração, a operação de restauração será cancelada. Você não será cobrado pelo banco de dados que não concluiu a restauração.

Para recuperar um banco de dados na Instância Gerenciada SQL para um point-in-time usando o portal do Azure, você pode ir para o banco de dados no portal e escolher Restaurar. Como alternativa, você pode abrir a página de visão geral da Instância Gerenciada SQL de destino e selecionar + Novo banco de dados na barra de ferramentas para abrir a página Criar Banco de Dados Gerenciado SQL do Azure.

Screenshot that shows the SQL Managed Instance overview pane in the Azure portal, with adding a new database selected.

Forneça detalhes da instância gerenciada de destino na guia Noções básicas e escolha um tipo de backup na guia Fonte de dados.

Screenshot of the Azure portal that shows the data source tab of the Create Azure SQL Managed Database page, with point-in-time restore selected.

Para obter mais detalhes, consulte o artigo Restauração pontual.

Restauração de banco de dados excluída

Você pode restaurar um banco de dados excluído para o tempo de exclusão, ou um ponto anterior no tempo, para a mesma instância ou uma instância diferente da instância de origem. A instância de destino pode estar na mesma assinatura ou em uma assinatura diferente da instância de origem. Ao restaurar uma base de dados eliminada, cria uma nova base de dados a partir da cópia de segurança.

Importante

Não pode restaurar uma instância gerida eliminada. Se você excluir uma instância gerenciada, todos os seus bancos de dados também serão excluídos e não poderão ser restaurados para o tempo de exclusão ou para um point-in-time anterior. 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 o point-in-time 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. Escolha mostrar Backups excluídos e selecione Restaurar ao lado do backup excluído que você deseja recuperar para abrir a página Criar Banco de Dados Gerenciado SQL do Azure. Forneça detalhes da instância gerenciada de destino na guia Noções básicas e detalhes da instância gerenciada de origem na guia Fonte de dados. Configure as configurações de retenção na guia Configurações adicionais.

Screenshot of the Azure portal, Backups page of the SQL Managed Instance, showing deleted databases and selecting the Restore action.

Gorjeta

Pode levar vários minutos para que os bancos de dados excluídos recentemente apareçam na página Bancos de dados excluídos no portal do Azure ou quando você deseja exibir bancos de dados excluídos usando a linha de comando.

Restauro geográfico

Importante

  • A restauração geográfica está disponível apenas para instâncias gerenciadas configuradas com armazenamento de backup com redundância geográfica. Se não estiver a utilizar atualmente cópias de segurança georreplicadas para uma base de dados, pode alterar isto ao configurar a redundância do armazenamento de cópias de segurança.
  • Você pode executar a restauração geográfica em instâncias gerenciadas que residem apenas na mesma assinatura.

A restauração geográfica é a opção de recuperação padrão quando o banco de dados está indisponível devido a um incidente na região de hospedagem. Você pode restaurar o banco de dados para uma instância em qualquer outra região. Você pode restaurar um banco de dados em qualquer instância gerenciada em qualquer região do Azure a partir dos backups replicados geograficamente mais recentes. A restauração geográfica usa um backup replicado geograficamente como origem. Você pode solicitar uma restauração geográfica mesmo que uma interrupção tenha tornado o banco de dados ou o datacenter inacessíveis.

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

Illustration of restoring a database across regions for the purpose of geo-restore.

No portal do Azure, você pode restaurar um backup replicado geograficamente para uma instância existente ou criar uma nova 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 restaurados geograficamente.

Para restaurar para uma instância existente, siga as etapas em Restauração point-in-time e certifique-se de escolher as instâncias de origem e de destino apropriadas para restaurar o banco de dados para a instância pretendida.

Para restaurar geograficamente para uma nova instância usando o portal do Azure, siga estas etapas:

  1. Vá para sua nova instância gerenciada do SQL do Azure.
  2. Selecione Nova base 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 para a fonte de dados.
  5. Selecione uma cópia de segurança na lista de cópias de segurança com restauro geográfico disponíveis.

Depois de concluir o 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 o restauro geográfico

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

  • O RPO (Recovery Point Objetive, 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.
  • Região secundária (emparelhada) são as configurações 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 de novos bancos de dados, eles devem 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 os negócios. Para aplicativos críticos para os negócios que exigem grandes bancos de dados e devem garantir a continuidade dos negócios, use grupos de failover. Esse recurso oferece um RPO e RTO muito mais baixos, e a capacidade é sempre garantida.

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

Limitações

Considere as seguintes limitações ao trabalhar com backups e a Instância Gerenciada 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 SQL de origem.
  • Os bancos de dados da Instância Gerenciada SQL do Azure só podem ser restaurados para o SQL Server 2022 (no local ou em uma máquina virtual) se a Instância Gerenciada do SQL de origem tiver se inscrito na onda de recursos de novembro de 2022.
  • Os bancos de dados da Instância Gerenciada SQL do Azure são criptografados com TDE por padrão. Quando o banco de dados de origem usa uma chave gerenciada pelo cliente (CMK) como protetor TDE, para restaurar seu banco de dados para uma instância diferente da Instância Gerenciada SQL de origem, a instância de destino deve ter acesso à mesma chave usada para criptografar o banco de dados de origem no Cofre de Chaves do Azure ou você deve desabilitar a criptografia TDE no banco de dados de origem antes de fazer o backup.
  • Você só pode acompanhar o progresso do processo de restauração usando as exibições de gerenciamento sys.dm_exec_requests e sys.dm_operation_status dinâmico.
  • Quando as políticas de ponto de extremidade de serviço são habilitadas na Instância Gerenciada SQL do Azure, colocar uma política de ponto de extremidade de serviço em uma sub-rede impede restaurações point-in-time (PITR) de instâncias em sub-redes diferentes.
  • O RPO (Recovery Point Objetive, objetivo de ponto de recuperação) é de até 1 hora.
  • O RTO (Recovery Time Objetive, 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 ir 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. Pode levar até 24 horas para que os backups do novo banco de dados fiquem visíveis.

Conteúdos relacionados