首先，这不是这个问题的重复。在那个问题中，这个人每次都在覆盖文件，解决方案是使用 INIT 或 NOINIT。
在我的例子中，我们为每个备份生成一个唯一的文件名——一个时间戳附加到文件名。
我们有一个代理作业，每晚为大约 20 个数据库运行完整备份。在大约一周的时间里，1 个数据库的大小似乎每晚都在显着增加。
我们运行第二个代理作业，每 15 分钟运行一次日志备份，但在晚上 11 点到凌晨 5 点之间停止运行。通常早上的第一件事是日志备份很大，然后它们的大小变小，直到人们开始工作，然后它们的大小各不相同。
所有这些多年来一直没有问题。
20 个数据库中只有一个显示此问题 - 每晚的完整备份都比前一晚大得多。
日志文件备份适用于该数据库和所有其他数据库。
我们有一个包含三个副本的可用性组。两个被设置为相互故障转移，第三个副本是只读的，用于繁重的查询、数据提取和报告。AG 控制台在所有服务器的页面下方一直显示绿色复选标记。
有问题的数据库是 20 个数据库中最大的一个。正常的完整备份大约是 25GB。它慢慢增加如下：33、35、36、41、47、54、64、73 GB。
相比之下，在此问题之前的所有 14 个备份中，文件大小相当稳定，约为 25GB。
我刚刚暂停了所有数据库的所有日志备份，并对受影响的数据库进行了完整备份，最后一次完整备份是 76GB。
这似乎是
sys.databases.log_reuse_wait报告AVAILABILITY_REPLICA可用性组中的两个副本和ACTIVE_TRANSACTION第三个副本的特殊问题。在我的例子中，试图确定活动事务没有产生任何结果 - 阅读针对问题的整个评论线程以获取详细信息。
最后，我重新启动了那个副本，一切都解决了。
总之
日志文件被一个活动的事务保持打开状态（或者至少数据库是这样认为的）并且这不知何故流向了每晚增长的数据文件完整备份文件大小。
通过检查确定根本原因
sys.databases.log_reuse_wait- 感谢@JD 在评论中提出建议 -解决方案是通过重新启动受影响的副本来解决的（因为尽管有消息说
kill，我实际上找不到任何活动事务）。log_reuse_waitACTIVE_TRANSACTION