Nosso servidor de banco de dados está sendo hospedado por outra empresa. Eles fornecem um backup em nível de arquivo que ocorre uma vez por dia. Eles também permitem o Log Shipping. Minha empresa está aproveitando a opção Logshipping como parte importante de sua solução de backup e recuperação.
Eu gostaria de ter um sistema de backup melhor que nos permitisse restaurar os dados até o momento da falha. Normalmente, esse seria o modelo de backup completo para o banco de dados e backups dos logs de transações, bem como os completos e incriminais. No entanto, o fornecedor me disse que fornecer backups de log de transação causaria problemas com o envio de log.
Existe uma estratégia de backup que me permitirá restaurar até o ponto de falha e também usar o logshipping?
Você pode estar utilizando os backups de log de transação que são obtidos pelo processo de envio de log. Na verdade, você não pode duplicar os backups de log de transações.
Portanto, contanto que você tenha os backups reais do log de transações e a capacidade de copiá-los para outro armazenamento (para preservação e retenção de backup personalizado para recuperação de desastres), você deve estar bem na frente do t-log.
Mas, o verdadeiro problema é que você não pode fazer backups completos (ou diferenciais) do banco de dados. Você precisará deles para a recuperação de desastres. Um backup em nível de arquivo não é bom o suficiente para um plano de DR sólido e certamente não é suficiente para uma recuperação pontual. Você deve ter, em algum momento, conseguido fazer um backup completo do banco de dados para inicializar seu(s) banco(s) de dados secundário(s). Por que isso não é mais uma opção?
Referência BOL sobre como usar o envio de logs como parte de um plano de recuperação
Como disse Thomas, os backups de log de transações não podem ser usados, a menos que você tenha um backup completo do banco de dados. Mas ter uma longa cadeia de backups de log de transações e um backup de banco de dados completo no início fará com que a restauração de um processo pontual seja muito lenta. Imagine que você precise reverter várias centenas de backups de log de transações.
O melhor seria fazer um backup completo do banco de dados uma vez por dia (ou uma vez por semana, dependendo da ocupação do seu banco de dados), para que o número de logs de transação a serem aplicados nunca seja grande. Para citar Paul Randal "O objetivo de qualquer operação de restauração é restaurar o menor número possível de backups, para que a operação de restauração seja a mais rápida possível". Veja mais aqui: SQL Server: Recuperando-se de Desastres Usando Backups