……至少我是这么认为的。
我最近在我的开发服务器上修改了我的备份例程。我为用户数据库创建了一个维护计划，该计划在全天的关键点执行一些每周清理任务、每日完整备份和事务日志备份。
一切都运行良好，直到今天收到一封电子邮件，通知我午餐时间备份失败。日志查看器并没有透露太多，除了一定数量的数据库已完全备份成功，在结束日志条目之前：
[snipped] Source: ... The package execution fa... The step failed.
不完全暴露
我突然想到，与以前的尝试相比，唯一的变化是今天早上我创建了一个新的（小而不起眼的）数据库。
我重新启动了 SQL Server 代理，并尝试手动重新运行（事务日志备份）步骤，但它再次失败。
但是，运行完整备份步骤（从而为我的新数据库创建第一个完整备份）有效 - 此外，再次重新运行事务日志备份步骤也有效。
由于缺少完整备份或以前的事务日志备份，事务日志备份似乎很困难。
这是预期的行为吗？一方面，在原始层面上这种做法是有道理的，但实际上，我希望它能够更优雅地处理这种情况。
如果是这样，有没有办法自动处理这个？这种情况不会经常发生，但我不能指望我在创建数据库时记得备份它，尤其是因为它仅处于开发的早期阶段。
如果不是，这种行为的可能原因是什么？我可以避免吗？
是的，这是预期的行为。为了使事务日志有用，需要有一个完整的备份作为前滚的起点。
不要太担心它。如果你创建一个新的数据库，第一天你就会得到那个错误。如您所见，其他数据库的日志备份将成功，但该错误只会使它看起来像步骤失败，而实际上只有一个数据库失败。然后，那天晚上（或任何时候），它将进行完整备份。之后，新数据库的跨日志备份将成功。基本上，在完整备份作业运行之前，您在创建新数据库时会有一天或错误。
我在要备份的 DBS 列表上放置了一个标志，表明它已被备份。备份脚本在等于 1 之前不会执行 Txn 备份。在我的完整备份脚本中，我将标志设置为 1。Presto，没有更多的失败。