Instância de backup do SQL Server sempre ativada em grupos de disponibilidade

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

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

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

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

SQL Server 2022 e anteriores

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

SQL Server 2025 e posterior

No SQL Server 2025 e posterior, as réplicas secundárias também dão suporte a backups completos e diferenciais. A preferência de backup agora rege os dois tipos de backup uniformemente. Ao definir Somente Secundário ou Preferir Secundário, backups completos e diferenciais não exigirão mais o nó primário.

Quando você registra um nó com o serviço Backup do Azure, instala a extensão de backup de carga de trabalho nesse nó. Ao configurar um banco de dados do AG para backup, os agendamentos de backup são enviados para todos os nós registrados do AG. Os agendamentos são executados em todos os nós do AG e as extensões de backup de carga de trabalho nesses nós são sincronizadas entre si para decidir qual nó pode realizar o backup. A seleção do nó depende do tipo de backup e da preferência de backup descrita em comportamento da preferência de backup por versão do SQL Server.

O nó selecionado continua com o trabalho de backup, enquanto o trabalho disparado nos outros nós sai, ou seja, ignora o trabalho.

Registrar nós do AG no cofre dos Serviços de Recuperação

Um cofre dos Serviços de Recuperação suporta backup de bancos de dados somente de VMs na mesma região e assinatura do cofre.

SQL Server 2022 e anteriores:

• Registre o nó primário no cofre (caso contrário, backups completos não poderão ser realizados).
• Registre pelo menos um nó secundário no cofre (caso contrário, os backups completos somente de log/cópia não poderão ser realizados) se a preferência de backup for somente secundário.

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 registro de nó primário não é mais obrigatório para a configuração de backup do AG. Como os backups completos e diferenciais agora podem ser executados em réplicas secundárias, você pode configurar backups com apenas nós secundários registrados (quando a preferência de backup é Secundária Somente ou Preferir Secundário).
• Na preferência de backup Primário, o nó primário ainda deve estar registrado.
• Registre pelo menos um nó que satisfaça a preferência de backup escolhida.

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

Com base na amostra fornecida de implantação do AG, a seguir estão várias considerações:

• Como o nó primário está nas região 1 e na assinatura 1, o cofre dos Serviços de Recuperação (Cofre 1) deve estar na Região 1 e na Assinatura 1 para proteger esse AG.
• VM3 não pode ser registrado no Vault 1, pois está em uma assinatura diferente.
• VM4 não pode ser registrado no Vault 1, pois está em uma região diferente.
• Se a preferência de backup for somente secundário, registre a VM1 (Primária) e a VM2 (Secundária) no Cofre 1. No SQL Server 2022 e anteriores, os backups completos exigem o nó primário, portanto, registre ambos os nós. No SQL Server 2025 e posterior, somente a VM2 é suficiente. Para outras preferências de backup, registre VM1 (Primário) no Cofre 1; A VM2 é opcional.
• Embora você possa registrar a VM3 no cofre 2 na assinatura 2, e os bancos de dados do AG passariam a aparecer para proteção no cofre 2, a configuração dos backups teria falha no SQL Server 2022 e versões anteriores devido à ausência do nó primário no cofre 2. No SQL Server 2025 e posterior, você pode configurar backups no cofre 2 se a preferência de backup for Somente Secundário ou Preferir Secundário.
• Da mesma forma, embora você possa registrar a VM4 no cofre 4 na região 2, a configuração de backups falhará no SQL Server 2022 e anterior, já que o nó primário não está registrado no cofre 4. No SQL Server 2025 e posterior, você pode configurar backups no cofre 4 se a preferência de backup for Somente Secundário ou Preferir Secundário.

Failover de identificador

Depois que o AG tiver passado por um dos nós secundários:

• SQL Server 2022 e anteriores: os backups completos e diferenciais continuarão a partir do novo nó primário, caso ele esteja registrado no cofre.
• SQL Server 2025 e posteriores: os backups completos e diferenciais continuam a partir do nó que atende à preferência de backup. Para Secundário Somente ou Preferir Secundário, esses backups podem ser executados em uma réplica secundária.
• Os backups completos de log e somente cópia continuarão do nó primário/secundário com base na preferência de backup.

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

• Failover para VM2
  • Backups completos e diferenciais ocorrerão a partir da VM2.
  • Os backups completos somente cópia e de log ocorrerão da VM1 ou da VM2 com base na preferência de backup.
• Failover para VM3 (outra assinatura)
  • Como os backups não são configurados no Cofre 2, nenhum backup ocorreria.
  • No SQL Server 2022 e anteriores, se a preferência de backup não for somente secundária, agora você poderá configurar backups no Cofre 2 porque o nó primário está registrado nesse cofre. No SQL Server 2025 e versões posteriores, você também pode configurar backups se o nó registrado no Vault 2 atender à preferência de backup selecionada. Essa condição pode levar a conflitos ou falhas de backup. Para obter mais informações, consulte Configurar backups para um AG de várias regiões.
