SQL Server 2005: agendamento de backup adequado

Question

Sou Desenvolvedor .NET e sei escrever SQL, mas não tenho a menor ideia de fazer qualquer tipo de planejamento de manutenção de banco de dados yadda

Então, recentemente assumi um projeto de um cliente anterior. O site está hospedado na Rackspace.

De qualquer forma, o cliente anterior estava fazendo três backups completos diariamente (a cada 8 horas). Estou apenas curioso para saber qual é o padrão adequado?

Algumas perguntas que tenho.

Acrescento ou sobrescrevo?

Defino os backups diários para expirar? [Rackspace faz um diferencial diário e semanal completo eu acredito também]

Preciso fazer backup do log de transações?

Preciso reduzir o log de transações?

Compartilhe alguns insights e práticas recomendadas. Eles seriam muito apreciados!

Obrigado !!

    

Answer 1

Do I append or overwrite?

Se for gravar depois, eu sobregravaria, caso contrário, escolheria um intervalo de tempo de disco aceitável para os backups expirarem (com base no seu tempo de recuperação) e anexar.

Do I set the daily backups to expire? [Rackspace does a daily differential and weekly full i believe as well]

Sim, a menos que o espaço em disco não seja um problema

Do I need to backup the transaction log?

Sim, com a frequência necessária para uma recuperação de ponto no tempo. por exemplo, se o seu SLA disser que você perderá apenas 15 minutos de dados em caso de falha, será necessário fazer o backup do log de transações a cada 15 minutos.

Do I need to shrink the transaction log?

Não, a menos que você de alguma forma tenha aumentado para um tamanho gigantesco em um ponto e nunca use mais do que 1% agora, e você está com pouco espaço em disco, então talvez

Please share some insights, best practices. They'd be greatly appreciated

Você precisa trabalhar com a empresa para determinar que tipo de dados espera perder em caso de um problema e por quanto tempo permitirá que o DB fique indisponível. Depois de ter os acordos em vigor, o restante se torna um exercício de matemática. Em seu exemplo, você menciona que você faz 3 fulls por dia. Você precisa descobrir se são apenas pessoas baleadas no escuro ou se há uma razão pela qual são 3 por dia (talvez devido a tempos de recuperação, incrementos não são possíveis)

Observe que somente depois de obter os requisitos de negócios você pode planejar sua recuperação. O mantra de "planejar sua recuperação" é tão usado que muitos administradores realmente acreditam nisso e simplesmente cometem os mesmos tipos de erros que cometem se se preocuparem com os backups.

    

Answer 2

Não existe realmente um "padrão adequado", pois é uma questão de:

Quantos dados você pode perder?

Um backup bastante padronizado é feito assim:

• Backup completo toda semana (ou 2 a 3 vezes por semana)
• Backups diferenciais todos os dias (ou várias vezes ao dia)
• Servidor secundário com envio de log implementado

Obviamente, depende de como sua carga se parece, quanto espaço em disco você tem para backups, etc.

Com base nas informações fornecidas, não é necessário fazer três backups completos diariamente. Você pode facilmente obter um backup completo por dia e, em seguida, quantos backups diferenciais forem necessários.

A chave REAL para backups não é planejar seus backups, tanto quanto planejar o PROCEDIMENTO DE RECUPERAÇÃO.

Se você começar com o fim em mente ... e o processo de recuperação envolvido e a quantidade máxima de dados que você pode possivelmente perder (ou estar disposto a perder), você encontrará o plano de backup que funciona para VOCÊ.

    

Answer 3

Na minha loja, executo backups t-log a cada hora. Meus diffs são executados todas as noites e meus backups completos são executados aos domingos. Não tenho minha configuração de backups para expirar automaticamente. Eu os excluo manualmente quando eles não são mais necessários. Ainda não implementei o envio de log, pois ainda não tenho os recursos disponíveis ...