Georreplicação ativa
Aplica-se a:
Banco de Dados SQL do Azure
A replicação geográfica ativa é um recurso que permite criar um banco de dados secundário legível continuamente sincronizado para um banco de dados primário. A base de dados secundária legível pode estar na mesma região do Azure que a principal ou, mais comummente, numa região diferente. Esse tipo de banco de dados secundário legível também é conhecido como geo-secundário ou geo-réplica.
A replicação geográfica ativa é configurada por banco de dados e suporta apenas failover manual. Para fazer failover de um grupo de bancos de dados, ou se seu aplicativo exigir um ponto de extremidade de conexão estável, considere grupos de failover.
Você também pode usar Migrar Banco de Dados SQL com replicação geográfica ativa.
Descrição geral
A replicação geográfica ativa foi projetada como uma solução de continuidade de negócios. A replicação geográfica ativa permite executar a recuperação rápida de desastres de bancos de dados individuais se houver um desastre regional ou uma interrupção em grande escala. Depois que a replicação geográfica estiver configurada, você poderá iniciar um failover geográfico para um geosecundário em uma região diferente do Azure. O failover geográfico é iniciado programaticamente pelo aplicativo ou manualmente pelo usuário.
O diagrama a seguir ilustra uma configuração típica de um aplicativo de nuvem com redundância geográfica usando replicação geográfica ativa.
Se, por qualquer motivo, o banco de dados primário falhar, você poderá iniciar um failover geográfico para qualquer um dos bancos de dados secundários. Quando um secundário é promovido à função principal, todos os outros secundários são automaticamente vinculados ao novo primário.
Você pode gerenciar a replicação geográfica e iniciar um failover geográfico usando qualquer um dos seguintes métodos:
- O portal do Azure
- PowerShell: Banco de dados único
- PowerShell: Pool elástico
- Transact-SQL: Banco de dados único ou pool elástico
- API REST: Banco de dados único
A replicação geográfica ativa usa a tecnologia de grupo de disponibilidade Always On para replicar de forma assíncrona o log de transações gerado na réplica primária para todas as réplicas geográficas. Embora, em qualquer momento, uma base de dados secundária possa estar ligeiramente atrás da base de dados primária, é garantido que os dados numa base de dados secundária são consistentes de forma transacional. Em outras palavras, as alterações feitas por transações não confirmadas não são visíveis.
Nota
A replicação geográfica ativa replica as alterações transmitindo o log de transações do banco de dados da réplica primária para as réplicas secundárias. Ele não está relacionado à replicação transacional, que replica as alterações executando comandos DML (INSERT, UPDATE, DELETE) nos assinantes.
A replicação geográfica fornece redundância regional. A redundância regional permite que os aplicativos se recuperem rapidamente de uma perda permanente de toda uma região do Azure ou partes de uma região, causada por desastres naturais, erros humanos catastróficos ou atos mal-intencionados. O RPO de replicação geográfica pode ser encontrado em Visão geral da continuidade de negócios.
A figura a seguir mostra um exemplo de replicação geográfica ativa configurada com uma primária na região Centro-Norte dos EUA e uma geosecundária na região Centro-Sul dos EUA.
Além da recuperação de desastres, a replicação geográfica ativa pode ser usada nos seguintes cenários:
- Migração de banco de dados: você pode usar a replicação geográfica ativa para migrar um banco de dados de um servidor para outro com o mínimo de tempo de inatividade.
- Atualizações de aplicativos: você pode criar um secundário extra como uma cópia de failback durante as atualizações de aplicativos.
Para alcançar a continuidade total dos negócios, adicionar redundância regional de banco de dados é apenas uma parte da solução. A recuperação de um aplicativo (serviço) de ponta a ponta após uma falha catastrófica requer a recuperação de todos os componentes que constituem o serviço e quaisquer serviços dependentes. Exemplos desses componentes incluem o software cliente (por exemplo, um navegador com um JavaScript personalizado), front-ends da Web, armazenamento e DNS. É fundamental que todos os componentes sejam resilientes às mesmas falhas e fiquem disponíveis dentro do RTO (Recovery Time Objetive, objetivo de tempo de recuperação) do seu aplicativo. Portanto, você precisa identificar todos os serviços dependentes e entender as garantias e capacidades que eles fornecem. Em seguida, você deve tomar as medidas adequadas para garantir que o serviço funcione durante o failover dos serviços dos quais ele depende. Para obter mais informações sobre como projetar soluções para recuperação de desastres, consulte Projetando soluções de nuvem para recuperação de desastres usando replicação geográfica ativa.
Terminologia e recursos de replicação geográfica ativa
Replicação assíncrona automática
Você só pode criar um geosecundário para um banco de dados existente. O geo-secundário pode ser criado em qualquer servidor lógico, diferente do servidor com o banco de dados primário. Uma vez criada, a réplica geosecundária é preenchida com os dados do banco de dados primário. Este processo é conhecido como semeadura. Depois que um geosecundário é criado e propagado, as atualizações do banco de dados primário são replicadas automática e assincronamente para a réplica geosecundária. A replicação assíncrona significa que as transações são confirmadas no banco de dados primário antes de serem replicadas.
Réplicas geosecundárias legíveis
Um aplicativo pode acessar uma réplica geosecundária para executar consultas somente leitura usando as mesmas entidades de segurança ou diferentes usadas para acessar o banco de dados primário. Para obter mais informações, consulte Usar réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura.
Importante
Você pode usar a replicação geográfica para criar réplicas secundárias na mesma região da principal. Você pode usar esses secundários para satisfazer cenários de expansão de leitura na mesma região. No entanto, uma réplica secundária na mesma região não fornece resiliência adicional a falhas catastróficas ou interrupções em grande escala e, portanto, não é um destino de failover adequado para fins de recuperação de desastres. Também não garante o isolamento da zona de disponibilidade. Use a configuração redundante da zona de camadas de serviço Business Critical ou Premium ou a configuração redundante da zona de camada de serviço de uso geral para obter o isolamento da zona de disponibilidade.
Failover (sem perda de dados)
O failover alterna as funções dos bancos de dados primários e geosecundários após concluir a sincronização completa de dados para que não haja perda de dados. A duração do failover depende do tamanho do log de transações no primário que precisa ser sincronizado com o geosecundário. O failover foi projetado para os seguintes cenários:
- Execute exercícios de DR na produção quando a perda de dados não for aceitável
- Realocar o banco de dados para uma região diferente
- Retorne o banco de dados para a região primária após a interrupção ter sido atenuada (conhecida como failback).
Failover forçado (perda potencial de dados)
O failover forçado alterna imediatamente o geosecundário para a função principal sem esperar pela sincronização com a principal. Todas as transações confirmadas no primário, mas ainda não replicadas para o secundário, são perdidas. Essa operação foi projetada como um método de recuperação durante interrupções quando o primário não está acessível, mas a disponibilidade do banco de dados deve ser restaurada rapidamente. Quando o primário original está online novamente, ele é automaticamente reconectado, resemeados usando dados atuais do primário e se torna o novo geo-secundário.
Importante
Após failover ou failover forçado, o ponto de extremidade de conexão para o novo primário muda porque o novo primário agora está localizado em um servidor lógico diferente.
Vários geo-secundários legíveis
Até quatro geossecundários podem ser criados para uma primária. Se houver apenas um secundário e ele falhar, o aplicativo será exposto a um risco maior até que um novo secundário seja criado. Se existirem vários secundários, o aplicativo permanecerá protegido mesmo se um dos secundários falhar. Secundários adicionais também podem ser usados para expandir cargas de trabalho somente leitura.
Gorjeta
Se você estiver usando a replicação geográfica ativa para criar um aplicativo distribuído globalmente e precisar fornecer acesso somente leitura a dados em mais de quatro regiões, poderá criar um secundário de um secundário (um processo conhecido como encadeamento) para criar réplicas geográficas adicionais. O atraso de replicação em réplicas geográficas encadeadas pode ser maior do que em réplicas geográficas conectadas diretamente à primária. A configuração de topologias de replicação geográfica encadeadas só tem suporte programático e não no portal do Azure.
Replicação geográfica de bancos de dados em um pool elástico
Cada geosecundário pode ser um único banco de dados ou um banco de dados em um pool elástico. A escolha do pool elástico para cada banco de dados geosecundário é separada e não depende da configuração de nenhuma outra réplica na topologia (primária ou secundária). Cada pool elástico está contido em um único servidor lógico. Como os nomes de banco de dados em um servidor lógico devem ser exclusivos, vários geosecundários do mesmo primário nunca podem compartilhar um pool elástico.
Geo-failover e failback controlados pelo usuário
Um geosecundário que tenha terminado a propagação inicial pode ser explicitamente alternado para a função principal (failover) a qualquer momento pelo aplicativo ou pelo usuário. Durante uma interrupção em que o primário está inacessível, apenas o failover forçado pode ser usado, o que promove imediatamente um geo-secundário para ser o novo primário. Quando a interrupção é atenuada, o sistema torna automaticamente o primário recuperado um geo-secundário e atualiza-o com o novo primário. Devido à natureza assíncrona da replicação geográfica, as transações recentes podem ser perdidas durante failovers forçados se o primário falhar antes que essas transações sejam replicadas para um geosecundário. Quando um primário com vários geosecundários faz failover, o sistema reconfigura automaticamente as relações de replicação e vincula os geosecundários restantes ao primário recém-promovido, sem exigir qualquer intervenção do usuário. Depois que a interrupção que causou o failover geográfico for atenuada, talvez seja desejável retornar o primário à sua região original. Para fazer isso, execute um failover manual.
Réplica em espera
Se sua réplica secundária for usada apenas para recuperação de desastres (DR) e não tiver nenhuma carga de trabalho de leitura ou gravação, você poderá designá-la como em espera para economizar nos custos de licenciamento.
Prepare-se para failover geográfico
Para garantir que seu aplicativo possa acessar imediatamente o novo primário após o failover geográfico, valide se a autenticação e o acesso à rede para o servidor secundário estão configurados corretamente. Para obter detalhes, consulte Segurança do Banco de dados SQL após a recuperação de desastres. Valide também se a política de retenção de backup no banco de dados secundário corresponde à do banco de dados principal. Essa configuração não faz parte do banco de dados e não é replicada do principal. Por padrão, o geosecundário é configurado com um período de retenção PITR padrão de sete dias. Para obter detalhes, consulte Backups automatizados do Banco de dados SQL.
Importante
Se o banco de dados for membro de um grupo de failover, não será possível iniciar o failover usando o comando de failover de replicação geográfica. Use o comando failover para o grupo. Se você precisar fazer failover de um banco de dados individual, deverá removê-lo do grupo de failover primeiro. Consulte Grupos de failover para obter detalhes.
Configurar geo-secundário
Tanto o primário quanto o geosecundário devem ter a mesma camada de serviço. Também é altamente recomendável que o geo-secundário seja configurado com a mesma redundância de armazenamento de backup, camada de computação (provisionada ou sem servidor) e tamanho de computação (DTUs ou vCores) que o principal. Se o primário estiver enfrentando uma carga de trabalho de gravação pesada, um geosecundário com um tamanho de computação menor pode não ser capaz de acompanhar. Isso causa atraso de replicação no geo-secundário e pode, eventualmente, causar a indisponibilidade do geo-secundário. Para mitigar esses riscos, a replicação geográfica ativa reduz (limita) a taxa de log de transações do primário, se necessário, para permitir que seus secundários se atualizem.
Outra consequência de uma configuração geosecundária desequilibrada é que, após o failover, o desempenho do aplicativo pode ser prejudicado devido à capacidade de computação insuficiente do novo primário. Nesse caso, é necessário aumentar a escala do banco de dados para ter recursos suficientes, o que pode levar um tempo significativo e requer um failover de alta disponibilidade no final do processo de expansão, o que pode interromper as cargas de trabalho do aplicativo.
Se você decidir criar o geosecundário com uma configuração diferente, deverá monitorar a taxa de E/S de log no primário ao longo do tempo. Isto permite-lhe estimar o tamanho de computação mínimo da georreplicação secundária necessário para manter a carga de replicação. Por exemplo, se seu banco de dados primário for P6 (1000 DTU) e sua E/S de log for sustentada em 50%, o geosecundário precisará ser pelo menos P4 (500 DTU). Para recuperar dados históricos de E/S de log, use a visualização sys.resource_stats . Para recuperar dados de E/S de log recentes com maior granularidade que reflita melhor picos de curto prazo, use a visualização sys.dm_db_resource_stats .
Gorjeta
A limitação de E/S do log de transações no primário devido ao menor tamanho de computação em um geosecundário é relatada usando o tipo de espera HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO, visível nas exibições sys.dm_exec_requests e sys.dm_os_wait_stats banco de dados.
A E/S do log de transações no primário pode ser limitada por motivos não relacionados ao menor tamanho de computação em um geosecundário. Esse tipo de limitação pode ocorrer mesmo que o geosecundário tenha o mesmo tamanho de computação ou maior que o primário. Para obter detalhes, incluindo tipos de espera para diferentes tipos de limitação de E/S de log, consulte Governança da taxa de log de transações.
Por padrão, a redundância de armazenamento de backup do geosecundário é a mesma do banco de dados primário. Você pode optar por configurar um geo-secundário com uma redundância de armazenamento de backup diferente. Os backups são sempre feitos no banco de dados primário. Se o secundário estiver configurado com uma redundância de armazenamento de backup diferente, após um failover geográfico, quando o secundário geográfico for promovido para o principal, novos backups serão armazenados e cobrados de acordo com o tipo de armazenamento (RA-GRS, ZRS, LRS) selecionado no novo primário (secundário anterior).
Economize em custos com a réplica em espera
Se sua réplica secundária for usada apenas para recuperação de desastres (DR) e não tiver cargas de trabalho de leitura ou gravação, você poderá economizar nos custos de licenciamento designando o banco de dados para espera ao configurar uma nova relação de replicação geográfica ativa.
Analise a réplica em espera sem licença para saber mais.
Georreplicação entre subscrições
Use Transact-SQL (T-SQL) para criar um geosecundário em uma assinatura diferente da assinatura do primário (seja sob o mesmo locatário do Microsoft Entra ID (anteriormente Azure Ative Directory) ou não). Consulte Configurar replicação geográfica ativa para saber mais.
Mantenha as credenciais e as regras de firewall sincronizadas
Ao usar o acesso à rede pública para se conectar ao banco de dados, recomendamos o uso de regras de firewall IP no nível de banco de dados para bancos de dados replicados geograficamente. Essas regras são replicadas com o banco de dados, o que garante que todos os geosecundários tenham as mesmas regras de firewall IP do primário. Essa abordagem elimina a necessidade de os clientes configurarem e manterem manualmente regras de firewall em servidores que hospedam os bancos de dados primários e secundários. Da mesma forma, o uso de usuários de banco de dados contidos para acesso a dados garante que os bancos de dados primários e secundários sempre tenham as mesmas credenciais de autenticação. Dessa forma, após um failover geográfico, não há interrupções devido a incompatibilidades de credenciais de autenticação. Se você estiver usando logins e usuários (em vez de usuários contidos), deverá tomar medidas adicionais para garantir que os mesmos logons existam para seu banco de dados secundário. Para obter detalhes de configuração, consulte Como configurar logins e usuários.
Dimensionar a base de dados primária
Você pode aumentar ou reduzir a escala do banco de dados primário para um tamanho de computação diferente (dentro da mesma camada de serviço) sem desconectar nenhum geo-secundário. Ao aumentar verticalmente, recomendamos que comece por aumentar verticalmente a instância de georreplicação secundária e, em seguida, a principal. Ao reduzir verticalmente, inverta a ordem: comece por reduzir verticalmente a principal e, em seguida, a secundária.
Nota
Se tiver criado uma geográfica secundária como parte da configuração do grupo de ativação pós-falha, não se recomenda reduzir verticalmente. Trata-se de garantir que a camada de dados tem capacidade suficiente para processar a carga de trabalho habitual após uma ativação pós-falha geográfica.
Importante
O banco de dados primário em um grupo de failover não pode ser dimensionado para uma camada de serviço mais alta (edição), a menos que o banco de dados secundário seja primeiro dimensionado para a camada mais alta. Por exemplo, se você quiser escalar o primário de Propósito Geral para Crítico de Negócios, primeiro terá que dimensionar o geosecundário para Crítico de Negócios. Se você tentar dimensionar o primário ou geosecundário de uma forma que viole essa regra, você receberá o seguinte erro:
The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.
Evitar a perda de dados críticos
Devido à alta latência das redes de longa distância, a replicação geográfica usa um mecanismo de replicação assíncrona. A replicação assíncrona torna inevitável a possibilidade de perda de dados se o primário falhar. Para proteger transações críticas contra perda de dados, um desenvolvedor de aplicativos pode chamar o sp_wait_for_database_copy_sync procedimento armazenado imediatamente após confirmar a transação. A chamada bloqueia o thread de chamada sp_wait_for_database_copy_sync até que a última transação confirmada tenha sido transmitida e reforçada no log de transações do banco de dados secundário. No entanto, não espera que as transações transmitidas sejam repetidas (refeitas) no secundário. sp_wait_for_database_copy_sync tem como escopo um link de replicação geográfica específico. Qualquer usuário com direitos de conexão com o banco de dados primário pode chamar este procedimento.
Nota
sp_wait_for_database_copy_sync Evita a perda de dados após failover geográfico para transações específicas, mas não garante a sincronização completa para acesso de leitura. O atraso causado por uma sp_wait_for_database_copy_sync chamada de procedimento pode ser significativo e depende do tamanho do log de transações ainda não transmitido no primário no momento da chamada.
Monitorizar o atraso da georreplicação
Para monitorizar o atraso em relação ao RPO, utilize a coluna replication_lag_sec de sys.dm_geo_replication_link_status na base de dados primária. Mostra o atraso em segundos entre as transações consolidadas na primária e protegidas no registo de transações na secundária. Por exemplo, se o atraso for de um segundo, significa que, se a primária for afetada por uma indisponibilidade neste momento e for iniciada uma ativação pós-falha de georreplicação, as transações consolidadas no último segundo serão perdidas.
Para medir o atraso em relação às alterações no banco de dados primário que foram reforçadas no geosecundário, compare last_commit tempo no geosecundário com o mesmo valor no primário.
Gorjeta
Se replication_lag_sec no primário for NULL, isso significa que o primário não sabe atualmente o quão atrás de um geo-secundário está. Isso normalmente acontece após o processo ser reiniciado e deve ser uma condição transitória. Considere enviar um alerta se replication_lag_sec retornar NULL por um longo período de tempo. Isso pode indicar que o geo-secundário não pode se comunicar com o primário devido a uma falha de conectividade.
Há também condições que podem fazer com que a diferença entre last_commit tempo no geo-secundário e no primário se torne grande. Por exemplo, se uma confirmação for feita no primário após um longo período sem alterações, a diferença saltará para um valor grande antes de retornar rapidamente a zero. Considere enviar um alerta se a diferença entre esses dois valores permanecer grande por muito tempo.
Gerencie programaticamente a replicação geográfica ativa
Como discutido anteriormente, a replicação geográfica ativa também pode ser gerenciada programaticamente usando T-SQL, Azure PowerShell e API REST. As tabelas a seguir descrevem o conjunto de comandos disponíveis. A replicação geográfica ativa inclui um conjunto de APIs do Azure Resource Manager para gerenciamento, incluindo a API REST do Banco de Dados SQL do Azure e cmdlets do Azure PowerShell. Essas APIs dão suporte ao controle de acesso baseado em função do Azure (Azure RBAC). Para obter mais informações sobre como implementar funções de acesso, consulte Controle de acesso baseado em função do Azure (Azure RBAC).
T-SQL: gerencie o failover geográfico de bancos de dados únicos e em pool
Importante
Esses comandos T-SQL só se aplicam à replicação geográfica ativa e não se aplicam a grupos de failover. Como tal, eles também não se aplicam à Instância Gerenciada SQL, que só oferece suporte a grupos de failover.
| Comando | Description |
|---|---|
| ALTER DATABASE | Use o argumento ADD SECONDARY ON SERVER para criar um banco de dados secundário para um banco de dados existente e iniciar a replicação de dados |
| ALTER DATABASE | Use FAILOVER ou FORCE_FAILOVER_ALLOW_DATA_LOSS para alternar um banco de dados secundário para ser primário para iniciar o failover |
| ALTER DATABASE | Use REMOVE SECONDARY ON SERVER para encerrar uma replicação de dados entre um Banco de dados SQL e o banco de dados secundário especificado. |
| sys.geo_replication_links | Retorna informações sobre todos os links de replicação existentes para cada banco de dados em um servidor. |
| sys.dm_geo_replication_link_status | Obtém o último tempo de replicação, o último atraso de replicação e outras informações sobre o link de replicação para um determinado banco de dados. |
| sys.dm_operation_status | Mostra o status de todas as operações de banco de dados, incluindo alterações em links de replicação. |
| sys.sp_wait_for_database_copy_sync | Faz com que o aplicativo aguarde até que todas as transações confirmadas sejam reforçadas para o log de transações de um geo-secundário. |
PowerShell: gerencie o failover geográfico de bancos de dados únicos e em pool
Nota
Este artigo usa o módulo Azure Az PowerShell, que é o módulo PowerShell recomendado para interagir com o Azure. Para começar a utilizar o módulo Azure PowerShell, veja Instalar o Azure PowerShell. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.
Importante
O módulo PowerShell Azure Resource Manager ainda é suportado pelo Banco de Dados SQL do Azure, mas todo o desenvolvimento futuro é para o módulo Az.Sql. Para esses cmdlets, consulte AzureRM.Sql. Os argumentos para os comandos no módulo Az e nos módulos AzureRm são substancialmente idênticos.
| Cmdlet | Description |
|---|---|
| Get-AzSqlDatabase | Obtém uma ou mais bases de dados. |
| New-AzSqlDatabaseSecondary | Cria uma base de dados secundária para uma base de dados existente e começa a replicação de dados. |
| Set-AzSqlDatabaseSecondary | Muda uma base de dados secundária para primária, para iniciar a ativação pós-falha. |
| Remove-AzSqlDatabaseSecondary | Termina a replicação de dados entre uma Base de Dados SQL e a base de dados secundária especificada. |
| Get-AzSqlDatabaseReplicationLink | Obtém os links de replicação geográfica para um banco de dados. |
Gorjeta
Para scripts de exemplo, consulte Configurar e fazer failover de um único banco de dados usando replicação geográfica ativa e Configurar e fazer failover de um banco de dados em pool usando replicação geográfica ativa.
API REST: gerencie o failover geográfico de bancos de dados únicos e em pool
| API | Description |
|---|---|
| Criar ou atualizar banco de dados (createMode=Restore) | Cria, atualiza ou restaura um banco de dados primário ou secundário. |
| Obter Criar ou Atualizar Status do Banco de Dados | Retorna o status durante uma operação de criação. |
| Definir banco de dados secundário como primário (failover planejado) | Define qual banco de dados secundário é primário fazendo failover do banco de dados primário atual. Esta opção não é suportada para a Instância Gerenciada SQL. |
| Definir banco de dados secundário como primário (failover não planejado) | Define qual banco de dados secundário é primário fazendo failover do banco de dados primário atual. Esta operação pode resultar em perda de dados. Esta opção não é suportada para a Instância Gerenciada SQL. |
| Obter link de replicação | Obtém um link de replicação específico para um determinado banco de dados em uma parceria de replicação geográfica. Ele recupera as informações visíveis na exibição de catálogo sys.geo_replication_links. Esta opção não é suportada para a Instância Gerenciada SQL. |
| Links de replicação - Lista por banco de dados | Obtém todos os links de replicação para um determinado banco de dados em uma parceria de replicação geográfica. Ele recupera as informações visíveis na exibição de catálogo sys.geo_replication_links. |
| Excluir link de replicação | Exclui um link de replicação de banco de dados. Não é possível fazer o failover durante o failover. |
Próximos passos
- Para obter scripts de exemplo, consulte:
- Configure e faça failover de um único banco de dados usando replicação geográfica ativa.
- Configure e faça failover de um banco de dados em pool usando replicação geográfica ativa.
- O Banco de dados SQL também oferece suporte a grupos de failover. Para obter mais informações, consulte Usando grupos de failover.
- Para obter uma visão geral e cenários de continuidade de negócios, consulte Visão geral de continuidade de negócios.
- Economize nos custos de licenciamento designando sua réplica de DR secundária para espera.
- Para saber mais sobre a Réplica Geográfica de Hiperescala da Base de Dados SQL do Azure, consulte Réplica geográfica de hiperescala
- Para saber mais sobre backups automatizados do Banco de Dados SQL do Azure, consulte Backups automatizados do Banco de Dados SQL.
- Para saber mais sobre como usar backups automatizados para recuperação, consulte Restaurar um banco de dados a partir dos backups iniciados pelo serviço.
- Para saber mais sobre os requisitos de autenticação para um novo servidor primário e banco de dados, consulte Segurança do Banco de dados SQL após recuperação de desastres.