Configurei um plano de manutenção para fazer um backup completo diário de todos os bancos de dados no meu servidor. Também configurei um segundo plano de manutenção para fazer backups do log de transações a cada 5 minutos. A tarefa de backups do log de transações é interrompida e reiniciada entre 23h e 1h, para permitir que backups em nível de servidor sejam feitos (aconselhamento da equipe de infraestrutura, talvez para serem revisitados). Não acredito que isso deva ser um problema, pois tenho outro servidor seguindo o mesmo padrão e não tenho problemas com seus backups.
Estou tentando verificar se meus backups estão funcionando corretamente, mas sempre que tento restaurar o backup completo com qualquer um dos backups do log de transações que vieram depois dele, recebo imediatamente o seguinte erro:
Estou tentando restaurar os backups em um servidor separado (mesma versão do SQL Server) cujo objetivo principal agora é testar a integridade do backup do banco de dados. O banco de dados que estou tentando restaurar atualmente não existe nesse servidor.
Se for de alguma relevância, estas são as opções de restauração que estou usando:
Seguindo esta resposta interessante de Aaron Bertrand a uma pergunta semelhante, agora estou investigando algumas coisas com o RESTORE HEADERONLY FROM DISKcomando. Em primeiro lugar, estes são os resultados do meu arquivo de backup completo:
Apenas um banco de dados/arquivo armazenado nesse backup completo.
Além disso, se eu executar RESTORE HEADERONLY FROM DISKmeu primeiro arquivo de backup do log de transações após o último backup completo, para o próprio arquivo de backup completo e o último arquivo de backup do log de transações antes do último backup completo, observo os seguintes LSNs:
Eu pensei que DatabaseBackupLSNtodos os backups deveriam corresponder ao FirstLSNúltimo backup completo anterior a esses backups. É estranho para mim que todos eles pareçam apontar para um backup completo mais antigo.
Quando tento gerar os scripts da restauração que o SSMS está tentando fazer, estranhamente recebo o mesmo erro como uma dica de ferramenta e não me dá os scripts:
Após uma inspeção mais detalhada, quando seleciono todos os meus backups, incluindo o completo, o SSMS remove automaticamente o backup completo e carrega apenas os backups do log de transações para restauração. Eu realmente acho que há uma espécie de cadeia de backup quebrada que está confundindo o SSMS:
Se eu selecionar apenas meu backup completo para restaurar, ele me permitirá clicar no botão de script e este é o script apenas para o backup completo:
USE [master]
RESTORE DATABASE [MyDatabase] FROM DISK = N'P:\MyDatabase\MyDatabase_backup_2021_09_16_223001_3540051.bak' WITH FILE = 1, NOUNLOAD, STATS = 5
Além disso, meu plano de manutenção não está definido para "backups somente cópia":
Para referência, aqui está o script T-SQL para um dos bancos de dados no plano de manutenção de backup completo:
BACKUP DATABASE [master] TO DISK = N'\\OurDomain\Shares\SQL Backups\Full Backups\master\master_backup_2021_09_19_004931_6111907.bak' WITH RETAINDAYS = 14, NOFORMAT, NOINIT, NAME = N'master_backup_2021_09_19_004931_6111907', SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10
Se eu fizer o script manualmente de uma restauração do meu backup completo e do backup do log de transações mais próximo que ocorreu após esse backup completo, ele restaurará o backup completo e deixará o banco de dados, NORECOVERYmas o backup do log de transações falhará com o seguinte erro:
Estes são os scripts manuais que escrevi:
USE [master]
RESTORE DATABASE [MyDatabase]
FROM DISK = N'P:\MyDatabase\MyDatabase_backup_2021_09_16_223001_3540051.bak'
WITH NORECOVERY;
RESTORE LOG [MyDatabase]
FROM DISK = N'P:\MyDatabase\MyDatabase_backup_2021_09_16_223001_4008446.trn'
WITH RECOVERY;
Estranhamente, se eu tentar restaurar o backup do log de transações mais próximo que ocorreu antes do backup completo, recebo a mesma mensagem de erro exata referenciando exatamente os mesmos LSNs. Então é como se meus backups de log de transações não estivessem seguindo a mesma cadeia de backup que meu backup completo?
A única outra informação relevante que consigo pensar é que esses planos de manutenção de backup foram configurados originalmente em uma instância do SQL Server 2016. O servidor dessa instância travou e criamos um novo servidor com uma instância do SQL Server 2019. Eu restaurei todos os bancos de dados de usuários e sistemas de backups (ironicamente) para a nova instância do SQL Server 2019. (Os bancos de dados do sistema que tive que restaurar primeiro em uma instância de 2016 e fazer uma atualização in-loco antes de permitir restaurá-los no novo servidor de 2019.) O único banco de dados que não consegui restaurar para o novo servidor com êxito foi o masterbase de dados. Todo o resto parece estar funcionando bem até agora.
A conclusão é que você (infelizmente) não pode confiar no SSMS para ajudá-lo na restauração. Porque não dá certo. Eu tenho um caso que relatei em 2014 em que o IMO é ruim, onde o SSMS tenta basear uma sequência de restauração em um backup copy_only, e lembrei a MS sobre isso algumas vezes. Isso caiu em ouvidos surdos, então essa é uma mensagem bastante clara para mim. Veja alguns exemplos: http://sqlblog.karaszi.com/?s=restore .
No seu caso, não temos o suficiente para reproduzir. E sem uma reprodução, não há nada que possamos fazer exceto dizer algo como "parece ser um bug no SSMS". Não sabemos qual backup você executou, não sabemos o que você clica na GUI, não sabemos quais arquivos de backup você possui no segundo servidor. etc.
Se você quiser que testemos se você entendeu mal a GUI, nos dê uma reprodução.
Talvez uma tarefa difícil para você, mas sem isso, como mencionei, ficamos com "parece ser um bug no SSMS" ...
Nosso software de backup em nível de servidor, Veeam, aparentemente foi configurado para truncar o log de transações. Eu não tinha conhecimento de que a Veeam pudesse interagir no nível do banco de dados até que o sábio Tibor Karaszi me apontou na direção certa:
(Isso foi configurado muito antes da minha existência. Nota lateral, não vejo absolutamente nenhuma razão para a Veeam oferecer essa opção terrível .)
Alterar isso para fazer backup dos próprios logs (em vez de ter um plano de manutenção para fazer isso) resolveria o problema. Mas eu prefiro deixar o SQL Server gerenciar os backups nativamente, então apenas desabilitamos o gerenciamento disso no software Veeam Backup & Replication.
No software Veeam Backup & Replication, na janela Edit Backup Job , na tela Guest Processing , desmarcamos a opção " Enable application-aware processing " para desativá-lo.
Para referência, esta é a documentação da Veeam sobre como configurá-la para gerenciar o log de transações.