Fazer backup de grupos de disponibilidade sempre ativos do SQL Server

O Backup do Azure oferece um suporte completo para fazer backup do SQL Server sempre em grupos de disponibilidade (AG) se todos os nós estiverem na mesma região e assinatura que o cofre dos Serviços de Recuperação. No entanto, se os nós AG estiverem espalhados entre regiões/assinaturas/instalações locais e no Azure, há algumas considerações a ter em mente.

Para visualizar os cenários de backup e restauração aos quais damos suporte atualmente, consulte a matriz de suporte. Para perguntas comuns, consulte as perguntas frequentes.

Comportamento de preferência de backup pela versão do SQL Server

O suporte total e diferencial de backups em réplicas secundárias depende da versão do SQL Server. A preferência de backup AG e a versão do SQL Server determinam o nó escolhido para cada tipo de backup.

SQL Server 2022 e anteriores

A preferência de backup usada pelo Azure Backup SQL AG dá suporte a backups completos e diferenciais somente da réplica primária. Portanto, esses trabalhos de backup sempre são executados no nó principal, independentemente da preferência de backup. Para backups somente cópia completos e de log de transações, a preferência de backup AG é considerada ao decidir o nó onde o backup será executado.

SQL Server 2025 e posteriores

No SQL Server 2025 e posteriores, as réplicas secundárias também suportam backups completos e diferenciais. A preferência de backup agora governa ambos os tipos de backup de forma uniforme. Quando defines Apenas Secundário ou Prefere Secundário, backups completos e diferenciais já não requerem o nó primário.

Quando registas um nó no serviço Azure Backup, instalas a extensão de backup da carga de trabalho nesse nó. Quando configuras uma base de dados AG para backup, os cronogramas de backup são enviados para todos os nós registados do AG. Os agendamentos são acionados em todos os nós do AG, e as extensões de cópia de segurança da carga de trabalho nesses nós sincronizam-se entre si para decidir qual o nó que pode efetuar a cópia de segurança. A seleção do nó depende do tipo de backup e da preferência de backup descrita em Comportamento de preferência de backup pela versão do SQL Server.

O nó selecionado prossegue com o trabalho de backup, enquanto o trabalho acionado nos outros nós é abortado, ou seja, ignora-se o trabalho.

Registar nós de disponibilidade no cofre do Recovery Services

Um cofre dos Serviços de Recuperação oferece suporte ao backup somente de bancos de dados de VMs na mesma região e assinatura que o cofre.

SQL Server 2022 e anteriores:

• Registe o nó principal no cofre (caso contrário, as cópias de segurança completas não poderão ser efetuadas).
• Registre pelo menos um nó secundário no vault (caso contrário, backups completos somente de log/cópia não poderão acontecer) se a preferência de backup for apenas secundária.

A configuração de backups para bancos de dados AG falhará com o código de erro FabricSvcBackupPreferenceCheckFailedUserError se as condições acima não forem atendidas.

SQL Server 2025 e posteriores:

• O registo do nó primário já não é obrigatório para a configuração de backup AG. Uma vez que as cópias de segurança completas e diferenciais podem agora ser executadas em réplicas secundárias, pode configurar cópias de segurança apenas com nós secundários registados (quando a preferência de backup for Apenas Secundário ou Preferir Secundário).
• Para a preferência de backup primário , o nó primário ainda deve estar registado.
• Regista pelo menos um nó que satisfaça a preferência de backup escolhida.

Vamos considerar a seguinte implantação do AG como uma referência.

Com base no exemplo de implantação do AG fornecido, a seguir estão várias considerações:

