本文采用備份加增量日志的恢複方法，恢複源庫到異機，增量日志恢複保證停機切換時間最小。
一、
SQL Server資料庫有三種恢複模式：簡單恢複模式、完整恢複模式和大容量日志恢複模式：
1.Simple 簡單恢複模式,
Simple模式的舊稱叫”Checkpoint with truncate log“，其實這個名字更形象，在Simple模式下，SQL Server會在每次checkpoint或backup之後自動截斷log，也就是丢棄所有的inactive log records，僅保留用于執行個體啟動時自動發生的instance recovery所需的少量log，這樣做的好處是log檔案非常小，不需要DBA去維護、備份log，但壞處也是顯而易見的，就是一旦資料庫出現異常，需要恢複時，最多隻能恢複到上一次的備份，無法恢複到最近可用狀态，因為log丢失了。 Simple模式主要用于非critical的業務，比如開發庫和測試庫，但是道富這邊的SQL Server（即使是生産庫）大都采用Simple模式，是因為這邊的SQL Server大都用于非critical的業務（critical的資料庫大都采用Oracle和DB2)，可以忍受少于1天的資料丢失(我們的job每天都會定時備份全庫）。
如果需要壓縮資料庫日志（Shrink語句），将資料庫模式切換到簡單恢複模式後壓縮率才是最高的，如果你的資料庫在完整恢複模式或大容量日志回複模式下采用日志壓縮，壓縮後的日志大小并不會很理想。
2.Full 完整恢複模式,
和Simple模式相反，Full模式的舊稱叫”Checkpoint without truncate log“，也就是SQL Server不主動截斷log，隻有備份log之後，才可以截斷log，否則log檔案會一直增大，直到撐爆硬碟，是以需要部署一個job定時備份log。Full的好處是可以做point-in-time恢複，最大限度的保證資料不丢失，一般用于critical的業務環境裡。缺點就是DBA需要維護log，增加人員成本（其實也就是多了定時備份log這項工作而已）。
3.Bulk-logged 大容量日志恢複
Bulk-logged模式和full模式類似，唯一的不同是針對以下Bulk操作，會産生盡量少的log： 1) Bulk load operations (bcp and BULK INSERT). 2) SELECT INTO. 3) Create/drop/rebuild index 衆所周知，通常bulk操作會産生大量的log，對SQL Server的性能有較大影響，bulk-logged模式的作用就在于降低這種性能影響，并防止log檔案過分增長，但是它的問題是無法point-in-time恢複到包含bulk-logged record的這段時間。 Bulk-logged模式的最佳實踐方案是在做bulk操作之前切換到bulk-logged，在bulk操作結束之後馬上切換回full模式。
二、
1、備份前的配置
資料庫備份使用full（完整）模式
如果檔案較大，網絡帶寬有限制，可以啟用備份壓縮。
增量日志備份使用截斷日志選項
使用自動維護計劃，備份集将單獨名稱生成，
增量日志備份選項
2、執行備份
全備、增量日志分别配置維護任務
3、檔案傳輸
傳輸資料庫備份和增量日志備份
增量日志備份每次備份後進行傳輸
4、全備恢複
使用restore with norecovery模式
找到備份集
保持恢複狀态
資料庫處于正在還原狀态
5、持續增量日志恢複
選擇事務日志恢複
6、恢複注意事項
恢複是需要注意的是，最好每次恢複時進行結尾日志備份，萬一所有的事務日志進行了恢複，此時資料庫會一直處于“正在還原”狀态，
我們用結尾日志備份進行事務日志恢複，并選擇with recovery模式即可打開資料庫。