Plano de manutenção de backup do SQL Server (backups de log completos e trans)

3

Eu configurei um plano de manutenção para realizar:

  • backup completo noturno (sobrescreve o arquivo)
  • um backup de log de transações de 2 horas (anexado a um arquivo separado do total)

O banco de dados está no modo de recuperação completa.

A idéia é fazer com que o agente de backup em fita faça um backup do arquivo de backup completo toda noite após o término do backup completo do SQL Server.

No entanto, estou confuso sobre como configurar os arquivos de backup para o log de transações.

Qual é a melhor prática para lidar com:

  1. Fazendo backup de log trans regular
    • ele deve criar arquivos separados para cada um deles?
    • como eu obteria cada backup do servidor para a fita em algum momento?
  2. Fazendo o backup do banco de dados inteiro a cada noite
    • deve sobrescrever o arquivo toda vez
    • Tenho notado que o arquivo de backup é bastante grande após 3 dias de execução, embora esteja configurado para sobrescrever. (DB = 28Gb, arquivo de backup noturno = 58Gb) Por que isso aconteceria?

Em resumo, quais são as práticas recomendadas (em termos de especificações de arquivo) para configurar um plano de backup Completo e de Log de Trans e, em seguida, fazer o backup delas em fita?

Obrigado Desenvolvedor A-não-dba

    
por damitamit 01.07.2010 / 15:19

2 respostas

2

Pessoalmente, eu tenho um banco de dados de 12GB (e crescente) que tem um backup noturno. Eu mantenho 5 dias em disco cada no seu próprio arquivo e copio-os para a fita todas as noites com um mês ou mais de retenção. Também tenho logs de transações enviados a cada hora, cada um para seu próprio arquivo. Eu mantenho 3 dias destes ao redor, mas nunca os copio para fita. Se eu atualizar o armazenamento na fita, também posso iniciar isso, embora provavelmente não seja necessário (IMO), pois você tem os backups noturnos no intervalo.

Como Peter disse, é bom manter os backups em disco por pelo menos alguns dias para fazer restaurações mais rápidas e fáceis, sem mencionar as restaurações em um banco de dados secundário por razões de depuração mais fáceis. Também é bom ter um bom tempo de retenção para a fita. Não é tanto um problema para mim, mas é bom para se você tiver recursos de exclusão em seu aplicativo e o cliente tiver um 'oops eu deletei algo ... um mês atrás que eu preciso hoje, você pode recuperá-lo para mim? tipo momento.

Editar:
Em resposta ao comentário e ampliando minha resposta um pouco aqui. Eu uso um segundo / terceiro trabalho SQL para gerenciar os arquivos para mim. No SQL 2005 eu tive problemas gerenciando os arquivos onde ele não iria apagar corretamente, então eu escrevi algum código (VBScript) para fazer isso para mim em uma tarefa agendada, na medida em que excluí-lo. Mas, no SQL 2008, eles o corrigiram, ou eu apenas fiz um trabalho melhor configurando-o e ele exclui meus backups antigos, remessas de log antigas e até mesmo outro para manter a integridade do banco de dados. Em seguida, eu uso algum script VB para copiar meus arquivos para "fita", que eu realmente deveria reescrever em C # na próxima vez que eu ficar entediado. Estou usando o drive / discos IOMEGA REV como minha "fita" e eles estão funcionando muito bem.

    
por 01.07.2010 / 15:37
1

Acho que a melhor prática é manter, talvez, três dias de backups completos em disco e levá-los varridos para a fita pelo agente de backup em fita (veritas / tivoli etc).

Os backups de log de transações geralmente são configurados para ir para a mesma área da unidade que os backups completos, e o agente de backup de fita os captura também.

Isso significa que, no caso de um requisito de restauração, você pode restaurar muito rapidamente a partir de um backup dos últimos três dias. Mais adiante, você precisará tirá-lo da fita.

    
por 01.07.2010 / 15:23