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

Aplica-se a:Azure SQL Managed Instance

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.

Visão geral

Os backups automatizados de bancos de dados ajudar 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 gerida, recuperada para um momento específico dentro do período de retenção.
• Crie um novo banco de dados na mesma instância gerida ou em uma instância gerida diferente, recuperada para um ponto no tempo especificado dentro do período de retenção.
• Crie um banco de dados na mesma instância gerida ou numa instância gerida diferente, recuperado até o momento da exclusão de um banco de dados eliminado.
• Crie um novo banco de dados em qualquer instância gerida na mesma subscrição ou numa subscrição diferente no mesmo locatário e na mesma região, recuperado até o ponto dos backups mais recentes.

Se você configurou de 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.

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 do banco 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é ao 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 um banco de dados grande ou muito ativo, a restauração pode levar 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 há muitas solicitações, o tempo de recuperação para bancos de dados individuais pode aumentar. A maioria das restaurações de banco de dados termina em menos de 12 horas.

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 RBAC do Azure: 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.

Restauração de um ponto específico no tempo

Pode restaurar uma base 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.

• Substituição de banco 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.

Restauro de base de dados eliminado

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 subscrição ou numa diferente da instância de origem. Pode restaurar uma base de dados eliminada criando uma nova base de dados a partir da cópia de segurança.

Restaurando um banco de dados a partir de uma instância gerenciada SQL excluída

Se você precisar restaurar uma instância gerenciada SQL excluída involuntariamente, entre em contato com a equipe de suporte da Microsoft dentro de 5 dias após a operação de exclusão. Considere o seguinte:

• Você precisa de uma instância existente com uma camada de serviço correspondente e SLO igual ou superior, como a instância excluída. Esteja pronto para fornecer suporte com detalhes da instância de destino.
• Os bancos de dados criptografados protegidos por uma chave gerenciada pelo cliente (CMK) só podem ser restaurados para instâncias que tenham acesso à mesma chave.
• Somente bancos de dados criados pelo usuário podem ser restaurados. Os bancos de dados do sistema não podem ser restaurados.
• A restauração só é possível para o último backup point-in-time feito pouco antes da instância ser excluída, usando o backup final do tail-log feito antes da operação de exclusão.
• A restauração de bancos de dados de uma instância excluída só é possível a partir de uma versão paga da instância gerenciada pelo SQL. Não há suporte para a restauração de bancos de dados de uma instância gratuita excluída.

Geo-restauração

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 utiliza um backup replicado geograficamente como fonte. 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.

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

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 cópias de segurança replicadas geograficamente e criadas automaticamente numa região secundária (emparelhada). Aqui estão algumas considerações para a restauração geográfica:

• O RPO (Recovery Point Objective, 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 aplicações críticas para os negócios que exigem grandes bases de dados e devem garantir a continuidade dos negócios, use grupos de recuperação automática. 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.

Risco de segurança ao restaurar backups de fontes não confiáveis

Esta secção descreve o risco de segurança associado à restauração de backups de fontes não confiáveis para qualquer ambiente SQL Server, incluindo on-premises, Azure SQL Managed Instance, SQL Server em Máquinas Virtuais Azure (VMs) e qualquer outro ambiente.

Por que motivo isto é importante

Restaurar ficheiros de backup SQL (.bak) introduz um risco potencial se o backup tiver origem numa fonte não confiável. O risco de segurança agrava-se ainda mais quando um ambiente SQL Server tem múltiplas instâncias, pois amplifica a área de ameaça. Embora backups que permaneçam dentro de um limite de confiança não representem qualquer problema de segurança, restaurar um backup malicioso pode comprometer a segurança de todo o ambiente.

Um ficheiro malicioso .bak pode:

• Assuma o controle de toda a instância do SQL Server.
• Escalar privilégios e obter acesso não autorizado ao host ou máquina virtual subjacente.

Este ataque ocorre antes de qualquer script de validação ou verificação de segurança poder ser executado, o que o torna extremamente perigoso. Restaurar um backup não confiável equivale a executar aplicações não confiáveis num servidor crítico ou máquina virtual, e introduzir a execução arbitrária de código no seu ambiente.

Melhores práticas

Siga estas melhores práticas de segurança de backup para reduzir a ameaça aos seus ambientes SQL Server:

• Trate a restauração de cópias de segurança como uma operação de alto risco.
• Reduza a área de serviço de ameaça utilizando instâncias isoladas.
• Permita apenas backups de confiança: nunca restaure backups de fontes desconhecidas ou externas.
• Só permitam backups que tenham permanecido dentro de um limite de confiança: certifique-se de que os backups têm origem dentro do limite de confiança.
• Não contorne os controlos de segurança por conveniência.
• Permitir auditoria ao nível do servidor para capturar backups e restaurar eventos e mitigar evasão de auditoria.

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ã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 vistas de gestão dinâmicas sys.dm_exec_requests e sys.dm_operation_status.
• Quando políticas de ponto de extremidade de serviço estão presentes em uma sub-rede delegada à Instância Gerenciada SQL do Azure, a restauração point-in-time (PITR) para instâncias gerenciadas nessa sub-rede não pode ser executada a partir de instâncias em regiões diferentes.
• O RPO (Recovery Point Objective, 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.
• O número máximo de bancos de dados que você pode restaurar em paralelo é de 200 por assinatura única. Em alguns casos, é possível aumentar esse limite abrindo um ticket de suporte.
• Os backups de banco de dados podem ser restaurados para a instância gerenciada SQL com base na mesma política de atualização ou na versão superior:
  • Os backups de banco de dados obtidos de instâncias configuradas com a política de atualização do SQL Server 2022 podem ser restaurados para instâncias configuradas com a política de atualização SQL Server 2022, SQL Server 2025 ou Always-up-to-date .
  • Os backups de banco de dados obtidos de instâncias configuradas com a política de atualização do SQL Server 2025 podem ser restaurados para instâncias configuradas com o SQL Server 2025 ou com a política de atualização Always-up-to-date .
  • Os backups de banco de dados obtidos de instâncias configuradas com a política de atualização Always-up-to-date só podem ser restaurados para instâncias também configuradas com a política de atualização Always-up-to-date .

Conteúdo relacionado

• Backups automatizados da SQL Managed Instance
• Retenção a longo prazo
• Para saber mais sobre opções de recuperação mais rápidas, consulte Grupos de contingência.