事务日志备份 (SQL Server)
适用范围：
SQL Server
本文仅与使用完整恢复模式或大容量日志恢复模式的 SQL Server 数据库相关。 本文讨论备份 SQL Server 数据库的事务日志。
在创建任何日志备份之前，您必须至少创建一个完整备份。 然后，可以随时备份事务日志，除非已备份此日志。
建议经常执行日志备份，这样既可尽量减少丢失工作的风险，也可以截断事务日志。
数据库管理员通常偶尔（如每周）会创建完整数据库备份，还可以选择以较短间隔（如每天）创建一系列差异备份。 与数据库备份无关，数据库管理员可以比较频繁地创建事务日志备份。 对于给定的备份类型，最恰当的备份间隔取决于一系列因素，如数据的重要性、数据库的大小和服务器的工作负荷。 有关实施好策略的更多信息，请参阅本文中的“建议”。
日志备份顺序的工作方式
事务日志备份“日志链” 的序列与数据备份无关。 例如，假设有下列事件顺序。
| 时间 | 事件 |
|---|---|
| 8:00 AM | 备份数据库。 |
| 中午 | 备份事务日志。 |
| 4:00 PM | 备份事务日志。 |
| 晚上 6:00 | 备份数据库。 |
| 晚上 8:00 | 备份事务日志。 |
晚上 8:00 创建的事务日志备份包含从下午 4:00 到晚上 8:00 的事务日志记录，跨越晚上 6:00 创建完整数据库备份这一时间。 事务日志备份序列是连续的，从上午 8:00 创建第一个完整数据库备份到晚上 8:00 创建最后一个事务日志备份。 有关如何应用这些日志备份的信息，请参阅应用事务日志备份 (SQL Server) 中的示例。
建议
如果事务日志损坏，则最新有效备份以后执行的工作将丢失。 因此，我们强烈建议您将日志文件存储在容错的存储设备中。
如果数据库已损坏，或要还原数据库，建议创建一个结尾日志备份，可将数据库还原到当前时间点。
注意
已知问题：对于具有内存优化表的数据库，执行不带恢复的事务日志备份，然后执行带恢复执行事务日志还原，可能会导致数据库还原过程无响应。 此问题还会影响日志传送功能。 要解决此问题，可在启动还原过程前重启 SQL Server 实例。
默认情况下，每个成功的备份操作都会在 SQL Server 错误日志和系统事件日志中添加一个条目。 如果非常频繁地备份日志，这些成功消息会迅速累积，从而产生一个巨大的错误日志，这样会使查找其他消息变得非常困难。 在这些情况下，如果任何脚本均不依赖于这些条目，则可以使用跟踪标志 3226 抑制这些条目。 有关详细信息，请参阅跟踪标志 (Transact-SQL)。
请经常进行日志备份，其频率应足够支持业务需求，尤其是对损坏的日志存储可能导致的数据丢失的容忍程度。
适当的日志备份频率取决于你对工作丢失风险的容忍程度与所能存储、管理和潜在还原的日志备份数量之间的平衡。 实现恢复策略时，请考虑必需的恢复时间目标 (RTO) 和恢复点目标 (RPO)，特别是日志备份频率。
每 15 到 30 分钟进行一次日志备份可能就已足够。 但是如果你的业务要求将工作丢失的风险最小化，请考虑进行更频繁的日志备份。 频繁的日志备份还有增加日志截断频率的优点，其结果是日志文件较小。
重要
若要限制需要还原的日志备份的数量，必须定期备份数据。 例如，可以制定这样一个计划：每周进行一次完整数据库备份，每天进行若干次差异数据库备份。
同样，实现恢复策略时，请考虑所需 RTO 和 RPO，尤其是完整和差异的数据库备份频率。