我最近发生了一件让我重新考虑备份计划的事件：我们的一个 MSSQL 驱动的应用程序停止了，因为文件系统上的日志文件变得太大（它是 50 GB 的 IIRC）。
事实证明，应用程序开发人员将数据库恢复方法设置为“完整”，并且完整备份夜间路由不会清除和缩小该日志文件。为了缩小它必须备份它，将恢复方法更改为“简单”，并使用缩小进行备份。
我显然想防止这种情况发生，所以我正在寻找选择。
这是一个 MSSQL 2012 Express x64 实例。
应用程序开发人员完全不合作（外部承包商，与所有人合作），所以我假设他不希望我让数据库处于“简单”模式。
我可以轻松地调整我的 sqlcmd 脚本来执行“以‘完整’备份 -> 切换到‘简单’ -> 以‘简单’备份 -> 恢复为‘完整’”并保留文件，但我担心我可以冒着一些我现在没有预见到的风险。
在我看来，我应该相对频繁地执行此操作，因为日志文件越大，备份和收缩所需的时间就越多，从而导致明显的减速。
如果该例程是合理的，并且在每个循环之后我最终得到“清除日志之前的备份”和“清除日志后的备份”，并且假设两个进程都没有错误退出，那么丢弃第一个进程是否明智？一？我将保留“数据”备份和“清除日志”备份。
我应该通过执行“完整备份”而不是“常规日志备份”来添加 AFAIK 我牺牲了恢复到“两个完整备份之间的状态”的可能性，但我并没有阻碍完整备份本身，因为我已经恢复和克隆了他们过去很多次都没有问题。但如果这是错误的，请告诉我。
注意：为简单起见，假设现在能够恢复到每晚的完整备份就足够了。
我希望我能够解释自己。提前致谢。
不要这样做。这是一个可怕的想法，因为它给其他任何查看系统的人留下了错误的印象，并且只是对主要开发人员撒谎的一种解决方法。这不是围绕数据库恢复做出技术决策的好理由。由于我们对您的公司、应用程序等一无所知，因此存在未知风险，因此只有您可以与这些人交谈。
正确的路径是在利益相关者（包括任何顽固的开发人员）之间达成共识，并就满足业务需求的RTO/RPO达成一致。然后相应地调整恢复模式。
假设您不想根据您的帖子这样做：
如果您100% 确定您不关心比日常备份更精细的恢复，请将其保持在完全恢复模式并有一个事务日志备份作业指向，
NUL这样增长就不是问题。它不会将文件保存在任何地方，但仍然可以让您控制日志增长。另见：
全面披露：expressdb.io 是我的网站。