如果你的數據庫運行在完整或是批量日誌恢復模式下，那麼你就需要使用作業(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