• Como o nó principal está na região 1 e na assinatura 1, o cofre dos Serviços de Recuperação (Vault 1) deve estar na Região 1 e na Assinatura 1 para proteger esta AG.
• VM3 não pode ser registrado no Vault 1, pois ele está em uma assinatura diferente.
• VM4 não pode ser registrado no Vault 1, pois ele está em uma região diferente.
• Se a preferência de backup for apenas secundária, regista VM1 (Principal) e VM2 (Secundária) no Vault 1. No SQL Server 2022 e anteriores, as cópias de segurança completas requerem o nó primário, por isso registe ambos os nós; no SQL Server 2025 e posteriores, a VM2, por si só, é suficiente. Para outras preferências de backup, registar VM1 (Primário) no Vault 1; O VM2 é opcional.
• Embora possa registar o VM3 no cofre 2 na subscrição 2 e as bases de dados AG fiquem então disponíveis para proteção no cofre 2, a configuração dos backups falharia no SQL Server 2022 e versões anteriores devido à ausência do nó principal no cofre 2. No SQL Server 2025 e em versões posteriores, pode configurar cópias de segurança no Vault 2 se a preferência de cópia de segurança for Só Secundária ou Preferir Secundária.
• De forma semelhante, embora possa registar a VM4 no cofre 4 na região 2, a configuração de cópias de segurança falharia no SQL Server 2022 e em versões anteriores, uma vez que o nó principal não está registado no cofre 4. No SQL Server 2025 e versões posteriores, pode configurar as cópias de segurança no vault 4 se a preferência de cópia de segurança for Secondary Only ou Prefer Secondary.

Lidar com comutação automática

Após o AG ter feito failover para um dos nós secundários:

• SQL Server 2022 e anteriores: Backups completos e diferenciais continuam a partir do novo nó primário se este estiver registado no cofre.
• SQL Server 2025 e posterior: As cópias de segurança completas e diferenciais prosseguem no nó que satisfaz a preferência de cópia de segurança. Para Só secundário ou Preferir secundário, estas cópias de segurança podem ser executadas numa réplica secundária.
• Os backups de log completos e cópias continuarão a ser realizados a partir do nó principal ou secundário, com base na preferência definida para backup.

Com base no exemplo de implantação de AG acima, a seguir estão as várias possibilidades de failover:

• Failover para VM2
  • Backups completos e diferenciais serão realizados a partir de VM2.
  • Os backups completos somente de log e cópia acontecerão a partir de VM1 ou VM2 com base na preferência de backup.
• Mudança automática para VM3 (outra assinatura)
  • Como os backups não estão configurados no Vault 2, nenhum backup aconteceria.
  • No SQL Server 2022 e em versões anteriores, se a preferência de cópia de segurança não for exclusivamente secundária, pode agora configurar cópias de segurança no Cofre 2 porque o nó principal está registado neste cofre. No SQL Server 2025 e versões posteriores, também pode configurar backups quando o nó registado no Vault 2 satisfaz a preferência de backup selecionada. Esta condição pode levar a conflitos ou falhas de backup. Para mais informações, consulte Configurar backups para um AG multi-região.
• Failover para VM4 (noutra região)
  • Como os backups não estão configurados no Vault 4, nenhum backup aconteceria.
  • No SQL Server 2022 e versões anteriores, se a preferência de cópia de segurança não for exclusivamente secundária, pode agora configurar cópias de segurança no Cofre 4 porque o nó primário está registado neste cofre. No SQL Server 2025 e versões posteriores, também pode configurar backups quando o nó registado no Vault 4 satisfaz a preferência de backup selecionada. Esta condição pode levar a conflitos ou falhas de backup. Para mais informações, consulte Configurar backups para um AG multi-região.

Configurar backups para uma AG de várias regiões

O cofre de serviços de recuperação não oferece suporte a backups entre assinaturas ou entre regiões. Esta seção resume como habilitar backups para AGs que abrangem assinaturas ou regiões do Azure e as considerações associadas.

• Avalie se você realmente precisa habilitar backups de todos os nós. Se uma região/assinatura tiver a maioria dos nós AG e o failover para outros nós acontecer muito raramente, configurar o backup nessa primeira região pode ser suficiente. Se os failovers para outra região/assinatura acontecerem com frequência e por um período prolongado, convém configurar backups proativamente na outra região também.

• Cada cofre onde o backup é habilitado terá seu próprio conjunto de cadeias de pontos de recuperação. As restaurações desses pontos de recuperação podem ser feitas somente em VMs registradas nesse cofre.

• SQL Server 2022 e anteriores: As cópias de segurança completas e diferenciais funcionam apenas no cofre que contém o nó primário. Estas cópias de segurança noutros cofres continuam a falhar. No SQL Server 2025 e versões posteriores, este comportamento muda com as preferências Apenas Secundário e Preferir Secundário - veja SQL Server 2025: alterações às cópias de segurança do AG multirregião.