• Failover para VM4 (outra região)
  • Como os backups não estão configurados no Cofre 4, nenhum backup ocorrerá.
  • No SQL Server 2022 e em versões anteriores, se a preferência de backup não for apenas secundária, agora é possível configurar backups no Cofre 4 porque o nó primário está registrado nesse cofre. No SQL Server 2025 e versões posteriores, você também pode configurar backups quando o nó registrado no Cofre 4 atender à preferência de backup selecionada. Essa condição pode levar a conflitos ou falhas de backup. Para obter mais informações, consulte Configurar backups para um AG de várias regiões.

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

O cofre dos Serviços de Recuperação não oferece suporte a backups de assinatura cruzada. 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 do AG e o failover para outros nós ocorrer muito raramente, configurar o backup nessa primeira região poderá ser suficiente. Se os failovers para outra região/assinatura ocorrerem com frequência e por duração prolongada, talvez você queira configurar backups proativamente na outra região também.

• Cada cofre em que 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: os backups completos e diferenciais funcionam somente no cofre que contém o nó primário. Esses backups em outros cofres continuam falhando. No SQL Server 2025 e em versões posteriores, esse comportamento muda para as preferências Secondary Only e Prefer Secondary - consulte SQL Server 2025: Multi-Region AG backup changes.

• 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 em que o novo nó primário está presente) e interrompa a cadeia de logs do cofre antigo.

  Observação

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

• Backups completos do tipo somente cópia funcionarão em todos os repositórios.

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

Para evitar conflitos de backup de log entre os dois cofres, recomendamos definir a preferência de backup como Primária. Em seguida, o cofre que tiver o nó primário também fará os backups de log.

SQL Server 2025: alterações no backup do AG multirregional

Com SQL Server 2025, backups completos e diferenciais não exigem mais o nó primário. Essa alteração significa:

• O registro do nó primário não é necessário — se sua preferência de backup for Somente Secundário ou Preferir Secundário, você poderá configurar e executar backups em qualquer nó secundário registrado, mesmo que o nó primário esteja em outra região ou assinatura.

• Impacto reduzido do failover — após o failover para um nó em uma região diferente, os backups podem continuar no cofre original, desde que um nó registrado que atenda à preferência de backup esteja disponível.

No entanto, a limitação fundamental da coordenação entre vários cofres permanece — não é possível coordenar backups entre vários cofres. Se você registrar nós do AG em diferentes cofres em diferentes regiões, agendamentos de backup simultâneos poderão entrar em conflito e causar interrupções na cadeia de logs ou backups duplicados.

Recomendação para evitar conflitos entre cofres:

• AG de 2 nós: defina a preferência de backup como Secundária Somente ou Primária.
• AG de mais de três nós: defina a preferência de backup como Primário.

Essa configuração garante que somente o nó de um cofre esteja elegível para backups a qualquer momento.

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

Etapa 1: Habilitar backups na Região 1, Assinatura 1 (Cofre 1)

Como o nó primário está na região e na assinatura, as etapas comuns para habilitar backups funcionarão.

Etapa 2: Habilitar backups na Região 1, Assinatura 2 (Cofre 2)

1. Failover do AG para VM3 para que o nó primário está presente no Cofre 2.
2. Configure backups para os bancos de dados do AG no Cofre 2.
3. Neste ponto:
   1. Os backups completos/diferenciais falharão no Cofre 1, pois nenhum dos nós registrados pode fazer esse backup.
   2. Os backups de log terão êxito no Vault 1 até que um backup de log seja executado no Vault 2 e quebre a cadeia de logs do Vault 1.
4. Realizar o failback do AG para a VM1.

Etapa 3: Habilitar backups na Região 2, Assinatura 1 (Cofre 4)

O mesmo que a Etapa 2.

Fazer backup de um AG que abrange o Azure e o local

Backup do Microsoft 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 atendida pelos nós no Azure, você poderá seguir as diretrizes acima para o 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 logs podem continuar até que ocorra uma quebra na cadeia de logs ou até que se passem 15 dias.

A limitação para trabalhos de backup em um banco de dados AG

Atualmente, os limites de limitação de backup se aplicam em um nível de computador individual. O limite padrão é 20 – se mais de 20 backups forem disparados simultaneamente, os primeiros 20 serão executados e os outros serão colocados na fila. Quando os trabalhos em execução forem concluídos, os itens na fila começarão a ser executados.

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

Por exemplo, o primeiro nó tem 50 bancos de dados autônomos protegidos e ambos os nós têm 5 bancos de dados do AG protegidos. De fato, o nó 1 tem 55 tarefas de backup de banco de dados agendadas, 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 um ponto, todos os 55 backups serão disparados no nó 1 e 35 deles serão colocados na fila. Alguns desses seriam os backups de banco de dados AG. Mas, no nó 2, os backups do banco de dados do AG continuarão sem nenhum enfileiramento.

