Prós e contras das estratégias de backup do SQL Server e seus cenários de uso apropriados

O envio de logs não é um cenário de backup. É um cenário de disponibilidade semi alta.
Para backups, há backups completos, diferenciais e de log de transações. Todos eles devem ser usados ​​juntos. Seu SLA determina como você os usa. A maioria dos cenários típicos são backups completos, digamos, à meia-noite, backups diferentes ao meio-dia e backups de log de transações a cada 30 ou 15 minutos.

E lembre-se: você não tem um backup válido até restaurar dele para testar se está tudo bem.

Indiscutivelmente, não existe um conceito como uma estratégia de backup: você tem uma estratégia de restauração porque isso determina quanto tempo até que você volte a funcionar*.

Todas as estratégias requerem um backup completo para basear quaisquer restaurações subsequentes de backups diferenciais e/ou de log.

Na prática, você pode ter um backup completo de 6 meses atrás com backups de log de 15 minutos: no entanto, você deve aplicar todos os backups de log desde o último completo.

Como um exemplo aleatório, um cenário pode ser completo semanalmente, diferencial diário, log de 15 minutos.

O intervalo de backup determina quantos dados você perderá no pior caso: backups de log de 15 minutos fornecem uma perda de dados entre 1 segundo e 14 minutos e 59 segundos, média de 7,5 minutos. Isso é aceitável?

O envio de logs é uma espera passiva com failover manual: não é um backup, mas uma opção de alta disponibilidade.

Não existe uma estratégia que se encaixe em todas as situações. Mas é importante entender o que você tem disponível para você. Os backups completos são exatamente o que parecem: um backup completo do seu banco de dados, menos o log de transações. Backups diferenciais são backups de alterações nos arquivos de dados desde o último backup completo. Os backups do log de transações farão backup de todas as transações armazenadas no log de transações desde o último backup do log de transações. Os backups do log de transações permitirão que você restaure para um ponto no tempo. Se isso for um requisito, você precisará definir o modo de recuperação como "Full" e fazer backups regulares do log de transações, dependendo da quantidade de dados que deseja perder no caso de uma situação de recuperação.

Ao lidar com backups de log de transações, é importante entender o que é uma cadeia de log. Em minhas palavras, uma cadeia de log é a série de backups que precisam ser restaurados para restaurar seu banco de dados em um determinado ponto no tempo. Para começar a restaurar logs de transações, você deve primeiro restaurar um backup completo usando a opção WITH NORECOVERY. Se você também executar backups diferenciais, deverá restaurar o backup diferencial mais recente antes do ponto no tempo para o qual deseja restaurar usando a mesma opção WITH NORECOVERY. Neste ponto, você precisará restaurar os backups do Transaction Log, sequencialmente, usando a opção WITH NORECOVERY em todos os backups, exceto o backup final. Para obter mais informações sobre restaurações pontuais, confira este link. http://msdn.microsoft.com/en-us/library/ms175093.aspx

Conforme mencionado, o Log Shipping não é uma estratégia de backup, mas pode reduzir significativamente o tempo de restauração no caso de uma situação de recuperação de desastre. Uma pegadinha a ser observada é que todas as publicações de replicação precisarão ser roteirizadas para o servidor Log Shipping e inicializadas para que a replicação funcione como antes do desastre. Com publicações maiores, isso pode causar um aumento significativo no tempo necessário para restaurar o nível de produção.

Espero que isto ajude,

Matt

Eu segundo Mladen Prajdic. Este artigo ajudará você a escolher a estratégia de backup correta, dependendo do modelo de recuperação dos bancos de dados.

essas não são estratégias de backup para o SQL Server. Backups completos e diferenciais são tipos de backups que você pode fazer em um banco de dados SQL Server, enquanto Log Shipping é uma estratégia de Alta Disponibilidade (movendo backups de log em um horário agendado de um servidor para outro e sincronizando esses 2 bancos de dados até o limite de seus backups).

Boas informações sobre Disaster Recovery (backup e restauração :-)) você pode encontrar no MSDN: aqui e aqui . Resumindo, você precisa escolher a quantidade de dados que pode recuperar dos backups em caso de falha. Uma amostra sensata de estratégia de backup seria um backup completo todos os dias e backups de log a cada hora (isso depende de suas necessidades), portanto, neste caso, você seria capaz de restaurar o banco de dados do backup completo + todo o backup de log diário.

Outra boa referência sobre DR você pode encontrar em Simple_Talk .

Obviamente, você não precisa apenas restaurar seu banco de dados, mas também recuperar o contexto do servidor e do aplicativo do qual o banco de dados faz parte. Ainda não usei, mas o Data Protection Manager procura fazer um trabalho mais abrangente, se você precisar.

A melhor maneira é usar todos os três tipos de backups juntos. Obviamente, você pode ignorar o backup diferencial do backup do log de transações. Tudo depende do seu banco de dados, quão rápido ele cresce, com que frequência você faz alterações em seu banco de dados e outros. Antes de escolher seu plano de backup, considere quantos dados você está disposto a perder? Quanto tempo você está disposto a gastar para recuperar seu banco de dados?

Por exemplo, se seu banco de dados crescer rapidamente, você pode usar a seguinte estratégia de backup do SQL Server: backup completo - uma vez por dia, backups diferenciais - a cada duas horas e backups de log de transações - a cada 20 minutos. Nesse caso, se ocorrer a falha, você não perderá mais de 19 minutos do seu trabalho. Outro exemplo, se o seu banco de dados crescer lentamente, você pode executar um backup completo uma vez por dia, backup diferencial a cada seis horas e fazer backup do log de transações a cada hora.

Mais uma dica - para ter certeza de que seu banco de dados está seguro, de vez em quando restaure seus backups em um servidor de teste.