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