EDIT: O problema acabou sendo que, embora os backups sejam feitos todas as noites, eu estava tentando restaurar para um ponto no tempo que ainda não havia sido feito backup. Eu teria percebido isso antes se estivesse fazendo o script da restauração, mas como estava usando a GUI, ela simplesmente escolheu o arquivo de log mais recente e não se preocupou em me notificar de que o arquivo de log escolhido não continha realmente o ponto no tempo Eu estava especificando.
Depois que fiz um backup atual do banco de dados e do log de transações, funcionou perfeitamente.
Dito isso, ainda não entendo como o registro com tempo de '2013-11-27 12:52:08.240' foi restaurado no cenário descrito abaixo. Mas, por enquanto, vou atribuir isso a algo maluco com o aplicativo registrando um horário incorreto.
Mais uma vez, estou confuso com a (in?) capacidade do SQL Server de restaurar para um ponto específico no tempo.
Às vezes, quando tentei isso no passado, parecia que o SQL Server foi restaurado para um ponto no tempo próximo de onde eu pedi, mas não exatamente onde eu especifiquei. Eu considerei isso um mal-entendido da minha parte, pois sei que as datas registradas no banco de dados se originam no aplicativo e, portanto, podem variar um pouco desde o momento em que os registros são realmente gravados. As variações eram, na verdade, um pouco mais do que "ligeiras", mas essa ainda é a melhor explicação que pude apresentar.
Por volta das 12h55 de hoje, restaurei um banco de dados 30 minutos antes das 12h25. Agora, quando faço uma consulta no log e classifico por data/hora, vejo um registro com a data '2013-11-26 18:21:49.200' seguido imediatamente por um registro com a data '2013-11-27 12:52:08.240' um ao lado do outro.
Portanto, minha primeira observação é que todos os registros desde o início de hoje até o momento em que restaurei (12h25) não estão lá. Minha segunda observação é que há um único registro às 12h52, que é 27 minutos DEPOIS do horário em que tentei restaurar (muito, muito grande para uma pequena variação no tempo entre quando o aplicativo escolheu um horário e quando o registro realmente ficou escrito).
Alguém mais caiu nessa? Não tenho ideia de por que isso estaria acontecendo e gostaria de receber qualquer ajuda para descobrir como fazer backup de meus bancos de dados de forma que eles sejam restaurados adequadamente para um ponto no tempo em que eu precisar, pois esse é o motivo pelo qual mudei para usar o modelo Full Recovery para backups.
A resposta rápida aqui é: o que você está descrevendo/insinuando é um grande problema, e eu não experimentei isso e esse não é o comportamento padrão ou esperado do SQL Server.
A capacidade de restaurar é uma função fundamental de um RDBMS. A capacidade de restaurar a um ponto no tempo é uma parte fundamental dessa função fundamental. E a base dessa habilidade é o mecanismo de log de um Sistema de Gerenciamento de Banco de Dados Relacional.
Isso não é apenas o que nos dá a capacidade de restaurar para um ponto no tempo, mas a capacidade de recuperar para um estado consistente durante uma falha ou reinicialização. É o mesmo log de transações usado lá.
Resumindo (existem muitos recursos que descrevem o processo. Este é um bom começo ) - o SQL Server usa um mecanismo de log de gravação antecipada. Isso significa que tudo é gravado em seu log de transações e confirmado para ser gravado lá antes que a transação seja considerada durável e sua transação possa ser considerada concluída. Se isso não funcionasse, nunca poderíamos confiar na confiabilidade do SQL Server e dos dados em seu aplicativo, porque os dados poderiam se tornar inconsistentes com problemas de E/S, problemas de memória, reinicialização etc. Não teríamos garantia de manter o ACID propriedades do banco de dados mais.
Portanto, com essa ressalva em mente, há uma das três coisas acontecendo aqui:
(**observação:**Também gostaria de confirmar as configurações de fuso horário, o fuso horário no servidor onde os backups foram feitos é o fuso horário usado em sua restauração quando esta pergunta surgiu. Portanto, se você estiver restaurando de um servidor para o outro - verifique seus fusos horários e tudo.)
Uma maneira simples de provar isso?
Consulte um pouco a tabela que você está procurando para registrar após a atividade normal. Você vê o que espera ver com base em sua compreensão da atividade de hoje? Ok, bom, siga seu processo de restauração normal ou o indicado na documentação vinculada acima, se você tiver feito algo diferente. Faça esta restauração em outra máquina/máquina de desenvolvimento para não afetar seu servidor principal! Restaure para o momento em que você executou sua consulta nesta tabela. Observe sua tabela - se você executou as etapas acima corretamente, verá que os dados parecem corretos. Caso contrário, primeiro examinaria seu processo, releria as instruções, confirmaria o banco de dados, confirmaria os fusos horários e horários nos dois servidores e, se algo ainda estiver errado e você Descartou totalmente a possibilidade de algo faltando no processo? Eu abriria uma chamada imediatamente com a Microsoft, mas honestamente ficaria surpreso se você estivesse enfrentando um bug ou problema.