在数据库备份恢复的日常运维中，恢复模式决定了日志的保留方式、备份策略的设计以及故障点恢复的能力。很多DBA在接手新库时，经常面临一个典型问题：为什么业务库的日志文件不断膨胀？为什么日志备份无法截断？为什么时间点恢复总是失败？这些问题的根源往往在于恢复模式的选择不当。本文从实际场景出发，对比完整恢复与简单恢复的差异，帮你做出合理决策。
场景一：业务库日志无限膨胀，为何日志备份不截断？
某天你发现数据库日志文件已占满磁盘，而日志备份作业却始终报错。检查后发现，数据库处于完整恢复模式，但没有配置日志备份。在完整恢复模式下，所有事务都会写入日志，且只有执行日志备份后日志才会截断（即空间可重用）。如果从未做过日志备份，日志文件会持续增长直到磁盘耗尽。
此时，你需要立即执行一次日志备份（BACKUP LOG），然后规划定期的日志备份频率。如果业务允许丢失最近几分钟的数据，且对时间点恢复无要求，可以考虑切换到简单恢复模式，让系统自动截断日志，但代价是只能恢复到最近一次完整或差异备份，无法做时间点恢复。
场景二：误删数据，需要恢复到误删前一刻
业务人员误删了大量数据，要求恢复到几分钟前。如果数据库处于完整恢复模式，并且有完整的日志链（从完整备份开始的连续日志备份），你可以通过日志备份恢复到误删时间点（STOPAT）。具体操作：先还原完整备份（NORECOVERY），再依次还原差异备份（如有）和日志备份，直到目标时间点。
如果数据库处于简单恢复模式，则只能恢复到最近一次完整或差异备份，丢失自备份以来的所有更改。因此，对数据安全要求高、需要精细恢复的场景，必须选择完整恢复模式。
场景三：开发测试库，数据可重建，追求简单
对于开发、测试或临时库，数据可以从生产库重新生成，通常不需要严格的恢复能力。此时选择简单恢复模式最为合适：无需管理日志备份，日志自动截断，备份策略只需定期做完整备份（或差异备份），运维成本最低。
需要注意的是，即使使用简单恢复模式，完整备份和差异备份仍然有效，只是无法做日志备份和时间点恢复。在切换模式前，请确认业务RPO（恢复点目标）要求。
两种恢复模式的本质区别
完整恢复模式的核心是日志的完整性。所有事务都记录在日志中，直到被日志备份截断。这意味着你可以利用日志做时间点恢复、页面级恢复，甚至还原到日志备份中的任意LSN。代价是日志文件增长快，必须定期备份日志，否则日志膨胀。
简单恢复模式则简化了日志管理：每次检查点（Checkpoint）后，日志中已提交的事务空间会被自动重用，因此日志文件保持较小。但代价是只能恢复到最近一次备份，无法做时间点恢复。对于报表库、归档库等，简单恢复模式是常见选择。
如何选择恢复模式？
选择恢复模式，本质是权衡数据丢失容忍度与运维复杂度。以下是一些判断依据：
- 如果业务要求RPO接近零（如金融交易），必须使用完整恢复模式，并配置高频日志备份。
- 如果业务允许丢失最近几小时或一天的数据（如报表库），简单恢复模式即可满足。
- 如果数据库处于开发阶段，频繁变更结构，简单恢复模式可减少备份文件数量。
另外，在切换恢复模式前，务必先做一次完整备份，以确保切换后有一个清晰的基线。从简单恢复切换到完整恢复后，需要立即建立日志备份作业，否则日志会开始增长。
常见误区与注意事项
误区一：简单恢复模式不需要备份。实际上，简单恢复模式仍需定期完整备份和差异备份，否则一旦磁盘损坏，数据将全部丢失。
误区二：完整恢复模式必须配置日志备份。如果不做日志备份，日志会无限增长，最终导致磁盘满、数据库不可用。因此，完整恢复模式必须配套日志备份策略。
误区三：切换恢复模式会中断业务。在SQL Server中，切换恢复模式属于元数据操作，通常不会中断业务，但建议在维护窗口执行，并先做完整备份。
此外，在完整恢复模式下，某些操作（如索引重建）会大量写入日志，可能瞬间增大日志大小。建议在大操作前手动备份日志，或考虑使用简单恢复模式（如果允许）来减少日志开销。
总结
恢复模式的选择直接影响备份策略和故障恢复能力。完整恢复模式适合对数据安全要求高的生产环境，简单恢复模式适合对恢复点要求不高的场景。无论选择哪种，都应定期测试备份的可恢复性，确保在灾难发生时能真正恢复数据。关于备份类型的选择，可参考数据库增量备份与差异备份的区别详解；若遇到备份文件损坏，可参考数据库备份文件损坏后的修复方法；恢复测试的实践可参考数据库恢复测试的重要性及实施步骤。
参考资料
延伸阅读