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.
Observação
- Não há suporte para o backup de bancos de dados do Grupo de Disponibilidade Básico do Backup do Microsoft Azure.
- Confira a matriz de suporte de backup do SQL para saber mais sobre as configurações e cenários com suporte.
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.
| Preferência de Backup AG | Backups completos e de comparação executados em | Backups somente cópia e de log são tirados de |
|---|---|---|
| Primário | Réplica primária | Réplica primária |
| Somente Secundário | Réplica primária | Qualquer uma das réplicas secundárias |
| Preferir Secundário | Réplica primária | Réplicas secundárias são preferenciais, mas os backups também podem ser executados na réplica primária. |
| Nenhuma/qualquer | Réplica primária | Qualquer réplica |
A extensão de backup de carga de trabalho é instalada no nó quando é registrada com o serviço Backup do Microsoft Azure. Quando um banco de dados do AG é configurado para backup, os agendamentos de backup são efetuados para todos os nós registrados do AG. Os agendamentos acionam em todos os nós do AG e as extensões de backup de carga de trabalho nesses nós sincronizam entre si para decidir qual nó executará o backup. A seleção de nó depende do tipo de backup e da preferência de backup, conforme explicado na seção 1.
O nó selecionado continua com o trabalho de backup, enquanto o trabalho disparado nos outros nós sai, ou seja, ignora o trabalho.
Observação
O Backup do Microsoft Azure não considera prioridades ou réplicas de backup ao decidir entre as réplicas secundárias.
Registrar nós do AG no cofre dos Serviços de Recuperação
Um cofre dos Serviços de Recuperação dá suporte ao backup de bancos de dados somente de VMs na mesma região e assinatura que o cofre.
- Você deve registrar o nó primário no cofre (caso contrário, backups completos não podem acontecer).
- Se a preferência de backup for somente secundária, você precisará registrar pelo menos um nó secundário no cofre (caso contrário, os backups completos somente de log/cópia não poderão acontecer).
A configuração de backups para bancos de dados do AG falhará com o código de erro FabricSvcBackupPreferenceCheckFailedUserError se as condições acima não foram atendidas.
Vamos considerar a implantação do AG a seguir como uma referência.
Com base no exemplo de implantação do AG acima, veja a seguir 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.
- A VM3 não pode ser registrada no Cofre 1, pois está em uma assinatura diferente.
- A VM4 não pode ser registrada no Cofre 1, pois está em uma região diferente.
- Se a preferência de backup for somente secundária, VM1 (Primária) e VM2 (Secundária) deverão ser registradas no Cofre 1 (porque os backups completos exigem o nó primário e os logs exigem um nó secundário). Para outras preferências de backup, a VM1 (Primária) deve ser registrada no Cofre 1, a VM2 é opcional (porque todos os backups podem ser executados no nó primário).
- Embora a VM3 possa ser registrada no cofre 2 na assinatura 2 e os bancos de dados do AG apareceriam para proteção no cofre 2, devido à ausência do nó primário no cofre 2, a configuração de backups falharia.
- Da mesma forma, embora a VM4 possa ser registrada no cofre 4 na região 2, a configuração de backups falharia, pois o nó primário não está registrado no cofre 4.
Failover de identificador
Depois que o AG tiver passado por um dos nós secundários:
- Os backups completos e diferenciais continuarão do novo nó primário se ele estiver registrado no cofre.
- Os backups completos de log e somente cópia continuarão do nó primário/secundário com base na preferência de backup.
Observação
As quebras de cadeia de log não ocorrerão no failover se o failover não coincidir com um 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 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.
- Se a preferência de backup não for somente secundária, os backups poderão ser configurados agora no Cofre 2, porque o nó primário está registrado nesse cofre. Mas isso pode levar a conflitos/falhas de backup. Mais sobre isso em Configurar backups para um AG de várias regiões.
- Failover para VM4 (outra região)
- Como os backups não são configurados no Cofre 4, nenhum backup ocorreria.
- Se a preferência de backup não for somente secundária, os backups poderão ser configurados agora no Cofre 4, porque o nó primário está registrado nesse cofre. Mas isso pode levar a conflitos/falhas de backup. Mais sobre isso em 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.
Backups completos/diferenciais ocorrerão com êxito somente no cofre que tem o nó primário. 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 em que o novo nó primário está presente) e interrompa a cadeia de log 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 somente 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 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.
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)
- Failover do AG para VM3 para que o nó primário está presente no Cofre 2.
- Configure backups para os bancos de dados do AG no Cofre 2.
- Neste ponto:
- Os backups completos/diferenciais falharão no Cofre 1, pois nenhum dos nós registrados pode fazer esse backup.
- Os backups de log terão êxito no Cofre 1 até que um backup de log seja executado no Cofre 2 e quebre a cadeia de log do Cofre 1.
- Failback do AG para 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 log podem continuar até que ocorra a quebra da cadeia de log/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ê poderá alterar esse valor para um valor menor se os backups simultâneos estiverem causando a sobrecarga de memória/e/s/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 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 do 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 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 de banco de dados do 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á inoperante e, portanto, os trabalhos de não estão chegando para sincronização. Isso pode levar a quebras de cadeia de log 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 de SQL autônoma, uma instância do AG com backup é considerada como 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:
| Instância de cobrança/instância protegida | Bancos de dados considerados para calcular o tamanho de front-end |
|---|---|
| AG1 | DB1, DB2 |
| AG2 | DB4 |
| VM2 | BD3 |
| VM3 | DB6 |
| VM4 | DB5 |
Movendo 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 banco de 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 do AG protegido sai do AG e se torna 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 do AG pode ser interrompida com a retenção de dados para evitar que os backups futuros disparem e falhem nele.
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 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.
Depois disso, o novo nó sincroniza as informações de agendamento de backup do AG do serviço de Backup do Microsoft Azure e inicia a participação no 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, adição de nó, as extensões de carga de trabalho detectam a alteração da topologia no AG nesse caso e informam o serviço de Backup do Microsoft Azure. O serviço inicia um fluxo de trabalho de desconfiguração no nó removido para limpar os agendamentos de backup para bancos de dados do AG e excluir os metadados relacionados ao AG.
Cancelar o registro de um nó do AG do Backup do Microsoft 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 ingressado em um 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 reter os 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 na 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 excluir os 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.
Próximas etapas
Saiba como:
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de