为什么对我的数据库进行完整备份还原时出现错误“RESTORE 只能在还原完整备份时创建数据库...”？

我已经制定了维护计划，每天对服务器上的所有数据库进行完整备份。我还设置了第二个维护计划，每 5 分钟备份一次事务日志。事务日志备份作业在晚上 11 点到凌晨 1 点之间停止并重新启动，以允许进行服务器级备份（在基础架构团队的建议下，可能会重新访问）。我不认为这应该是一个问题，因为我有另一台服务器遵循相同的模式，并且它的备份没有问题。

我正在尝试验证我的备份是否正常工作，但是每当我尝试使用之后的任何事务日志备份来恢复完整备份时，我都会立即收到以下错误：

我正在尝试将备份还原到单独的服务器（相同的 SQL Server 版本），其主要目的是测试数据库备份的完整性。我正在尝试恢复的数据库当前在该服务器上不存在。

如果它有任何相关性，这些是我正在使用的还原选项：

在Aaron Bertrand 对类似问题的有趣回答之后，我现在正在使用该RESTORE HEADERONLY FROM DISK命令调查一些事情。首先，这些是我的完整备份文件的结果：

该完整备份中仅存储一个数据库/文件。

此外，如果我RESTORE HEADERONLY FROM DISK在最后一次完整备份之后运行我的第一个事务日志备份文件、完整备份文件本身以及最后一次完整备份之前的最后一个事务日志备份文件，我会注意到以下 LSN：

我认为DatabaseBackupLSN所有备份的 都应该与FirstLSN这些备份之前的最后一个完整备份相匹配。对我来说奇怪的是，它们似乎都指向较旧的完整备份。

当我尝试生成 SSMS 尝试执行的还原脚本时，奇怪的是我得到了与工具提示相同的错误，并且它不会给我脚本：

仔细检查后，当我选择所有备份（包括完整备份）时，SSMS 会自动删除完整备份并仅加载要还原的事务日志备份。我真的认为有一个损坏的备份链让 SSMS 感到困惑：

如果我只选择要恢复的完整备份，那么它可以让我单击脚本按钮，这就是完整备份本身的脚本：

USE [master]
RESTORE DATABASE [MyDatabase] FROM  DISK = N'P:\MyDatabase\MyDatabase_backup_2021_09_16_223001_3540051.bak' WITH  FILE = 1,  NOUNLOAD,  STATS = 5

此外，我的维护计划未设置为“仅复制备份”：

作为参考，这里是完整备份维护计划中的数据库之一的 T-SQL 脚本：

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

如果我手动编写完整备份的还原以及在该完整备份之后发生的最接近事务日志备份的脚本，它会很好地还原完整备份并将数据库保留在其中，NORECOVERY但事务日志备份失败并出现以下错误：

这些是我编写的手动脚本：

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;

奇怪的是，如果我尝试恢复在完全备份之前发生的最近的事务日志备份，我会得到完全相同的错误消息，引用完全相同的 LSN。所以就像我的事务日志备份没有遵循与我的完整备份相同的备份链？

我能想到的唯一其他相关信息是这些备份维护计划最初是在 SQL Server 2016 实例上设置的。该实例的服务器崩溃了，我们使用 SQL Server 2019 实例启动了一个全新的服务器。我将所有用户和系统数据库从备份（讽刺地）还原到新的 SQL Server 2019 实例。（我必须首先在 2016 实例上恢复系统数据库，并在它允许我在新的 2019 服务器上恢复它们​​之前进行就地升级。）我无法成功恢复到新服务器的唯一数据库是master数据库。到目前为止，其他一切似乎都运行良好。