Como os trabalhos do banco de dados do AG são enfileirados em um nó e executados em outro, a sincronização de backup não funciona corretamente. O Nó 2 pode supor que o Nó 1 está inoperante e, portanto, os trabalhos do Nó 1 não estão chegando para sincronização. Esse problema pode levar a quebras de cadeia de logs ou backups extras, pois ambos os nós podem fazer backups de forma independente.

Um problema semelhante pode ocorrer se o número de bancos de dados do 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 ele é executado 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 do Microsoft Azure como primária ou secundária apenas. em seguida, somente um nó pode fazer os backups, o outro sempre se desaparecerá.
• Para um AG com mais de 2 nós, defina a preferência de Backup do Microsoft Azure para primário e, em seguida, somente o nó primário poderá fazer os backups, outros serão desativados.

Cobrança para backups do AG

O mesmo que uma instância SQL autônoma, uma instância AG com backup é considerada uma instância protegida. O tamanho total de front-end 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 maneira:

Mover um banco de dados protegido para dentro ou para fora de um AG

O Backup do Microsoft Azure considera Instância SQL ou nome do AG/nome do banco de dados como o nome exclusivo do banco de dados. Quando o BD autônomo foi protegido, seu nome exclusivo era StandAloneInstanceName\DBName. Quando ele se move para um AG, o nome exclusivo é alterado para AGName\DBName. Os backups do 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 sob o 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 os backups futuros disparem e falhem nele. 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 a partir da 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 do AG pode ser interrompida com a retenção de dados para evitar que os backups futuros disparem e falhem nele.

Adição ou remoção de um nó para 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 do AG já registrados detectam a alteração de topologia no AG e informam o serviço de Backup do Microsoft Azure durante o próximo trabalho de descoberta de banco de dados agendado. 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 Microsoft Azure dispara um fluxo de trabalho que configura esse novo nó com os metadados necessários para executar backups do AG.

Após essa etapa, o novo nó sincroniza as informações de agendamento de backup do AG com o serviço Backup do Azure e começa a participar do processo de backup sincronizado. Se o novo nó não puder sincronizar os agendamentos de backup e participar de backups, disparar um novo registro no nó forçará a reconfiguração do nó para backups do AG também. Da mesma forma, durante a remoção de nó, as extensões de carga de trabalho detectam a alteração da topologia no AG e informam o serviço de Backup do Azure. O serviço inicia um fluxo de trabalho de desconfiguração no nó removido para limpar os agendamentos de backup dos bancos de dados do AG e excluir os metadados relacionados ao AG.

Cancelar o registro de um nó do AG do Backup do Azure

Se um nó fizer parte de um AG que tenha um ou mais bancos de dados configurados para backup, o Backup do Microsoft Azure não permitirá o cancelamento do registro desse nó. Isso é para evitar falhas de backup futuras caso a preferência de backup não possa ser atendida sem esse 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, limpando esse nó, você poderá cancelar seu registro.

Restaurar um banco de dados do Backup do Microsoft Azure para um grupo de disponibilidade do AG SQL não tem suporte à restauração direta de um banco de dados no AG. O banco de dados precisa ser restaurado para uma instância SQL autônoma e, em seguida, precisa ser adicionado a um Grupo de Disponibilidade (AG).

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

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

• A recriação dos AGs que já estão protegidos aparece como AGs duplicados 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 retenha dados antes de recriar e agendar backups nos novos itens do AG.

  Por design, o Backup do Azure lista os itens duplicados na lista de itens protegidos e a página Configurar Backup ou lista de itens protegíveis e exibe esses itens até que você queira 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 exclua dados para o item mais antigo antes de recriar e agendar backups no novo AG.

  Cuidado

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

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

Considerações sobre backup do AG do SQL Server 2025

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

Se você alterar a preferência de backup do AG, mas não registrar o nó necessário no cofre, os backups falharão. Por exemplo, se você alterar a preferência de Primário para Somente Secundário, mas nenhum nó secundário estiver registrado, os backups de log e completo/diferencial terão falha. Sempre verifique se os nós que atendem à nova preferência de backup estão registrados no cofre antes de fazer a alteração.

Coordenação de backup multirregional do AG

Quando você protege nós do AG em vários cofres em diferentes regiões, os cofres não podem coordenar os backups entre si, independentemente da versão do SQL Server. Para obter diretrizes sobre as configurações de preferência de backup que evitam quebras de cadeia de logs e backups duplicados neste cenário, consulte SQL Server 2025: Alterações de backup do AG de várias regiões.

Suporte ao backup de instantâneo

Não há suporte a backups de instantâneo em réplicas secundárias de um AG. Quando você ativa o backup por instantâneo na política de backup, o registro do nó primário permanece obrigatório, independentemente da versão do SQL Server.

Próximas etapas

Saiba como:

• Restaurar bancos de dados do SQL Server com backup
• Gerenciar bancos de dados do SQL Server com backup

Conteúdo relacionado

• Faça backup de bancos de dados do SQL Server em VMs do Azure usando o Backup do Azure por meio da API REST.
• Restaurar 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, a CLI do Azure, a API REST.