• Os backups de log continuarão funcionando no cofre anterior até que um backup de log seja executado no novo cofre (ou seja, no cofre onde o novo nó primário está presente) e quebre a cadeia de logs do cofre antigo.

  Nota

  Há um limite rígido de 15 dias além do qual os backups de log começarão a falhar.

• Os backups completos somente para cópia funcionarão em todos os cofres.

• A proteção em cada repositório é tratada como uma fonte de dados distinta e é cobrada separadamente.

Para evitar conflitos de backup de log entre os dois cofres, recomendamos que você defina a preferência de backup como Principal. Em seguida, qualquer repositório que tenha o nó primário também realizará os backups de log.

SQL Server 2025: Alterações ao backup AG multi-região

Com o SQL Server 2025, backups completos e diferenciais deixam de requerer o nó primário. Esta alteração significa:

• O registo do nó primário não é obrigatório — Se a sua preferência de backup for Apenas Secundário ou Preferencialmente Secundário, pode configurar e executar backups a partir de qualquer nó secundário registado, mesmo que o nó primário esteja numa região ou subscrição diferente.

• Redução do impacto do failover — Após o failover para um nó numa região diferente, os backups podem continuar no vault original desde que exista um nó registado que satisfaça a preferência de backup.

No entanto, mantém-se a limitação fundamental da coordenação entre cofres — não é possível coordenar backups entre vários cofres. Se registar nós AG em diferentes cofres, em diferentes regiões, os agendamentos de cópia de segurança simultâneos podem entrar em conflito e causar quebras na cadeia de registos ou cópias de segurança duplicadas.

Recomendação para evitar conflitos entre cofres:

• AG de 2 nós: Defina a preferência de backup para Apenas Secundário ou Principal.
• AG de 3+ nós: Defina a preferência de cópia de segurança para Principal.

Esta configuração garante que apenas o nó de um único cofre está elegível para backups a qualquer momento.

Com base no exemplo de implantação do AG acima, aqui estão as etapas para ativar o backup a partir de todos os nós. A suposição é que a preferência de backup seja satisfeita em todas as etapas.

Etapa 1: ativar cópias de segurança na Região 1, Assinatura 1 (Vault 1)

Como o nó principal está associado à região e à subscrição, as etapas usuais para habilitar backups devem funcionar corretamente.

Etapa 2: habilitar backups na Região 1, Assinatura 2 (Vault 2)

1. Efetue o failover do AG para a VM3, de modo que o nó primário esteja presente no Vault 2.
2. Configurar cópias de segurança para os bancos de dados AG no Vault 2.
3. Neste ponto:
   1. Os backups completos/diferenciais falharão no Vault 1, pois nenhum dos nós registrados pode fazer esse backup.
   2. Os backups de log serão bem-sucedidos no Vault 1 até que um backup de log seja executado no Vault 2 e quebre a cadeia de logs do Vault 1.
4. Failback do AG para VM1.

Etapa 3: Ativar backups na Região 2, Assinatura 1 (Vault 4)

O mesmo que o Passo 2.

Fazer backup de um AG que abrange o Azure e o on-premises

O Backup do Azure para SQL Server não pode ser executado localmente. Se o nó primário estiver no Azure e a preferência de backup for satisfeita pelos nós no Azure, você poderá seguir as orientações acima para AG de várias regiões para habilitar backups para as réplicas no Azure. Se ocorrer um failover para o nó local, os backups completos e diferenciais no Azure começarão a falhar. Os backups de log podem continuar durante 15 dias ou até que ocorra uma quebra na cadeia de logs.

Limitação de tarefas de backup em um banco de dados AG

Atualmente, os limites de limitação de backup aplicam-se ao nível de cada máquina. O limite padrão é 20 – se mais de 20 backups forem acionados simultaneamente, os primeiros 20 serão executados e os outros ficarão na fila. Quando os trabalhos em execução estiverem concluídos, os trabalhos enfileirados começarão a ser executados.

