MySQL · 最佳實踐 · SQL Server三種常見備份 已認證的機構
本期月報是SQL Server數據庫備份技術系列文章的開篇，介紹三種常見的SQL Server備份方法的工作方式、使用T-SQL語句和使用SSMS IDE創建備份集三個層面，介紹SQL Server的三種常見備份的工作原理和使用方法。三種常見的備份包括：
?數據庫完全備份（Full Backup）
?數據庫日志備份（Transaction Log Backup）
?數據庫差異備份（Differential Backup）
備份的重要性在開始分享之前，我們首先來看看數據庫備份的重要性。進入DT時代，數據的價值越發體現，數據已經成為每個公司賴以生存的生命線，數據的重要性不言而喻，而公司絕大多數核心數據都存放在數據庫里。數據庫本身的災難恢復（DR）能力是數據安全的最后一道防線，也是數據庫從業者對數據安全底線的堅守。數據庫中數據潛在的安全風險包括：硬件故障、惡意入侵、用戶誤操作、數據庫損壞和自然災害導致的數據損失等。在關系型數據庫SQL Server中，數據庫備份是災難恢復的能力有力保證。
Full BackupFull Backup（完全備份）是SQL Server所有備份類型中，最為簡單、最基礎的數據庫備份方法，它提供了某個數據庫在備份時間點的完整拷貝。但是，它僅支持還原到數據庫備份成功結束的時間點，即不支持任意時間點還原操作。
Full Backup工作方式以上是Full Backup是什么的解釋，那么接下來，我們通過一張圖和案例來解釋Full Backup的工作原理。
這是一張某數據庫的數據產生以及數據庫備份在時間軸上的分布圖，從左往右，我們可以分析如下：
7 P.m.：產生了數據#1
10 P.m.：數據庫完全備份，備份文件中包含了#1
2 a.m.：產生了數據#2，目前數據包含#1，#2
6 a.m.：產生了數據#3，目前數據包含#1，#2，#3
10 a.m.：數據庫完全備份，備份文件中包含#1，#2，#3
1 p.m.：產生了數據#4，目前數據包含#1，#2，#3，#4
5 p.m.：產生了數據#5，目前數據包含#1，#2，#3，#4，#5
8 p.m.：產生了數據#6，目前數據包含#1，#2，#3，#4，#5，#6
10 p.m.：數據庫完全備份，備份文件中包含了數據#1，#2，#3，#4，#5，#6
從這張圖和相應的解釋分析來看，數據庫完全備份工作原理應該是非常簡單的，它就是數據庫在備份時間點對所有數據的一個完整拷貝。當然在現實的生產環境中，事務的操作遠比這個復雜，因此，在這個圖里面有兩個非常重要的點沒有展示出來，那就是：
?備份操作可能會導致I/O變慢：由于數據庫備份是一個I/O密集型操作，所以在數據庫備份過程中，可能會導致數據庫的I/O操作變慢。
?全備份過程中，數據庫的事務日志不能夠被截斷：對于具有大事務頻繁操作的數據庫，可能會導致事務日志空間一直不停頻繁增長，直到占滿所有的磁盤剩余空間，這個場景在阿里云RDS SQL產品中有很多的客戶都遇到過。其中之一解決方法就需要依賴于我們后面要談到的事務日志備份技術。
T-SQL創建Full Backup使用T-SQL語句來完成數據庫的完全備份，使用BACKUP DATABASE語句即可，如下，對AdventureWorks2008R2數據庫進行一個完全備份：
USE masterGOBACKUP DATABASE [AdventureWorks2008R2] TO DISK = ’C:TempAdventureWorks2008R2_20171112_FULL.bak’ WITH COMPRESSION, INIT, STATS = 5;GO SSMS IDE創建Full Backup
除了使用T-SQL語句創建數據庫的完全備份外，我們還可以使用SSMS IDE界面操作來完成，方法：
右鍵點擊想要備份的數據庫 => Tasks => Backup => 選擇FULL Backup Type => 選擇Disk 做為備份文件存儲 => 點擊Add 添加備份文件 => 選擇你需要存儲備份文件的目錄 => 輸入備份文件名，如下圖兩張圖展示。
Back up Database設置界面
SQL Server數據庫完全備份是數據庫的完整拷貝，所以備份文件空間占用相對較大，加之可能會在備份過程中導致事務日志一直不斷增長。為了解決這個問題，事務日志備份可以很好的解決這個問題，因為：事務日志備份記錄了數據庫從上一次日志備份到當前時間內的所有事務提交的數據變更，它可以配合數據庫完全備份和差異備份（可選）來實現時間點的還原。當日志備份操作成功以后，事務日志文件會被截斷，事務日志空間將會被重復循環利用，以此來解決完全備份過程中事務日志文件一致不停增長的問題，因此我們最好能夠周期性對數據庫進行事務日志備份，以此來控制事務日志文件的大小。但是這里需要有一個前提是數據庫必須是FULL恢復模式，SIMPLE恢復模式的數據庫不支持事務日志的備份，當然就無法實現時間點的還原。請使用下面的語句將數據庫修改為FULL恢復模式，比如針對AdventureWorks2008R2數據庫：
USE [master]GOALTER DATABASE [AdventureWorks2008R2] SET RECOVERY FULL WITH NO_WAITGO Transaction Log Backup工作方式
事務日志備份與數據完全備份工作方式截然不同，它不是數據庫的一個完整拷貝，而是至上一次日志備份到當前時間內所有提交的事務數據變更。用一張圖來解釋事務日志備份的工作方式：
00:01：事務#1，#2，#3開始，未提交
00:02：事務#1，#2，#3成功提交；#4，#5，#6事務開始，未提交；這時備份事務日志；事務日志備份文件中僅包含已提交的#1，#2，#3的事務（圖中的LSN 1-4，不包含#4）
00:04：由于在00:02做了事務日志備份，所以#1，#2，#3所占用的空間被回收；#4，#5，#6事務提交完成
00:05：事務#7已經提交成功；#8，#9，#10開始，但未提交；事務日志備份文件中包含#4，#5，#6，#7的事務（圖中的LSN4-8，不包含#8）。
從這張圖我們看到，每個事務日志備份文件中包含的是已經完成的事務變更，兩次事務日志備份中存放的是完全不同的變更數據。而每一次事務日志備份成功以后，事務日志空間可以被成功回收，重復利用，達到了解決數據庫完全備份過程中事務日志一致不斷增長的問題。
T-SQL創建事務日志備份使用T-SQL語句來創建事務日志的備份方法如下：
USE MasterGOBACKUP LOG [AdventureWorks2008R2]TO DISK = N’C:tempAdventureWorks2008R2_log_201711122201.trn’ with compression,stats=1;GOBACKUP LOG [AdventureWorks2008R2]TO DISK = N’C:tempAdventureWorks2008R2_log_201711122202.trn’ with compression,stats=1;GOBACKUP LOG [AdventureWorks2008R2]TO DISK = N’C:tempAdventureWorks2008R2_log_201711122203.trn’ with compression,stats=1;GO SSMS IDE創建事務日志備份
使用SSMS IDE創建事務日志備份的方法：
右鍵點擊想要創建事務日志備份的數據庫 => Tasks => Backup => 選擇Transaction Log Backup Type => 選擇Disk 做為備份文件存儲 => 點擊Add 添加備份文件 => 選擇你需要存儲備份文件的目錄 => 輸入備份文件名，如下圖展示：
由于數據庫完全備份是時間點數據的完整拷貝，每個數據庫完整備份相互獨立，而多個事務日志備份是通過事務日志鏈條連接在一起，事務日志鏈起點于完全備份，SQL Server中的每一個事務日志備份文件都擁有自己的FirstLSN和LastLSN，FirstLSN用于指向前一個事務日志備份文件的LastLSN；而LastLSN指向下一個日志的FirstLSN，以此來建立這種鏈接關系。這種鏈接關系決定了事務日志備份文件還原的先后順序。當然，如果其中任何一個事務日志備份文件丟失或者破壞，都會導致無法恢復整個事務日志鏈，僅可能恢復到你擁有的事務日志鏈條的最后一個。事務日志備份鏈條的關系如下圖所示：
我們使用前面“T-SQL創建事務日志備份”創建的事務日志鏈，使用RESTORE HEADERONLY方法來查看事務日志鏈的關系：
USE MasterGORESTORE HEADERONLY FROM DISK = N’C:tempAdventureWorks2008R2_log_201711122201.trn’;RESTORE HEADERONLY FROM DISK = N’C:tempAdventureWorks2008R2_log_201711122202.trn’;RESTORE HEADERONLY FROM DISK = N’C:tempAdventureWorks2008R2_log_201711122203.trn’;
查詢結果如下：
從這個結果展示來看，事務日志備份文件AdventureWorks2008R2_log_201711122201的LastLSN指向了的AdventureWorks2008R2_log_201711122202的FirstLSN，而AdventureWorks2008R2_log_201711122202的LastLSN又指向了AdventureWorks2008R2_log_201711122203的FirstLSN，以此來建立了事務日志備份鏈條關系。假如AdventureWorks2008R2_log_201711122202的事務日志備份文件丟失或者損壞的話，數據庫只能還原到AdventureWorks2008R2_log_201711122201所包含的所有事務行為。
這里有一個問題是：為了防止數據庫事務日志一直不斷的增長，而我們又不想每次都對數據庫做完全備份，那么我們就必須對數據庫事務日志做周期性的日志備份，比如：5分鐘甚至更短，以此來降低數據丟失的風險，以此推算每天會產生24 * 12 = 288個事務日志備份，這樣勢必會導致事務日志恢復鏈條過長，拉長恢復時間，增大了數據庫還原時間（RTO）。這個問題如何解決就是我們下面章節要分享到的差異備份技術。
Differential Backup事務日志備份會導致數據庫還原鏈條過長的問題，而差異備份就是來解決事務日志備份的這個問題的。差異備份是備份至上一次數據庫全量備份以來的所有變更的數據頁，所以差異備份相對于數據庫完全備份而言往往數據空間占用會小很多。因此，備份的效率更高，還原的速度更快，可以大大提升我們災難恢復的能力。
Differential Backup工作方式我們還是從一張圖來了解數據庫差異備份的工作方式：
7 a.m.：數據包含#1
10 a.m.：數據庫完全備份，備份文件中包含#1
1 p.m.：數據包含#1，#2，#3，#4
2 p.m.：數據庫差異備份，備份文件中包含#2，#3，#4（上一次全備到目前的變更數據）
4 p.m.：數據包含#1，#2，…，#6
6 p.m.：數據庫差異備份，備份文件中包含#2，#3，#4，#5，#6
8 p.m.：數據包含#1，#2，…，#8
10 p.m.：數據庫完全備份，備份文件中包含#1，#2，…，#8
11 p.m.：產生新的數據#9，#10;數據包含#1，#2，…，#10
2 a.m.：數據庫差異備份，備份文件中包含#9，#10
從這個差異備份的工作方式圖，我們可以很清楚的看出差異備份的工作原理：它是備份繼上一次完全備份以來的所有數據變更，所以它大大減少了備份日之鏈條的長度和縮小備份集的大小。
T-SQL創建差異備份使用T-SQL語句創建差異備份的方法如下：
USE masterGOBACKUP DATABASE [AdventureWorks2008R2] TO DISK = ’C:TempAdventureWorks2008R2_20171112_diff.bak’ WITH DIFFERENTIALGO SSMS創建差異備份
使用SSMS IDE創建差異備份的方法：
右鍵點擊想要創建事務日志備份的數據庫 => Tasks => Backup => 選擇Differential Backup Type => 選擇Disk 做為備份文件存儲 => 點擊Add 添加備份文件 => 選擇你需要存儲備份文件的目錄 => 輸入備份文件名，如下圖展示：
本期月報分享了SQL Server三種常見的備份技術的工作方式和備份方法。數據庫完全備份是數據庫備份時間的一個完整拷貝；事務日志備份是上一次日志備份到當前時間的事務日志變更，它解決了數據庫完全備份過程中事務日志一直增長的問題；差異備份上一次完全備份到當前時間的數據變更，它解決了事務日志備份鏈過長的問題。
將SQL Server這三種備份方式的工作方式，優缺點總結如下表格：
從這個表格，我們知道每種備份有其各自的優缺點，那么我們如何來制定我們的備份和還原策略以達到快速災難恢復的能力呢？這個話題，我們將在下一期月報中進行分享。
來自：https://zhuanlan.zhihu.com/p/31355859
相關文章：
網公網安備