1、數據備份的主要方式：
完全備份
完全備份（full backup）」，每個檔案都會被寫進備份檔去。如上所述，如果兩個時間點備份之間，數據沒有任何更動，那么所有備份數據都是一樣的。
這問題出自備份系統不會檢查自上次備份后，檔案有沒有被更動過；它只是機械性地將每個檔案讀出、寫入，不管檔案有沒有被修改過。備份全部選中的文件及文件夾，並不依賴文件的存盤屬性來確定備份哪些文件。
（在備份過程中，任何現有的標記都被清除，每個文件都被標記為已備份，換言之，清除存盤屬性）。
這是我們不會一味采取完全備份的原因 — 每個檔案都會被寫到備份裝置上。這表示即使所有檔案都沒有變動，還是會占據許多存儲空間。如果每天變動的檔案只有 10 MB，每晚卻要花費 100 GB 的存儲空間做備份，這絕對不是個好方法；這也就是推出「增量備份（incremental backups） 的主要原因。
增量備份
跟完全備份不同，增量備份備份上一次的完全備份后發生變化的所有文件，檔案的最后修改時間是否比上次備份的時間來得晚。如果不是的話，那表示自上次備份后，這檔案並沒有被更動過，所以這次不需要備份。換句話說，如果修改日期「的確」比上次更動的日期來得晚，那么檔案就被更動過，需要備份。
增量備份常常跟完全備份合用（例如每個星期做完全備份，每天做增量備份）差異備份是針對完全備份：備份上一次的完全備份后發生變化的所有文件。
（差異備份過程中，只備份有標記的那些選中的文件和文件夾。它不清除標記，既：備份后不標記為已備份文件，換言之，不清除存盤屬性）。
使用增量備份最大的好處在於備份速度：它的速度比完整備份快上許多，同時由於增量備份在做備份前會自動判斷備份時間點及文件是否已作改動，所以相對於完全備份其對於節省存儲空間也大有益處。增量備份的不足之處在於數據還原的時間較長，效率相對較低，例如，如果您要還原一個備份檔案，您必須把所有增量備份的磁盤都找一遍，直到找到為止，如果您要復原整個檔案系統，那就得先復原最近一次的完整備份，然后復原一個又一個的增量備份。
要避免復原一個又一個的遞增數據，提升數據的復原的效率，把做法稍微改變一下，就變成了「差異備份（differential backup）」。
差異備份
差異備份與增量備份一樣，差異備份是針對完全備份。但前者的備份是「累積（cumulative）」的—— 一個檔案只要自上次完整備份后，曾被更新過，那么接下來每次做差異備份時，這個檔案都會被備份（當然，直到下一次完整備份為止）。
這表示差異備份中的檔案，都是自上次完全備份之后，曾被改變的檔案。如果要復原整個系統，那么您只要先復原完全備份，再復原最后一次的差異備份即可。增量備份是針對於上一次備份（無論是哪種備份）：備份上一次備份后，所有發生變化的文件。
（增量備份過程中，只備份有標記的選中的文件和文件夾，它清除標記，既：備份后標記文件，換言之，清除存盤屬性。）
跟增量備份所使用的策略一樣，您平時只要定期做一次完全備份，再定時做差異備份即可。
所以，差異備份的大小，會隨着時間過去而不斷增加（假設在完全備份間，每天修改的檔案都不一樣）。以備份空間與速度來說，差異備份介於遞增備份與完全備份之間；但不管是復原一個檔案或是整個系統，速度通常比完全備份、增量備份快（因為要搜尋 / 復原的磁盤數目比較少）。
基於這些特點，差異備份是值得考慮的方案，增量備份與差異備份技術在部分中高端的網絡附加存儲設備如IBM、HP、及自由遁等品牌的部分產品的附帶軟件中已內置。
事務日志備份： 在特定事務日志備份之前執行的完整數據庫備份和上次差異備份（如果有）。在完整數據庫備份之后執行的所有事務日志備份或在特定事務日志備份之前執行的差異備份（如果您還原了差異備份）。如果你設置了恢復模式為【簡單】，你將無法使用【事務日志】備份。SQL Server 2000 和 SQL Server 2005： 創建事務日志備份，您必須使用完整恢復或大容量日志記錄恢復模型。
部分備份： 通過指定 READ_WRITE_FILEGROUPS 創建的備份稱為“部分備份”。在簡單恢復模式下，只允許對只讀文件組執行文件組備份。還原的數據備份類型：數據庫備份、部分備份或文件備份。對於數據庫備份或部分備份，日志備份序列必須從數據庫備份或部分備份的結尾處開始延續。對於一組文件備份，日志備份序列必須從整組文件備份的開頭開始延續。
文件備份： “文件備份”包含一個或多個文件（或文件組）中的所有數據。
日志鏈： 連續的日志備份序列稱為“日志鏈”。日志鏈從數據庫的完整備份開始。通常，僅當第一次備份數據庫時，或者將恢復模式從簡單恢復模式切換到完整恢復模式或大容量日志恢復模式之后，才會開始一個新的日志鏈。除非在創建完整數據庫備份時選擇覆蓋現有備份集，否則現有的日志鏈將保持不變。在該日志鏈保持不變的情況下，便可從媒體集中的任何完整數據庫備份還原數據庫，然后再還原相應恢復點之前的所有后續日志備份。恢復點可以是上次日志備份的結尾，也可以是任何日志備份中的特定恢復點。
2、不同備份類型組合應用的示例
（1）、完全備份與差異備份
以每周數據備份計划為例，我們可以在星期一進行完全備份，在星期二至星期五進行差異備份。如果在星期五數據被破壞了，則你只需要還原星期一完全的備份和星期四的差異備份。這種策略備份數據需要較多的時間，但還原數據使用較少的時間。
（2）、完全備份與增量備份
還是以每周數據備份為例，在星期一進行完全備份，在星期二至星期五進行增量備份。如果在星期五數據被破壞了，則你需要還原星期一正常的備份和從星期二至星期五的所有增量備份。這種策略備份數據需要較多的時間，但還原數據使用較少的時間。
一個備份方案例子： 某個站點在星期天晚上執行完整數據庫備份。在白天每隔 4 小時制作一個事務日志備份集，並用當天的備份重寫頭一天的備份。每晚則進行差異備份。如果數據庫的某個數據磁盤在星期四上午 9:12 出現故障，則該站點可以：
1) 備份當前事務日志；（已經出現故障了，如何備份當前事務日志？）
2) 還原從星期天晚上開始的數據庫備份；
3) 還原從星期三晚上開始的差異備份，將數據庫前滾到這一時刻；
4) 還原從早上 4 點到 8 點的事務日志備份，以將數據庫前滾到早上 8 點；
5) 還原故障之后的日志備份。這將使數據庫前滾到故障發生的那一刻。
二、還原步驟
創建一個叫TestBackup的數據庫，創建一張叫Table1的表，這個時候進行一次完整備份，備份文件為：TestBackupDB-full.bak；接着創建表Table2后進行差異備份，備份文件為：TestBackupDB-diff.bak；接着創建表Table3后進行事務日志備份（如果數據庫設置了恢復模式為【簡單】，那么在備份類型選項中將看不到【事務日志】），備份文件為：TestBackupDB-log.bak；
創建一個叫TestBackup2的數據庫，用於測試TestBackup數據庫的備份文件的還原。
（圖1：創建庫結構）
（圖2：備份類型）
下面我們就可以對三個備份文件：TestBackupDB-full.bak、TestBackupDB-diff.bak、TestBackupDB-log.bak進行還原：
步驟1：還原完整備份文件TestBackupDB-full.bak，選項如圖4、圖5所示，還原成功后數據列表就會如圖6所示，這是因為恢復狀態選項：不對數據庫執行任何操作，不回滾未提交的事務。可以還原其他事務日志。(RESTORE WITH NORECOVERY)
（圖3：進入SSMS還原）
（圖4：還原常規）
（圖5：還原選項）
（圖6：完整備份還原）
步驟2：還原差異備份文件TestBackupDB-diff.bak，操作如步驟1所示，這個時候的數據庫還是跟圖6的狀態一樣的。
步驟3：還原事務日志備份文件TestBackupDB-log.bak，如圖7進入事務日志的還原操作界面；看圖8的選項中有指定事務的時間進行還原（還原過程中的恢復狀態都是默認為RESTORE WITH RECOVERY，所以這里沒有提及這個選項）。還原后的TestBackup2數據庫，還原之后的數據庫TestBackup2如圖9所示。
（圖7：進入事務日志）
（圖8：事務日志）
（圖9：還原后的數據庫）
三、升級
通常來說文章寫到這里就應該結束了，但是很幸運，再給你介紹一下如何在對表進行分區后的還原操作，從上面的操作來看只包括了mdf和ldf文件，但如果多了幾個ndf文件，這些還原又一樣嗎？所以我稱這部分的內容為升級。
情景一：如果本來就有對應的分區文件的，只要在還原的時候修改【還原為】的文件名就可以進行還原了。
情景二：如果剛剛新建了分區文件組和文件，這個時候接着還原備份就會出現圖10的錯誤（不知道是不是在SQL Server 2005的問題）；要解決這個問題有兩個方法，第一個：重啟數據庫服務再還原；第二個：設置數據庫的【限制訪問】設置為【Single】；
（圖10：錯誤）