Você pode alterar esse valor para um valor menor se os backups simultâneos estiverem causando tensão de memória/E/S/CPU no nó. Como a limitação está no nível do nó, ter nós AG desequilibrados pode levar a problemas de sincronização de backup. Para entender isso, considere um AG de 2 nós, por exemplo.

Por exemplo, o primeiro nó tem 50 bancos de dados autônomos protegidos e ambos os nós têm 5 bancos de dados AG protegidos. Efetivamente, o Nó 1 tem 55 trabalhos de backup de banco de dados agendados, enquanto o Nó 2 tem apenas 5. Além disso, todos esses backups são configurados para serem executados ao mesmo tempo, a cada hora. Em determinado momento, todos os 55 backups serão acionados no Nó 1 e 35 deles serão enfileirados. Alguns deles seriam as cópias de segurança da base de dados AG. Mas no Nó 2, os backups do banco de dados AG continuariam sem qualquer fila.

Como os trabalhos da base de dados AG ficam em fila num nó e correm noutro, a sincronização de backups não funciona corretamente. O Nó 2 pode presumir que o Nó 1 está em baixo e, por isso, as tarefas do Nó 1 não surgem para sincronização. Este problema pode levar a quebras na cadeia de logs ou a cópias de segurança adicionais, pois ambos os nós podem efetuar cópias de segurança de forma independente.

Problema semelhante pode acontecer se o número de bancos de dados AG protegidos for maior do que o limite de limitação. Nesse caso, o backup para, digamos, DB1 pode ser enfileirado no Nó 1 enquanto está em execução no Nó 2.

Recomendamos que você use as seguintes preferências de backup para evitar esses problemas de sincronização:

• Para um AG de 2 nós, defina a Preferência de backup para Apenas Primário ou Apenas Secundário – então, apenas um nó poderá fazer os backups, enquanto o outro sempre ficará inativo.
• Para um AG com mais de 2 nós, defina a Preferência de Backup para Principal – assim, apenas o nó principal poderá fazer os backups, enquanto os outros não participarão.

Faturamento de backups AG

Assim como uma instância SQL autônoma, uma instância AG de backup é considerada como uma instância protegida. O tamanho total do frontend de todos os bancos de dados protegidos em uma instância é cobrado. Considere a seguinte implantação:

As instâncias protegidas são calculadas da seguinte forma:

Mover uma base de dados protegida para dentro ou fora de uma AG

O Backup do Azure considera a instância SQL ou o nome AG\Nome do banco de dados como o nome exclusivo do banco de dados. Quando o banco de dados autônomo foi protegido, seu nome exclusivo foi StandAloneInstanceName\DBName. Quando se move sob um AG, o nome único muda para AGName\DBName. Os backups para o banco de dados autônomo começarão a falhar com o código de erro: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

O banco de dados deve ser configurado para proteção pelo AG. Isso será tratado como uma nova fonte de dados com uma cadeia de pontos de recuperação separada. A proteção mais antiga do banco de dados autônomo pode ser interrompida com a retenção de dados para evitar que backups futuros sejam acionados e falhem neles. Da mesma forma, quando um banco de dados AG protegido sai do AG e se torna um banco de dados autônomo, seus backups começam a falhar com o código de erro: UserErrorBackupFailedDatabaseMovedOutOfAG.

O banco de dados deve ser configurado para proteção sob a instância autônoma. Isso será tratado como uma nova fonte de dados com uma cadeia de pontos de recuperação separada. A proteção mais antiga do banco de dados AG pode ser interrompida com a retenção dos dados antigos para evitar que backups futuros sejam acionados e falhem devido a isso.

Adição ou remoção de um nó a um AG

Quando um novo nó é adicionado a um AG configurado para backups, as extensões de backup de carga de trabalho em execução nos nós AG já registrados detetam a alteração da topologia AG e informam o serviço de Backup do Azure durante o próximo trabalho agendado de descoberta de banco de dados. Quando esse novo nó é registrado para backups no mesmo cofre dos Serviços de Recuperação que os outros nós existentes, o serviço de Backup do Azure aciona um fluxo de trabalho que configura esse novo nó com os metadados necessários para executar backups AG.

Após este passo, o novo nó sincroniza a informação do cronograma de backup AG do serviço Azure Backup e começa a participar no processo de backup sincronizado. Se o novo nó não for capaz de sincronizar os agendamentos de backup e participar nos backups, iniciar um novo registo no nó forçará a reconfiguração do nó para os backups AG também. De forma semelhante, durante a remoção de nós, as extensões de carga de trabalho detetam a alteração da topologia AG e informam o serviço Azure Backup. O serviço inicia um fluxo de trabalho de desconfiguração de nó no nó removido para limpar os cronogramas de backup das bases de dados AG e eliminar os metadados relacionados com AG.

Desregistar um nó AG do Azure Backup

Se um nó fizer parte de um AG que tenha um ou mais bancos de dados configurados para backup, o Backup do Azure não permite o desregisto desse nó. Isso é para evitar futuras falhas de backup caso a preferência de backup não possa ser satisfeita sem este nó. Para cancelar o registro do nó, primeiro você precisa removê-lo do AG. Quando o fluxo de trabalho de desconfiguração do nó for concluído e esse nó for limpo, poderá removê-lo do registo.

Restaurar um banco de dados do Backup do Azure para um AG SQL Os Grupos de Disponibilidade não suportam a restauração direta de um banco de dados no AG. A base de dados precisa ser restaurada para uma instância SQL autónoma e, em seguida, precisa ser associada a um Grupo de Disponibilidade.

Cenários de recriação do grupo de disponibilidade para o servidor de banco de dados SQL

Recriação do grupo de disponibilidade (AG), AGs duplicados e os itens de backup são listados como itens protegíveis ou itens protegidos nos seguintes cenários:

• Ao recriar AGs que já estão protegidas, estas aparecem como AGs duplicadas na página Configurar Backup e na lista de Itens protegidos. Se você quiser reter os dados de backup que já estão presentes no AG mais antigo, interrompa o backup usando a opção Parar proteção e reter dados antes de recriar e agendar backups nos novos itens AG.

  Por conceção, o Azure Backup lista os itens duplicados na lista de Itens protegidos, na página Configurar Backup ou na lista de itens Protegíveis e exibe esses itens até que se pretenda reter os dados de backup.

• Se você não quiser os dados de backup do AG mais antigo, interrompa a operação de backup usando a opção Parar proteção e excluir dados para o item mais antigo antes de recriar e agendar backups no novo AG.

  Atenção

  Parar a proteção e excluir dados é uma operação destrutiva.

• Você pode recriar o AG depois de executar um dos processos de proteção Stop acima para evitar falhas de backup.

Considerações sobre backup do SQL Server 2025 AG

Alterações nas preferências de backup após a configuração

Se mudar a preferência de backup AG mas não registar o nó necessário no vault, os backups falham. Por exemplo, se mudar a preferência de Primário para Apenas Secundário mas nenhum nó secundário estiver registado, os backups de registo e Full/Diff falham. Certifique-se sempre de que os nós que satisfaçam a nova preferência de backup estão registados no cofre antes de fazer a alteração.

Coordenação de backup de AG multi-região

Quando proteges nós AG em vários cofres em regiões diferentes, os cofres não conseguem coordenar cópias de segurança entre si, independentemente da versão do SQL Server. Para obter orientações sobre as definições de preferência da cópia de segurança que evitam interrupções na cadeia de registos de transações e cópias de segurança duplicadas neste cenário, consulte SQL Server 2025: Alterações à cópia de segurança da AG multirregião.

Suporte para cópias de segurança por instantâneo

As cópias de segurança de instantâneo não são suportadas em réplicas secundárias de um AG. Quando ativas o backup snapshot na política de backup, o registo do nó principal continua a ser obrigatório independentemente da versão do SQL Server.

Próximos passos

Aprenda a:

• Restaurar bases de dados do SQL Server a partir de cópias de segurança
• Gerenciar bancos de dados SQL Server de backup

Conteúdo relacionado

• Faça backup de bancos de dados do SQL Server em VMs do Azure usando o Backup do Azure via API REST.
• Restaure bancos de dados do SQL Server em VMs do Azure com a API REST.
• Gerencie bancos de dados do SQL Server em VMs do Azure com o portal do Azure, CLI do Azure, API REST.