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/locais e o 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 de 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 completos e de log de transações somente cópia, 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 somente cópia e log são retirados 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 o secundário | 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 é registrada 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ó 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 é resgatado, ou seja, ignora o trabalho.
Nota
O Backup do Azure não considera prioridades de backup ou réplicas ao decidir entre as réplicas secundárias.
Registrar nós AG no cofre dos Serviços de Recuperação
Um cofre dos Serviços de Recuperação oferece suporte ao backup de bancos de dados somente de VMs na mesma região e assinatura do cofre.
- Você deve registrar o nó principal no cofre (caso contrário, backups completos não podem acontecer).
- Se a preferência de backup for apenas secundária, você precisará registrar pelo menos um nó secundário no vault (caso contrário, backups completos somente de log/cópia não poderão acontecer).
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.
Com base no exemplo de implantação do AG acima, 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.
- O VM3 não pode ser registrado no Vault 1, pois está em uma assinatura diferente.
- O VM4 não pode ser registrado no Vault 1, pois está em uma região diferente.
- Se a preferência de backup for apenas secundária, VM1 (Principal) e VM2 (Secundário) deverão ser registrados 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).
- Enquanto o VM3 poderia ser registrado no vault 2 na assinatura 2 e os bancos de dados AG apareceriam para proteção no vault 2, mas devido à ausência do nó principal no vault 2, a configuração de backups 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 failover
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 ele estiver registrado no cofre.
- Os backups completos somente de log e cópia continuarão do nó principal/secundário com base na preferência de backup.
Nota
As quebras da cadeia de logs não acontecem no failover se o failover 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 acontecerão a partir do 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.
- Failover 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 secundária, os backups podem ser configurados agora no Vault 2, 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.
- Failover para VM4 (outra 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 que tem 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 cofre é 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 cofre que tenha o nó primário também fará os backups de log.
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 seja satisfeita em todas as etapas.
Etapa 1: habilitar backups na Região 1, Assinatura 1 (Vault 1)
Como o nó principal está na região e na assinatura, as etapas usuais para habilitar backups funcionarão.
Etapa 2: habilitar backups na Região 1, Assinatura 2 (Vault 2)
- Faça failover do AG para VM3 para que o nó primário esteja presente no Vault 2.
- Configure backups para os bancos de dados AG no Vault 2.
- Neste ponto:
- Os backups completos/diferenciais falharão no Vault 1, pois nenhum dos nós registrados pode fazer esse backup.
- 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.
- Failback do AG para VM1.
Etapa 3: habilitar backups na Região 2, Assinatura 1 (Vault 4)
O mesmo que o Passo 2.
Faça backup de uma AG que abrange o Azure e no 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 até que a quebra da cadeia de logs aconteça/15 dias se passem.
Limitação de tarefas de backup em um banco de dados AG
Atualmente, os limites de limitação de backup se aplicam em um nível de máquina individual. 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 um ponto, todos os 55 backups serão acionados no Nó 1 e 35 deles serão enfileirados. Alguns deles seriam os backups de banco 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 nó e executados em outro, a sincronização de backup (mencionada na seção 6) não funcionará corretamente. O nó 2 pode assumir que o nó 1 está inativo e, portanto, os trabalhos de lá não estão chegando 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 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 como Apenas primário ou secundário – então apenas um nó pode fazer os backups, o outro sempre será resgatado.
- Para um AG com mais de 2 nós, defina a Preferência de backup como Primária – então apenas o nó primário pode fazer os backups, outros serão resgatados.
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:
| 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 ele se move sob um AG, o nome exclusivo 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 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 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 de dados para evitar que backups futuros sejam acionados e falhem neles.
Adição/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 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 de agendamento de backup AG do serviço de Backup do Azure e começa a participar do processo de backup sincronizado. Se o novo nó não for capaz de sincronizar as agendas de backup e participar de backups, acionar um novo registro no nó forçará a reconfiguração do nó para backups AG também. Da mesma forma, adição de nó, as extensões de carga de trabalho detetam a alteração de topologia AG neste caso e informam o serviço de Backup do Azure. 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 permitirá cancelar o registro desse nó. Isso é para evitar futuras falhas de backup 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á cancelá-lo.
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. O banco de dados precisa ser restaurado para uma instância SQL autônoma e, em seguida, precisa ser associado a um AG.
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:
A recriação de AGs que já estão protegidas aparecem como AGs duplicadas na página Configurar Backup e na lista 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 design, o Backup do Azure lista os itens duplicados na lista Itens protegidos e na página Configurar Backup ou na 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 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: