Restaurar um banco de dados a partir de um backup no Banco de Dados SQL do Azure
Aplica-se a:
Banco de Dados SQL do Azure
Este artigo fornece etapas para recuperar qualquer banco de dados de um backup no Banco de Dados SQL do Azure, incluindo bancos de dados Hyperscale. Para a Instância Gerenciada SQL do Azure, consulte Restaurar um banco de dados a partir de um backup na Instância Gerenciada SQL do Azure.
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:
- Criar uma nova base de dados no mesmo servidor, recuperada para um ponto no tempo específico dentro do período de retenção.
- Criar uma base de dados no mesmo servidor, recuperada para a hora de eliminação de uma base de dados eliminada.
- Crie um novo banco de dados em qualquer servidor na mesma região, recuperado até o momento de um backup recente.
- Criar uma nova base de dados em qualquer servidor em qualquer outra região, recuperada para o ponto das cópias de segurança replicadas 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 servidor.
Importante
- Não pode substituir uma base de dados existente durante o restauro.
- As operações de restauração do banco de dados não restauram as tags do banco de dados original.
Quando você estiver usando a camada de serviço Standard ou Premium no modelo de compra de DTU, a restauração do banco de dados pode incorrer em um custo de armazenamento extra. O custo extra acontece quando o tamanho máximo do banco de dados restaurado é maior do que a quantidade de armazenamento incluída na camada de serviço e no objetivo de serviço do banco de dados de destino.
Para obter detalhes de preços de armazenamento extra, consulte a página de preços do Banco de dados SQL. Se a quantidade real de espaço usado for menor do que a quantidade de armazenamento incluída, você poderá evitar esse custo extra definindo o tamanho máximo do banco de dados para a quantidade incluída.
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.
Para uma única assinatura, você tem as seguintes limitações no número de solicitações de restauração simultâneas. Estas limitações aplicam-se a qualquer combinação de restauros para um ponto anterior no tempo, restauros geográficos e restauros a partir da cópia de segurança de retenção de longo prazo.
| Opção de implementação | Max # de solicitações simultâneas sendo processadas | Max # de solicitações simultâneas sendo enviadas |
|---|---|---|
| Base de dados individual (por subscrição) | 30 | 100 |
| Conjunto elástico (por conjunto) | 4 | 2.000 |
Permissões
Para recuperar usando backups automatizados, você deve ser:
- Um membro da função de Colaborador ou da função de Colaborador do SQL Server na assinatura ou grupo de recursos que contém o servidor lógico
- O proprietário da subscrição ou do grupo de recursos
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 qualquer banco de dados para um point-in-time anterior dentro de seu período de retenção. A solicitação de restauração pode especificar qualquer camada de serviço ou tamanho de computação para o banco de dados restaurado. Ao restaurar um banco de dados em um pool elástico, verifique se você tem recursos suficientes no pool para acomodar o banco de dados.
Quando a restauração estiver concluída, ele criará um novo banco de dados no mesmo servidor que o banco de dados original. 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
- Você pode executar uma restauração point-in-time de um banco de dados para o mesmo servidor. Atualmente, não há suporte para restauração point-in-time entre servidores, entre assinaturas cruzadas e entre geografias. Para restaurar um banco de dados para uma região diferente usando backups replicados geograficamente, consulte Restauração geográfica.
- 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.
- O
BackupFrequencyparâmetro não é suportado para bancos de dados Hyperscale. - As operações de restauração de banco de dados consomem muitos recursos e podem exigir uma camada de serviço de S3 ou superior para o banco de dados de restauração (de destino). Quando a restauração for concluída, o banco de dados ou o pool elástico poderá ser reduzido, se necessário.
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 para um point-in-time usando o portal do Azure, abra a página de visão geral do banco de dados e selecione Restaurar na barra de ferramentas. Escolha a origem do backup e, em seguida, selecione o ponto de backup point-in-time a partir do qual um novo banco de dados será criado.
Restauro de cópias de segurança de longo prazo
Para executar uma operação de restauração em um backup de longo prazo, você pode usar o portal do Azure, a CLI do Azure, o Azure PowerShell ou a API REST. Para obter mais informações, consulte Restaurar um backup de longo prazo. A retenção de longo prazo não é aplicável a bancos de dados Hyperscale.
Para recuperar um backup de longo prazo usando o portal do Azure, vá para seu servidor lógico. Selecione Backups em Configurações e, em seguida, selecione Gerenciar em Backups LTR disponíveis para o banco de dados que você está tentando restaurar.
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, no mesmo servidor usando o portal do Azure, a CLI do Azure, o Azure PowerShell e a API REST.
Importante
Se você excluir um servidor, todos os seus bancos de dados e seus backups PITR também serão excluídos. Não é possível restaurar um servidor excluído e não é possível restaurar os bancos de dados excluídos dos backups PITR. Se você configurou backups LTR para esses bancos de dados, poderá usá-los para restaurar os bancos de dados em um servidor diferente.
Para recuperar um banco de dados excluído para o tempo de exclusão usando o portal do Azure, abra a página de visão geral do servidor e selecione Bancos de dados excluídos. Selecione um banco de dados excluído que você deseja restaurar e insira o nome do novo banco de dados que será criado com os dados restaurados do backup.
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 programaticamente.
Restauro geográfico
Você pode usar a restauração geográfica para restaurar um banco de dados excluído usando o portal do Azure, a CLI do Azure, o Azure PowerShell e a API REST.
Importante
- A restauração geográfica está disponível apenas para bancos de dados configurados 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 somente em bancos de dados que residem na mesma assinatura.
A restauração geográfica usa backups replicados geograficamente como origem. Você pode restaurar um banco de dados em qualquer servidor lógico em qualquer região do Azure a partir dos backups replicados geograficamente mais recentes. Você pode solicitar uma restauração geográfica mesmo que uma interrupção tenha tornado o banco de dados ou toda a região inacessível.
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. Pode restaurar a base de dados para um servidor em qualquer outra região.
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.
No portal do Azure, você cria um novo banco de dados único e seleciona 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 geograficamente um único banco de dados do portal do Azure na região e no servidor de sua escolha, siga estas etapas:
- No Painel, selecione Adicionar>Criar Banco de Dados SQL. Na guia Noções básicas, insira as informações necessárias.
- Selecione Configurações adicionais.
- Em Usar dados existentes, selecione Backup.
- Selecione uma cópia de segurança na lista de cópias de segurança com restauro geográfico disponíveis.
Conclua o processo de criação de um banco de dados a partir do backup. Quando você cria um banco de dados no Banco de Dados SQL do Azure, ele contém o backup de restauração geográfica restaurado.
Considerações sobre o restauro geográfico
Para obter mais informações sobre como usar a restauração geográfica, consulte Recuperação usando restauração geográfica.
Nota
Para obter informações detalhadas sobre a recuperação de uma interrupção, consulte as diretrizes de recuperação de desastres do Banco de Dados SQL do Azure e a lista de verificação de alta disponibilidade e recuperação de desastres do Banco de Dados SQL do Azure.
A restauração geográfica é a solução mais básica de recuperação de desastres disponível no Banco de dados SQL. Ele depende de backups replicados geograficamente criados automaticamente com um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) de até 1 hora e um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) estimado de até 12 horas. Isso não garante que a região de destino terá a capacidade de restaurar seus bancos de dados após uma interrupção regional, porque é provável um aumento acentuado da demanda. Se seu aplicativo usa bancos de dados relativamente pequenos e não é crítico para os negócios, a restauração geográfica é uma solução apropriada de recuperação de desastres.
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.
Nota
Se você planeja usar a restauração geográfica como solução de recuperação de desastres, recomendamos que realize exercícios periódicos para verificar a tolerância do aplicativo a qualquer perda de modificações de dados recentes, juntamente com todos os aspetos operacionais do procedimento de recuperação.
Próximos passos
- Backups automatizados do Banco de dados SQL
- Retenção de longa duração
- Para saber mais sobre opções de recuperação mais rápidas, consulte Replicação geográfica ativa ou Grupos de failover.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários