Pelo que sei, há três maneiras possíveis de fazer backup do banco de dados do SQL Server
Quais são os prós e os contras de cada estratégia e em que situações eles devem ser empregados?
O envio de logs não é um cenário de backup. É um cenário de disponibilidade semi alta.
Para backups, existem backups completos, diferenciais e de log de transações. Todos devem ser usados juntos. Seu SLA determina como você os usa. Os cenários mais comuns são backup completo, por exemplo, à meia-noite, backup diferenciado 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é restaurá-lo para testar se está ok.
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 você deve voltar à operação *.
Todas as estratégias requerem um backup completo para basear as 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, é necessário aplicar todos os backups de log do último total.
Como exemplo aleatório, um cenário pode ser semanal completo, diferencial diário, registrar 15 minutos.
O intervalo de backup determina a quantidade de dados que você perderá na pior das hipóteses: os backups de log de 15 min oferecem uma perda de dados entre 1 segundo e 14 minutos e 59 minutos e 59 segundos, em média 7,5 minutos. Isso é aceitável?
O envio de logs está em espera quente com failover manual: não é backup, mas uma opção de alta disponibilidade.
Não existe uma estratégia que se adapte a todas as situações. Mas é importante entender o que você tem à sua disposição. 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 restaurar para um ponto no tempo. Se isso for um requisito, você precisará definir o modo de recuperação como "Completo" e precisará 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 do log de transações, é importante entender o que é uma cadeia de logs. Em minhas palavras, uma cadeia de logs é a série de backups que precisam ser restaurados para restaurar seu banco de dados em um determinado momento. Para começar a restaurar os logs de transações, você deve primeiro restaurar um backup completo usando a opção WITH NORECOVERY. Se você também executar backups diferenciais, desejará restaurar o backup diferencial mais recente antes do momento em que deseja restaurar o uso da mesma opção WITH NORECOVERY. Nesse momento, você precisará restaurar os backups do log de transações, 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
Como 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 dica a ter em atenção é que todas as publicações de replicação precisarão ser scripts para o servidor Log Shipping e inicializadas para que a replicação funcione como era 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. Os backups completos e diferenciais são tipos de backup que você pode fazer em um banco de dados do SQL Server, enquanto o Envio de Log é uma estratégia de Alta Disponibilidade (movendo backups de log em um horário agendado de um servidor para outro e tendo esses 2 bancos de dados sincronizados até o limite de seus backups).
Informações legais sobre a recuperação de falhas (backup e restauração :-)) você pode encontrar no MSDN: aqui e aqui . Em resumo, você precisa escolher a quantidade de dados que pode recuperar dos backups em caso de falha. Uma amostra sã da estratégia de backup seria um backup completo todos os dias e backups de log a cada hora (isso depende de suas necessidades); portanto, nesse caso, você poderá restaurar o banco de dados a partir do backup completo + todo o backup diário de log.
Outra boa referência sobre DR você pode encontrar no Simple_Talk .
Obviamente, você não apenas precisa restaurar seu banco de dados, como também recuperar no contexto do servidor e aplicativo do qual o banco de dados faz parte. Ainda não 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. Obviamente, você pode ignorar o backup diferencial do backup do log de transações. Tudo depende do seu banco de dados, da velocidade com que cresce, da frequência com que você faz alterações no banco de dados e outras. Antes de escolher seu plano de backup, considere quantos dados você deseja perder? Quanto tempo você está pronto para gastar para recuperar seu banco de dados?
Por exemplo, se o seu banco de dados cresce 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 a falha ocorrer, você não perderá mais de 19 minutos do seu trabalho. Outro exemplo, se o banco de dados crescer lentamente, você poderá executar um backup completo uma vez por dia, backup diferencial a cada seis horas e a cada hora fazer backup do log de transações.
Mais uma dica - para garantir que seu banco de dados seja seguro, periodicamente, restaure seus backups em um servidor de teste.