Planejar a proteção de dados do SQL Server
Publicado: março de 2016
Aplicável a: System Center 2012 SP1 - Data Protection Manager, System Center 2012 - Data Protection Manager, System Center 2012 R2 Data Protection Manager
Antes de implantar o DPM para proteger o SQL Server, faça o seguinte:
Examine as notas de versão e os Cenários com e sem suporte no DPM para quaisquer problemas do SQL Server.
Verifique o suporte para as versões do SQL Server em Matriz de suporte de proteção do DPM.
Observe o seguinte:
Se você tiver um banco de dados com arquivos em um compartilhamento de arquivo remoto, a proteção falhará com a ID do Erro 104.O DPM não oferece suporte à proteção de dados do SQL Server em um compartilhamento de arquivo remoto.
O DPM não pode proteger os bancos de dados armazenados em compartilhamentos SMB remotos.
Verifique se as réplicas do grupo de disponibilidade estão configuradas como somente leitura.
Adicione explicitamente a conta do sistema NTAuthority\System ao grupo Sysadmin no SQL Server.
Ao realizar uma recuperação em local alternativo de um banco de dados parcialmente independente, verifique se a instância SQL de destino está com o recurso Banco de Dados Independentes habilitado.
Proteger o SQL Server com AlwaysOn habilitado
O SQL Server 2012 introduz um novo recurso de alta disponibilidade, o AlwaysOn.É possível adicionar os bancos de dados aos Grupos de Disponibilidade, que são basicamente contêineres para bancos de dados configurados para failover.O DPM do System Center 2012 SP1 oferece suporte à proteção de bancos de dados que fazem parte de Grupos de Disponibilidade.Os principais recursos do suporte ao DPM para o AlwaysOn são:
O DPM detecta os Grupos de Disponibilidade ao executar a consulta na criação do grupo de proteção.
O DPM detecta um failover e continua a proteção do banco de dados.
O DPM oferece suporte a configurações de cluster multissite para uma instância do SQL Server.
Ao proteger bancos de dados que usam o recurso AlwaysOn, o DPM apresenta as seguintes limitações:
O DPM seguirá a política de backup de grupos de disponibilidade que está definida no SQL Server com base nas preferências de backup, como a seguir:
Preferir secundária — Os backups devem ocorrer em uma réplica secundária, exceto quando a réplica primária é a única réplica online.Se houver várias réplicas secundárias disponíveis, então o nó com a maior prioridade de backup será selecionado para backup.Quando somente a réplica primária está disponível, o backup deve ocorrer na réplica primária.
Somente secundária — O backup não deve ser executado na réplica primária.Se a réplica primária é a única online, o backup não deve ocorrer.
Primária — Os backups sempre devem ocorrer na réplica primária.
Qualquer réplica — Os backups podem acontecer em qualquer uma das réplicas de disponibilidade do grupo de disponibilidade.O nó cujo backup será feito será baseado nas prioridades de backup de cada um dos nós.
Observe o seguinte:
Os backups podem acontecer em qualquer réplica legível, ou seja, primária, secundária síncrona, secundária assíncrona.
Se alguma réplica for excluída do backup (por exemplo, a opção Excluir Réplica está habilitada ou está marcada como não legível), então ela não será selecionada para backup em nenhuma das opções.
Se várias réplicas estiverem disponíveis e legíveis, então o nó com a maior prioridade de backup será selecionado para backup.
Se o backup falhar no nó selecionado, a operação de backup falhará.
Não há suporte para a recuperação em local original.