Meu servidor de produção não tem potência suficiente para executar backups localmente sem causar impacto na produção. Eu gostaria de transferi-los para minhas réplicas secundárias, para liberar recursos no meu primário.
As perguntas e preocupações gerais que tenho são:
- Que tipos de backups posso fazer em minhas réplicas secundárias?
- Eu faço backups diferenciais hoje, como isso vai funcionar?
- Como isso afetará meu RPO/RTO?
- Como configuro a preferência de backup?
- Configurei a preferência de backup, mas ela não está sendo respeitada. O que eu fiz errado?
- E as verificações de integridade? Não devo levar aqueles onde levo meus backups?
- Vou quebrar minhas correntes de log?
- Devo considerar descarregar meus backups ou devo procurar outras alternativas?
Tipos de backups que você pode fazer em réplicas secundárias
Você pode fazer backups completos somente cópia e backups de log. Você não pode fazer um backup completo tradicional em uma réplica secundária porque o banco de dados é somente leitura e o SQL Server não pode limpar o sinalizador de bitmap diferencial.
Ainda deseja fazer backups diferenciais
Você terá que fazer isso em suas réplicas primárias, junto com seus backups completos. Lembre-se de que você só pode fazer backups completos somente de cópia em sua réplica secundária. Para poder redefinir o sinalizador de bitmap diferencial, você terá que fazer isso em seu primário.
Impacto para RPO/RTO
Seu RPO/RTO pode ser muito afetado dependendo de onde você faz seus backups. A sincronização para réplicas secundárias pode ficar para trás. A replicase secundária pode ser reinicializada quando seus trabalhos de backup devem estar em execução, além de uma meia dúzia de outros motivos pelos quais esses backups podem se tornar não confiáveis. Nada seria pior do que planejar um RPO de 15 minutos, apenas para descobrir que sua réplica secundária estava 30 minutos atrasada em relação à última vez que um backup de log de transações foi executado nele.
Configurando a preferência de backup
Isso é muito fácil de configurar no assistente do Grupo de Disponibilidade. Você tem poucas opções.
Depois de definir a preferência, você desejará definir a prioridade. Este é um (0-100), 0 sendo o mais baixo, 100 sendo o mais alto. Essa configuração é útil para ajudar a evitar que os backups sejam executados em todas as suas réplicas secundárias ao mesmo tempo, com cada uma pensando que são a prioridade mais alta. Normalmente, você definirá uma réplica como 100 e diminuirá outras réplicas, conforme apropriado.
Configurei a preferência de backup, mas ela não está sendo respeitada. O que eu fiz errado?
Configurar a preferência e a prioridade de backup por si só não é suficiente para garantir que seus backups sejam executados onde você acha que eles funcionarão. Seus trabalhos de backup devem estar cientes dessa configuração. Essencialmente, configurar esses valores em sua disponibilidade apenas expõe essas configurações por meio de uma função do sistema chamada sys.fn_hadr_backup_is_preferred_replica ( 'dbname' ) . Você deve certificar-se de que as tarefas de backup estão verificando o resultado dessa função antes de tentar um backup em qualquer banco de dados.
E as verificações de integridade ? Não devo levar aqueles onde levo meus backups?
Sim, você deseja executar verificações de integridade onde está fazendo backups, para saber que tem backups válidos que poderá restaurar. No entanto, em um grupo de disponibilidade, você realmente deseja certificar-se de executar verificações de integridade em todas as réplicas, independentemente de onde você faz os backups. Executar verificações de integridade e fazer backups apenas em uma réplica secundária não garante que não haja corrupção em sua réplica primária. Suas réplicas secundárias estão obtendo apenas detalhes do log de transações do primário. Eles não saberiam se o primário tinha uma página corrompida no disco. Se você também não estiver executando verificações de integridade em seu primário, ele poderá passar despercebido por semanas, meses ou mais. Você pode não descobrir até não ter mais backups válidos para reverter.
Você pode dizer: "bem, vou fazer o failover para minha réplica secundária". E isso pode funcionar. Mas não estou procurando que essa seja minha proteção primária contra a corrupção. Quero ser alertado o mais rápido possível e ainda ter backups válidos para voltar, apenas por precaução.
E as cadeias de logs
Tenha cuidado com as Cadeias de Logs ao fazer backups de log em grupos de disponibilidade. Não importa de qual nó você faça um backup de log em um Grupo de Disponibilidade, essa cadeia de log é mantida em todos os nós. Se você tiver backups de log em execução em mais de um nó, por qualquer motivo, precisará de todos eles caso precise restaurar para um ponto no tempo. Mantenha as coisas simples aqui, limite todos os backups de log ao mesmo nó.
Conclusão
Minha preferência é manter todos os meus backups em execução na minha réplica primária. Se a sincronização ficar atrasada, por qualquer motivo, sei que ainda posso contar com meus backups para serem a cópia mais atualizada que posso obter. Se ocorrer corrupção, serei notificado rapidamente e poderei reagir. Também posso depender de um reparo automático de página de uma réplica secundária. Se estou enfrentando um problema em que é uma preocupação executar backups em minhas réplicas primárias, estou questionando se o servidor tem recursos suficientes ou se o ajuste de consulta ou índice é necessário para ajudar o servidor a ter um melhor desempenho. Não estou procurando limitar minha capacidade de recuperar um banco de dados corretamente, transferindo meus backups para outro servidor.
Mais informações estão disponíveis aqui e aqui .