这里简单总结一下关于SQL Server事务日志备份的一些疑问，如有其它更多疑问，欢迎你们留言讨论。
事务日志备份频繁有性能影响吗？
关于事务日志备份，如果设置得非常频繁有什么性能影响吗？ 这个是不少人的疑惑，频繁的事务日志备份是否影响性能呢？其实这是一个谬论。关于这些问题，我们先来做个假设，假设两小时内产生了30G大小的事务日志，那么对于下面几种事务日志备份策略：
1: 2小时做一次事务日志备份。
2: 1小时做一次事务日志备份。
3：30分钟做一次事务日志备份。
4: 15分钟做一次事务日志备份。
5: 5分钟做一次事务日志备份。
总体来说，如果2小时内，产生了30G大小的事务日志，那么不管哪种备份策略，事务日志备份的IO总量（或者事务日志备份文件大小）是一样的。并不会因为日志备份频率有所区别。但是如果2小时备份一次事务日志，那么一次将要备份30G大小的日志。这个对IO的影响将持续较长一段时间，如果是15分钟备份一次事务日志（这里为了说明，假设事务日志是均衡、平均产生的），那么一次事务日志备份只需要备份3.75GB大小的事务日志。如果从资源消耗的角度来说，频繁的事务日志备份反而能分散IO到不同时间段，避免较短时间产生大量的IO操作。这样对系统IO性能反而好处较多。
而且频繁的事务日志备份不仅可以减少一次备份事务日志的大小，从时间范围上分散IO，而且频繁的事务日志备份，还有增加日志截断频率的优点，让事务日志文件不会变得非常大。
那么说了这么多，频繁的事务日志备份都是好处，那么是不是我设置的越频繁越好呢？ 要不要设置为1分钟一次事务日志备份呢？这个也不尽然，我们知道很多事务日志备份作业是串行备份多个数据库。如果一分钟做一次事务日志备份，那么可能出现作业在一分钟内运行不完的情况。另外，可能会产生大量的事务备份文件，管理和还原的时候也会有所干扰。正确的做法权衡多方面考虑，设置合适的备份频率。
如何设置日志备份的频率呢？官方文档有这样的描述：
· 事务日志备份频率应足够支持业务需求，尤其是对损坏的日志存储可能导致的数据丢失的容忍程度。
· 适当的日志备份频率取决于您对数据丢失风险的容忍程度与所能存储、管理和潜在还原的日志备份数量之间的平衡。 实现恢复策略时，请考虑必需的RTO和 RPO，特别是日志备份频率。
· 每 15 到 30 分钟进行一次日志备份可能就已足够。 但是如果您的业务要求将工作丢失的风险最小化，请考虑进行更频繁的日志备份。
完整备份包含事务日志备份吗？
数据库完整备份将备份整个数据库。 还包括部分的事务日志，以便在还原完整数据库备份后可以恢复完整数据库。其实差异备份也是如此。完整或差异备份需要日志来将数据库还原到当完整或差异备份结束时的事务一致性状态。所以，完整备份或差异备份包含部分事务日志备份。准确的说是从完整备份开始到结束这段时间的事务日志备份。
完整备份会截断事务日志吗？
首先，我们先搞清楚一个概念，截断日志（log truncating）和日志清理（log clearing）其实是同一件事情，它们表示事务日志的一部分被标记为不再需要，可以覆盖重复使用了（有点类似Oracle下的redo log归档后，可以被重新覆盖了）。在完整或大容量事务日志恢复模式下，只有备份日志才会清除日志。我们知道完整备份会包含事务日志备份，但是它确实不会截断日志(清除日志)，跟多详细细节参考“Misconceptions around the log and log backups: how to convince yourself”
简单恢复模式下能做事务日志备份吗？
不行。简单的恢复模式下仅允许完整备份和差异数据库备份，并且没有进行事务日志备份的机会。 在简单恢复模型中创建检查点时，将从事务日志中删除所有已提交的事务。
参考资料：