如果你的数据库运行在完整或是批量日志恢复模式下，那么你就需要使用作业(job)来定期备份事务日志，保持你的事务文件大小处在一个可管理的范围。当你需要还原事务日志时，你就需要按照创建事务日志的顺序来恢复它们。你可以参考存在msdb..backupset表中的信息来确定还原文件的顺序，使用FirstLSN和LastLSN列的值作参考。当你备份时，这些备份信息就会存在backupset表中
只要序列处于维护状态下，你就可以使用对应的日志把数据恢复到任意恢复点上。不幸的是，有些实例的序列已经被损坏了。下面两种情况普通是引起损坏的原因：
- 数据库的恢复模型被切换到了简单(SIMPLE)后，再次被切换回完整或是批量日志。
- Backup log命令运行时，附带了TRUNCATE_ONLY/NO_LOG选项。
当上面两种情况发生时，你需要即可做一个数据库的完整备份，作为事务日志恢复的新的恢复点。那么你如何判断序列已经被破坏了呢？
在SQL Server 2000中，这确实有点麻烦。假如数据库恢复模型已经被更改了，或是备份时日志已经被截断了，那么当更改后，你第一次备份事务日志时，SQL Server 2000会显示如下输出：
There is no current database backup. This log backup cannot be used to roll forward a preceding database backup.
Processed 1 pages for database 'logtest', file 'logtest_log' on file 1.
BACKUP LOG successfully processed 1 pages in 0.078 seconds (0.019 MB/sec).
注意这仅仅是个消息。虽然备份依然会成功完成，但却不可用。因为这是个计划作业，所以你什么都看不到，不过当事务日志被截断时，在Windows事件日志中是相关警告日志的。。
注意：如果你正在使用SQL Server 2000，那么日志事务对于数据库是非常重要的，所以要在Windows事件日志中不间断的监控日志事务事件。
假如你既没有关注警告消息，也没有监控Windows事件日志，那么基本上你就是有一批不可恢复的事务日志备份。SQL Server不应该警告我们吗？不应该停止无效的备份吗？假如你正在使用SQL Server 2005，那么答案肯定是应该的，而且它也是这么做的。下面就是当日志备份序列被毁坏时显示的消息:
Server: Msg 4214, Level 16, State 1, Line 1
BACKUP LOG cannot be performed because there is no current database backup.
Server: Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.
是不是好多了。总之，如果你正在使用SQL Server 2000，你需要关注上面提到两个警告事件，这两个事件会毁坏你的日志备份序列，使你的备份失效。
下面是一些通用操作来保证日志序列不被破坏：
- 数据库恢复模型可以从完整到批量日志，反过来也一样
- 执行数据库完整备份，差异备份可是文件/文件组备份
假如你有如下一个备份序列(F代表完整数据备份，T代表事务日志)
F1,T1,T2,T3,T4,T5,T6
现在假设你要恢复到T6时间点，如下的恢复序列会帮你达到目的：
F1,T1,T2,T3,T4,T5,T6
F2,T3,T4,T5,T6
F3,T5,T6
本文翻译自sqlbackuprestore，更多精彩内容请浏览http://www.sqlbackuprestore.com