Partilhar via

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.

Nota

  • O Backup de bancos de dados do Grupo de Disponibilidade Básica não é suportado pelo Backup do Azure.
  • Consulte a matriz de suporte a backup SQL para saber mais sobre as configurações e cenários suportados.

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.

Preferência AG Backup Backups completos e de comparação são executados em Os backups de cópia apenas e de log são realizados a partir de
Primário Réplica primária Réplica primária
Apenas secundário Réplica primária Qualquer uma das réplicas secundárias
Prefira a opção secundária Réplica primária As réplicas secundárias são preferidas, mas os backups também podem ser executados na réplica primária.
Nenhum/Qualquer Réplica primária Qualquer réplica

A extensão de backup de carga de trabalho é instalada no nó quando você a registra no serviço de Backup do Azure. Quando um banco de dados AG é configurado para backup, as agendas de backup são enviadas por push para todos os nós registrados do AG. As agendas são acionadas em todos os nós AG e as extensões de backup de carga de trabalho nesses nós são sincronizadas entre si para decidir qual nó pode executar o backup. A seleção do nó depende do tipo de backup e da preferência de backup, conforme explicado na seção 1.

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

Nota

O Backup do Azure não considera prioridades de backup ou réplicas ao decidir entre as réplicas secundárias.

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.

  • 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.

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

Diagrama para a implantação de AG como 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ário, VM1 (Principal) e VM2 (Secundário) deverão ser registados no Vault 1 (porque backups completos exigem o nó primário e os logs exigem um nó secundário). Para outras preferências de backup, o VM1 (Principal) deve ser registrado no Vault 1, o VM2 é opcional (porque todos os backups podem ser executados no nó primário).
  • Embora o VM3 pudesse ser registado no vault 2 na assinatura 2 e as bases de dados AG aparecessem para proteção no vault 2, no entanto, devido à ausência do nó principal no vault 2, a configuração de cópias de segurança falharia.
  • Da mesma forma, embora o VM4 pudesse ser registrado no vault 4 na região 2, a configuração de backups falharia, já que o nó principal não está registrado no vault 4.

Lidar com comutação automática

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

  • Os backups completos e diferenciais continuarão a partir do novo nó principal, se este estiver registado no sistema de armazenamento seguro.
  • 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.

Nota

As quebras da cadeia de logs não acontecem durante o failover se este não coincidir com um 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.
    • Se a preferência de backup não for apenas secundária, os backups podem ser configurados agora no Vault 2, porque o nó principal está registrado nesse Vault. Mas isso pode levar a conflitos/falhas de backup. Mais informações sobre isso em Configurar backups para um AG de várias regiões.
  • Failover para VM4 (noutra região)
    • Como os backups não estão configurados no Vault 4, nenhum backup aconteceria.
    • Se a preferência de backup não for somente secundária, os backups podem ser configurados agora no Vault 4, porque o nó principal está registrado nesse cofre. Mas isso pode levar a conflitos/falhas de backup. Mais informações sobre isso em Configurar backups para um AG de várias regiões.

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.

  • Os backups completos/diferenciais acontecerão com êxito somente no cofre onde está o nó principal. Esses backups em outros cofres continuarão falhando.

  • 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.

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.

Faça backup de um Grupo de Disponibilidade que abrange o Azure e o ambiente local.

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 do banco de dados AG são enfileirados em um dos nós e executados em outro, a sincronização de backup (mencionada na secção 6) não funcionará corretamente. O nó 2 pode assumir que o nó 1 está inativo e, portanto, as tarefas de lá não estão a ser enviadas para sincronização. Isso pode levar a quebras na cadeia de logs ou backups extras, já que ambos os nós podem fazer backups 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:

Diagrama mostrando o cálculo de instâncias protegidas de bancos de dados.

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

Instância protegida/instância de faturamento Bancos de dados considerados para calcular o tamanho do frontend
AG1 DB1, DB2
AG2 DB4
VM2 DB3
VM3 DB6
VM4 DB5

Mover uma base de dados protegida para dentro ou para 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/remoção de um nó em 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.

Depois disso, o novo nó sincroniza as informações do cronograma de backup AG do serviço de Backup do Azure 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 à adição de nó, as extensões de carga de trabalho detetam a alteração na topologia AG nesta situação 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 as agendas de backup para bancos de dados AG e excluir os metadados relacionados a AG.

Cancelar o registro de um nó 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 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.

Próximos passos

Aprenda a:

Conteúdo relacionado

  • Last updated on