Gerenciador de snap do Netapp para backups SQL versus nativo

1

Mover para um novo centro de dados. O data center vai usar a replicação SRM para vm's e o gerenciador de snap netapp para sql para backups sql. Atualmente, estamos usando backups nativos completos / tlog. Como os novos padrões se comparam aos padrões atuais e posso interromper com segurança os backups nativos?

    
por William Salzman 09.02.2011 / 16:53

3 respostas

4

Profissionais do NetApp SnapManager:

  • Backups completos levam um segundo ou menos, independentemente do tamanho do banco de dados.
  • Os backups completos não diminuem a velocidade do SQL Server porque nenhum dado é arrastado pela conexão da SAN.
  • As unidades de backup em fita podem ser conectadas diretamente à SAN, permitindo backups rápidos e rápidos do instantâneo.
  • Você pode montar as capturas instantâneas em seus servidores de desenvolvimento ou de controle de qualidade para testes com o mínimo de lentidão na produção (se estiverem configurados corretamente)

Contras do NetApp SnapManager:

  • As capturas instantâneas ainda estão na SAN. Se o seu controlador SAN morrer, você está ferrado e os controladores SAN morrem.
  • Se você precisar atualizar frequentemente um SQL Server dev / QA a partir de dados de produção e esse servidor não estiver usando a mesma SAN do NetApp, ainda será necessário transferir dados aleatoriamente para essa outra SAN. Você pode fazer isso, mas é um pouco mais complexo do que usar o envio de logs convencional.

Profissionais nativos:

  • Está totalmente sob o controle do DBA. Ele não se pergunta se a SAN está ficando sem espaço para os instantâneos. (Você pode atenuar isso envolvendo-se com o administrador da SAN e não quero dizer romanticamente envolvido, embora eu suponha que isso funcionaria também.)
  • Se você precisar fazer o envio de logs para vários servidores para fins de geração de relatórios, e esses outros servidores não estiverem nas SANs da NetApp (como se estivessem usando armazenamento local ou Fusion-IO), é mais fácil gerenciar logs.
  • Gratuito e integrado ao SQL Server.

Contras nativas:

  • Backups muito, muito mais lentos e completos que afetam as consultas de produção.
por 09.02.2011 / 17:01
1

Usamos o gerenciador de snap do netapp para SQL. É um backup rápido, mas eu tenho problemas de vez em quando. Às vezes vou encontrar instantâneos lun lun. Depois de obter um lun ocupado, ele começa a criar mais e mais instantâneos lun lun e, eventualmente, preencherá o espaço do snapshot, fazendo com que todos os backups falhem. A única maneira de se livrar deles é para destruir os luns ocupados e, em seguida, excluir os instantâneos desses luns e tudo vai começar a fazer o backup corretamente novamente. Eu não tive a menor chance de impedir que as luas ocupadas fossem criadas. Claro, eu não entrei em contato com o fornecedor ainda, estou apenas lidando com o problema quando isso acontece.

    
por 09.02.2011 / 17:33
0

Já passou algum tempo desde que trabalhei com eles, mas achei que faltava a ferramenta Netapp Snap Manager para SQL quando ela era contada; durante uma restauração. Você não tem visibilidade nem recorre a como a restauração vai e, muitas vezes, falha. Se eu tivesse uma chance, não usaria o Netapp para fazer o backup novamente.

    
por 09.02.2011 / 18:06

Tags