我最近发生了一件让我重新考虑备份计划的事件：我们的一个 MSSQL 驱动的应用程序停止了，因为文件系统上的日志文件变得太大（它是 50 GB 的 IIRC）。
事实证明，应用程序开发人员将数据库恢复方法设置为“完整”，并且完整备份夜间路由不会清除和缩小该日志文件。为了缩小它必须备份它，将恢复方法更改为“简单”，并使用缩小进行备份。
我显然想防止这种情况发生，所以我正在寻找选择。
这是一个 MSSQL 2012 Express x64 实例。
应用程序开发人员完全不合作（外部承包商，与所有人合作），所以我假设他不希望我让数据库处于“简单”模式。
我可以轻松地调整我的 sqlcmd 脚本来执行“以‘完整’备份 -> 切换到‘简单’ -> 以‘简单’备份 -> 恢复为‘完整’”并保留文件，但我担心我可以冒着一些我现在没有预见到的风险。
在我看来，我应该相对频繁地执行此操作，因为日志文件越大，备份和收缩所需的时间就越多，从而导致明显的减速。
如果该例程是合理的，并且在每个循环之后我最终得到“清除日志之前的备份”和“清除日志后的备份”，并且假设两个进程都没有错误退出，那么丢弃第一个进程是否明智？一？我将保留“数据”备份和“清除日志”备份。
我应该通过执行“完整备份”而不是“常规日志备份”来添加 AFAIK 我牺牲了恢复到“两个完整备份之间的状态”的可能性，但我并没有阻碍完整备份本身，因为我已经恢复和克隆了他们过去很多次都没有问题。但如果这是错误的，请告诉我。
注意：为简单起见，假设现在能够恢复到每晚的完整备份就足够了。
我希望我能够解释自己。提前致谢。
