Qual a diferença entre os backups do SQL e os backups noturnos regulares do servidor de TI?

Nosso departamento de TI faz backup de todo o servidor todas as noites (uma instância do SQL Server está instalada neste servidor), que deve fazer backup desse servidor e de toda a rede, caso algo dê errado ...

Então, meu gerente perguntou qual é o significado dos meus backups completos, diferenciais e de log SQL versus qualquer que seja o backup do departamento de TI? Para economizar mais espaço em nosso servidor, em vez de manter esses arquivos por algumas semanas e excluí-los, ela acha que a TI apenas os fornecerá!

Sei que não está certo, pois como posso restaurar os últimos 30 minutos com meus backups de log, a TI o restaura no dia seguinte, mas essa é a única diferença?

Como eu salvo / envio meus arquivos de backup do banco de dados para o mesmo servidor, a TI os restaurará, mas se eu não tiver essas tarefas de backup no meu plano de manutenção, a TI poderá restaurar a instância do SQL sem nenhuma de nossas tabelas, transações ... etc. Estou entendendo direito?
Qualquer conselho seria muito apreciado.

Os backups de banco de dados oferecem a capacidade de restauração point-in-time (desde que você tenha um FULLmodelo de recuperação). Mesmo que seu pessoal de TI faça backups a cada poucos minutos, o que é extremamente improvável, você ainda terá uma lacuna.

Os backups do servidor não substituem os backups do banco de dados, eles os complementam "arquivando" os arquivos de backup do banco de dados a longo prazo (isto é, mais do que hoje).

No final, você e seu gerenciamento precisam decidir seu RPO (o objetivo do ponto de recuperação - quanto você precisa recuperar em uma falha). Com apenas backups diários do servidor e sem backups do banco de dados, você pode perder um dia inteiro de trabalho no pior dos casos.

Edit : @Sting tem um ponto válido em que as cópias de sombra (o mecanismo mais provavelmente usado para fazer backups do servidor) provavelmente não terão uma cópia exatamente simultânea de todos os seus arquivos de banco de dados (incluindo arquivos de log), o que pode levar a inconsistências quando você restaura o backup. Por exemplo, se a cópia de sombra ler o log de transações alguns milissegundos antes de ler o arquivo de banco de dados, o arquivo de banco de dados poderá conter uma transação não confirmada, mas, como a transação foi confirmada um milissegundo mais tarde, o log não terá nenhum registro.

Há uma chance de que a restauração de arquivos mdf e ldf da cópia de sombra seja transacionalmente inconsistente. Isso significa que essas restaurações de sombra não estão em conformidade com as propriedades ACID do banco de dados.

https://msdn.microsoft.com/en-us/library/aa480356.aspx

Provavelmente, a restauração provavelmente funcionará, mas você ficará imaginando o que realmente está recebendo. (Sem mencionar, você seria encarregado de testar para garantir que os backups / cópias de sombra do servidor estejam funcionando corretamente em todos os servidores) Além disso, não há como restaurar os logs de transações em um momento específico, como você pode usar o SQL Server T -SQL RESTORE LOG / STOPAT.

Até que os backups / restaurações do Windows Server estejam em conformidade com o teste ACID do SQL Server, nosso setor não pode se arriscar.

Tendo dito tudo isso, estive em algumas das reuniões mais estranhas. Se você transmitir os problemas para a TI e eles ainda não parecem se importar ou estão dispostos a correr o risco, isso remove uma enorme carga de seus ombros. Aconteça o que acontecer, documente a ata da reunião com o que todos decidirem e por que todos decidiram e envie-a aos participantes da reunião.

Tudo isso depende do produto que seu departamento de TI está usando para backups em nível de servidor.

Por exemplo, em um ambiente virtual, o VMWare tira instantâneos do servidor. Se o SQL Server estiver envolvido, o VMWare tem uma opção que a maioria dos administradores habilita (ou, por padrão, não sei) que congelará a IO dos bancos de dados durante o instantâneo. Agora, enquanto isso leva apenas alguns segundos, você pode causar problemas no seu aplicativo e não é realmente um método confiável a ser usado para restaurar o banco de dados.

Se você estiver usando um produto de terceiros para fazer backups no nível do servidor, é provável que esteja fazendo apenas backups no nível de arquivo de seus bancos de dados. Também é necessário ter a capacidade de fazer backups de arquivos bloqueados, porque o SQL Server tem todos os arquivos mdf e ldf anexados bloqueados na perspectiva do Windows. O BackupExec da Symantec, por exemplo, utiliza a opção Advanced Open File para fazer isso, para que possa basicamente tirar uma foto desse arquivo bloqueado. Da mesma maneira que os sons farão com que a maioria dos DBAs se encrave, se for necessário restaurar o banco de dados com um backup como esse, pense na consistência do banco de dados ao fazer esse backup. Não há garantia de que o backup seja acionado enquanto um processo de carregamento de dados estiver ocorrendo. Que parte do carregamento de dados esse backup recebeu?

Os backups nativos do SQL Server são confiáveis, desde que sejam verificados como bons backups. Você sabe exatamente em que estado eles estavam quando acionou o backup por um COMPLETO, se você tem isso agendado para carregar dados e tal. Um backup de log para o modelo de recuperação COMPLETO garante que você possa restaurar esse banco de dados no segundo.

Se o seu gerente está decidido a usar o backup no nível do servidor, eu pesquisaria muito o produto que está usando. Gostaria de descobrir se existe algum "complemento" ou agente de backup do SQL Server que possa ser comprado para permitir que ele faça backups de VDI dos bancos de dados.

Algo a considerar e discutir com seu gerente é o envolvimento que você precisará ter na verificação e solução de problemas se os backups do SQL Server falharem. Eu usei o Netbackup intensamente em trabalhos anteriores e, há alguns anos, um cliente queria que eu testasse o uso do agente SQL Server do Netbackup em seu ambiente. Isso incluiu outros DBAs que também precisavam fornecer suporte. Eu disse a eles que a solução de falhas de backup do SQL Server exigia que você soubesse um pouco sobre o Netbackup. Os servidores principais do Netbackup geralmente são executados em servidores Unix, então agora você precisa conhecer alguns Unix .... pode ser divertido, mas é mais difícil se você já estiver ocupado. Apenas algo a considerar e pode ser um bom ponto de discussão com seu gerente e descubra quem é o responsável pela solução de falhas.

Há pouco menos de um milhão de variáveis ​​na sua pergunta. Você precisará conversar com seu departamento de TI sobre quais backups eles fazem. Com toda a probabilidade, eles têm ou podem ter até o minuto de backup disponível. Quanto tempo leva para carregá-los depende de mais variáveis.

Em um cenário perfeito, seu departamento de TI mantém seus backups em um ou mais servidores diferentes em diferentes locais. Você provavelmente está mantendo seu backup no mesmo servidor em que seus bancos de dados estão. Portanto, se o servidor morrer ou seu edifício queimar, seu departamento de TI provavelmente poderá restaurar seus arquivos, mas os backups que você fez desaparecerão com o servidor.

MAS você pode restaurar seu backup, na sua velocidade, sempre que quiser, desde que o servidor ainda esteja ativo.

Como já foi dito, depende de quais são suas necessidades, sua tolerância a riscos e a importância do controle do tempo de recuperação. Se você deseja recuperar algo estúpido que você fez, seus backups serão mais rápidos e melhores. Se você deseja se recuperar de um desastre fora do seu controle, o backup de TI (deve ser) é a melhor opção.