摘要

本期月報(bào)是SQL Server數(shù)據(jù)庫備份技術(shù)系列文章的開篇，介紹三種常見的SQL Server備份方法的工作方式、使用T-SQL語句和使用SSMS IDE創(chuàng)建備份集三個(gè)層面，介紹SQL Server的三種常見備份的工作原理和使用方法。三種常見的備份包括：

?數(shù)據(jù)庫完全備份（Full Backup）

?數(shù)據(jù)庫日志備份（Transaction Log Backup）

?數(shù)據(jù)庫差異備份（Differential Backup）

備份的重要性

在開始分享之前，我們首先來看看數(shù)據(jù)庫備份的重要性。進(jìn)入DT時(shí)代，數(shù)據(jù)的價(jià)值越發(fā)體現(xiàn)，數(shù)據(jù)已經(jīng)成為每個(gè)公司賴以生存的生命線，數(shù)據(jù)的重要性不言而喻，而公司絕大多數(shù)核心數(shù)據(jù)都存放在數(shù)據(jù)庫里。數(shù)據(jù)庫本身的災(zāi)難恢復(fù)（DR）能力是數(shù)據(jù)安全的最后一道防線，也是數(shù)據(jù)庫從業(yè)者對(duì)數(shù)據(jù)安全底線的堅(jiān)守。數(shù)據(jù)庫中數(shù)據(jù)潛在的安全風(fēng)險(xiǎn)包括：硬件故障、惡意入侵、用戶誤操作、數(shù)據(jù)庫損壞和自然災(zāi)害導(dǎo)致的數(shù)據(jù)損失等。在關(guān)系型數(shù)據(jù)庫SQL Server中，數(shù)據(jù)庫備份是災(zāi)難恢復(fù)的能力有力保證。

Full Backup

Full Backup（完全備份）是SQL Server所有備份類型中，最為簡(jiǎn)單、最基礎(chǔ)的數(shù)據(jù)庫備份方法，它提供了某個(gè)數(shù)據(jù)庫在備份時(shí)間點(diǎn)的完整拷貝。但是，它僅支持還原到數(shù)據(jù)庫備份成功結(jié)束的時(shí)間點(diǎn)，即不支持任意時(shí)間點(diǎn)還原操作。

Full Backup工作方式

以上是Full Backup是什么的解釋，那么接下來，我們通過一張圖和案例來解釋Full Backup的工作原理。

這是一張某數(shù)據(jù)庫的數(shù)據(jù)產(chǎn)生以及數(shù)據(jù)庫備份在時(shí)間軸上的分布圖，從左往右，我們可以分析如下：

7 P.m.：產(chǎn)生了數(shù)據(jù)#1

10 P.m.：數(shù)據(jù)庫完全備份，備份文件中包含了#1

2 a.m.：產(chǎn)生了數(shù)據(jù)#2，目前數(shù)據(jù)包含#1，#2

6 a.m.：產(chǎn)生了數(shù)據(jù)#3，目前數(shù)據(jù)包含#1，#2，#3

10 a.m.：數(shù)據(jù)庫完全備份，備份文件中包含#1，#2，#3

1 p.m.：產(chǎn)生了數(shù)據(jù)#4，目前數(shù)據(jù)包含#1，#2，#3，#4

5 p.m.：產(chǎn)生了數(shù)據(jù)#5，目前數(shù)據(jù)包含#1，#2，#3，#4，#5

8 p.m.：產(chǎn)生了數(shù)據(jù)#6，目前數(shù)據(jù)包含#1，#2，#3，#4，#5，#6

10 p.m.：數(shù)據(jù)庫完全備份，備份文件中包含了數(shù)據(jù)#1，#2，#3，#4，#5，#6

從這張圖和相應(yīng)的解釋分析來看，數(shù)據(jù)庫完全備份工作原理應(yīng)該是非常簡(jiǎn)單的，它就是數(shù)據(jù)庫在備份時(shí)間點(diǎn)對(duì)所有數(shù)據(jù)的一個(gè)完整拷貝。當(dāng)然在現(xiàn)實(shí)的生產(chǎn)環(huán)境中，事務(wù)的操作遠(yuǎn)比這個(gè)復(fù)雜，因此，在這個(gè)圖里面有兩個(gè)非常重要的點(diǎn)沒有展示出來，那就是：

?備份操作可能會(huì)導(dǎo)致I/O變慢：由于數(shù)據(jù)庫備份是一個(gè)I/O密集型操作，所以在數(shù)據(jù)庫備份過程中，可能會(huì)導(dǎo)致數(shù)據(jù)庫的I/O操作變慢。

?全備份過程中，數(shù)據(jù)庫的事務(wù)日志不能夠被截?cái)啵簩?duì)于具有大事務(wù)頻繁操作的數(shù)據(jù)庫，可能會(huì)導(dǎo)致事務(wù)日志空間一直不停頻繁增長(zhǎng)，直到占滿所有的磁盤剩余空間，這個(gè)場(chǎng)景在阿里云RDS SQL產(chǎn)品中有很多的客戶都遇到過。其中之一解決方法就需要依賴于我們后面要談到的事務(wù)日志備份技術(shù)。

T-SQL創(chuàng)建Full Backup

使用T-SQL語句來完成數(shù)據(jù)庫的完全備份，使用BACKUP DATABASE語句即可，如下，對(duì)AdventureWorks2008R2數(shù)據(jù)庫進(jìn)行一個(gè)完全備份：

USE masterGOBACKUP DATABASE [AdventureWorks2008R2] TO DISK = ’C:TempAdventureWorks2008R2_20171112_FULL.bak’ WITH COMPRESSION, INIT, STATS = 5;GO SSMS IDE創(chuàng)建Full Backup

除了使用T-SQL語句創(chuàng)建數(shù)據(jù)庫的完全備份外，我們還可以使用SSMS IDE界面操作來完成，方法：

右鍵點(diǎn)擊想要備份的數(shù)據(jù)庫 => Tasks => Backup => 選擇FULL Backup Type => 選擇Disk 做為備份文件存儲(chǔ) => 點(diǎn)擊Add 添加備份文件 => 選擇你需要存儲(chǔ)備份文件的目錄 => 輸入備份文件名，如下圖兩張圖展示。

Back up Database設(shè)置界面

Transaction Log Backup

SQL Server數(shù)據(jù)庫完全備份是數(shù)據(jù)庫的完整拷貝，所以備份文件空間占用相對(duì)較大，加之可能會(huì)在備份過程中導(dǎo)致事務(wù)日志一直不斷增長(zhǎng)。為了解決這個(gè)問題，事務(wù)日志備份可以很好的解決這個(gè)問題，因?yàn)椋菏聞?wù)日志備份記錄了數(shù)據(jù)庫從上一次日志備份到當(dāng)前時(shí)間內(nèi)的所有事務(wù)提交的數(shù)據(jù)變更，它可以配合數(shù)據(jù)庫完全備份和差異備份（可選）來實(shí)現(xiàn)時(shí)間點(diǎn)的還原。當(dāng)日志備份操作成功以后，事務(wù)日志文件會(huì)被截?cái)啵聞?wù)日志空間將會(huì)被重復(fù)循環(huán)利用，以此來解決完全備份過程中事務(wù)日志文件一致不停增長(zhǎng)的問題，因此我們最好能夠周期性對(duì)數(shù)據(jù)庫進(jìn)行事務(wù)日志備份，以此來控制事務(wù)日志文件的大小。但是這里需要有一個(gè)前提是數(shù)據(jù)庫必須是FULL恢復(fù)模式，SIMPLE恢復(fù)模式的數(shù)據(jù)庫不支持事務(wù)日志的備份，當(dāng)然就無法實(shí)現(xiàn)時(shí)間點(diǎn)的還原。請(qǐng)使用下面的語句將數(shù)據(jù)庫修改為FULL恢復(fù)模式，比如針對(duì)AdventureWorks2008R2數(shù)據(jù)庫：

USE [master]GOALTER DATABASE [AdventureWorks2008R2] SET RECOVERY FULL WITH NO_WAITGO Transaction Log Backup工作方式

事務(wù)日志備份與數(shù)據(jù)完全備份工作方式截然不同，它不是數(shù)據(jù)庫的一個(gè)完整拷貝，而是至上一次日志備份到當(dāng)前時(shí)間內(nèi)所有提交的事務(wù)數(shù)據(jù)變更。用一張圖來解釋事務(wù)日志備份的工作方式：

00:01：事務(wù)#1，#2，#3開始，未提交

00:02：事務(wù)#1，#2，#3成功提交；#4，#5，#6事務(wù)開始，未提交；這時(shí)備份事務(wù)日志；事務(wù)日志備份文件中僅包含已提交的#1，#2，#3的事務(wù)（圖中的LSN 1-4，不包含#4）

00:04：由于在00:02做了事務(wù)日志備份，所以#1，#2，#3所占用的空間被回收；#4，#5，#6事務(wù)提交完成

00:05：事務(wù)#7已經(jīng)提交成功；#8，#9，#10開始，但未提交；事務(wù)日志備份文件中包含#4，#5，#6，#7的事務(wù)（圖中的LSN4-8，不包含#8）。

從這張圖我們看到，每個(gè)事務(wù)日志備份文件中包含的是已經(jīng)完成的事務(wù)變更，兩次事務(wù)日志備份中存放的是完全不同的變更數(shù)據(jù)。而每一次事務(wù)日志備份成功以后，事務(wù)日志空間可以被成功回收，重復(fù)利用，達(dá)到了解決數(shù)據(jù)庫完全備份過程中事務(wù)日志一致不斷增長(zhǎng)的問題。

T-SQL創(chuàng)建事務(wù)日志備份

使用T-SQL語句來創(chuàng)建事務(wù)日志的備份方法如下：

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創(chuàng)建事務(wù)日志備份

使用SSMS IDE創(chuàng)建事務(wù)日志備份的方法：

右鍵點(diǎn)擊想要?jiǎng)?chuàng)建事務(wù)日志備份的數(shù)據(jù)庫 => Tasks => Backup => 選擇Transaction Log Backup Type => 選擇Disk 做為備份文件存儲(chǔ) => 點(diǎn)擊Add 添加備份文件 => 選擇你需要存儲(chǔ)備份文件的目錄 => 輸入備份文件名，如下圖展示：

事務(wù)日志備份鏈

由于數(shù)據(jù)庫完全備份是時(shí)間點(diǎn)數(shù)據(jù)的完整拷貝，每個(gè)數(shù)據(jù)庫完整備份相互獨(dú)立，而多個(gè)事務(wù)日志備份是通過事務(wù)日志鏈條連接在一起，事務(wù)日志鏈起點(diǎn)于完全備份，SQL Server中的每一個(gè)事務(wù)日志備份文件都擁有自己的FirstLSN和LastLSN，F(xiàn)irstLSN用于指向前一個(gè)事務(wù)日志備份文件的LastLSN；而LastLSN指向下一個(gè)日志的FirstLSN，以此來建立這種鏈接關(guān)系。這種鏈接關(guān)系決定了事務(wù)日志備份文件還原的先后順序。當(dāng)然，如果其中任何一個(gè)事務(wù)日志備份文件丟失或者破壞，都會(huì)導(dǎo)致無法恢復(fù)整個(gè)事務(wù)日志鏈，僅可能恢復(fù)到你擁有的事務(wù)日志鏈條的最后一個(gè)。事務(wù)日志備份鏈條的關(guān)系如下圖所示：

我們使用前面“T-SQL創(chuàng)建事務(wù)日志備份”創(chuàng)建的事務(wù)日志鏈，使用RESTORE HEADERONLY方法來查看事務(wù)日志鏈的關(guān)系：

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’;

查詢結(jié)果如下：

從這個(gè)結(jié)果展示來看，事務(wù)日志備份文件AdventureWorks2008R2_log_201711122201的LastLSN指向了的AdventureWorks2008R2_log_201711122202的FirstLSN，而AdventureWorks2008R2_log_201711122202的LastLSN又指向了AdventureWorks2008R2_log_201711122203的FirstLSN，以此來建立了事務(wù)日志備份鏈條關(guān)系。假如AdventureWorks2008R2_log_201711122202的事務(wù)日志備份文件丟失或者損壞的話，數(shù)據(jù)庫只能還原到AdventureWorks2008R2_log_201711122201所包含的所有事務(wù)行為。

這里有一個(gè)問題是：為了防止數(shù)據(jù)庫事務(wù)日志一直不斷的增長(zhǎng)，而我們又不想每次都對(duì)數(shù)據(jù)庫做完全備份，那么我們就必須對(duì)數(shù)據(jù)庫事務(wù)日志做周期性的日志備份，比如：5分鐘甚至更短，以此來降低數(shù)據(jù)丟失的風(fēng)險(xiǎn)，以此推算每天會(huì)產(chǎn)生24 * 12 = 288個(gè)事務(wù)日志備份，這樣勢(shì)必會(huì)導(dǎo)致事務(wù)日志恢復(fù)鏈條過長(zhǎng)，拉長(zhǎng)恢復(fù)時(shí)間，增大了數(shù)據(jù)庫還原時(shí)間（RTO）。這個(gè)問題如何解決就是我們下面章節(jié)要分享到的差異備份技術(shù)。

Differential Backup

事務(wù)日志備份會(huì)導(dǎo)致數(shù)據(jù)庫還原鏈條過長(zhǎng)的問題，而差異備份就是來解決事務(wù)日志備份的這個(gè)問題的。差異備份是備份至上一次數(shù)據(jù)庫全量備份以來的所有變更的數(shù)據(jù)頁，所以差異備份相對(duì)于數(shù)據(jù)庫完全備份而言往往數(shù)據(jù)空間占用會(huì)小很多。因此，備份的效率更高，還原的速度更快，可以大大提升我們?yōu)碾y恢復(fù)的能力。

Differential Backup工作方式

我們還是從一張圖來了解數(shù)據(jù)庫差異備份的工作方式：

7 a.m.：數(shù)據(jù)包含#1

10 a.m.：數(shù)據(jù)庫完全備份，備份文件中包含#1

1 p.m.：數(shù)據(jù)包含#1，#2，#3，#4

2 p.m.：數(shù)據(jù)庫差異備份，備份文件中包含#2，#3，#4（上一次全備到目前的變更數(shù)據(jù)）

4 p.m.：數(shù)據(jù)包含#1，#2，…，#6

6 p.m.：數(shù)據(jù)庫差異備份，備份文件中包含#2，#3，#4，#5，#6

8 p.m.：數(shù)據(jù)包含#1，#2，…，#8

10 p.m.：數(shù)據(jù)庫完全備份，備份文件中包含#1，#2，…，#8

11 p.m.：產(chǎn)生新的數(shù)據(jù)#9，#10;數(shù)據(jù)包含#1，#2，…，#10

2 a.m.：數(shù)據(jù)庫差異備份，備份文件中包含#9，#10

從這個(gè)差異備份的工作方式圖，我們可以很清楚的看出差異備份的工作原理：它是備份繼上一次完全備份以來的所有數(shù)據(jù)變更，所以它大大減少了備份日之鏈條的長(zhǎng)度和縮小備份集的大小。

T-SQL創(chuàng)建差異備份

使用T-SQL語句創(chuàng)建差異備份的方法如下：

USE masterGOBACKUP DATABASE [AdventureWorks2008R2] TO DISK = ’C:TempAdventureWorks2008R2_20171112_diff.bak’ WITH DIFFERENTIALGO SSMS創(chuàng)建差異備份

使用SSMS IDE創(chuàng)建差異備份的方法：

右鍵點(diǎn)擊想要?jiǎng)?chuàng)建事務(wù)日志備份的數(shù)據(jù)庫 => Tasks => Backup => 選擇Differential Backup Type => 選擇Disk 做為備份文件存儲(chǔ) => 點(diǎn)擊Add 添加備份文件 => 選擇你需要存儲(chǔ)備份文件的目錄 => 輸入備份文件名，如下圖展示：

最后總結(jié)

本期月報(bào)分享了SQL Server三種常見的備份技術(shù)的工作方式和備份方法。數(shù)據(jù)庫完全備份是數(shù)據(jù)庫備份時(shí)間的一個(gè)完整拷貝；事務(wù)日志備份是上一次日志備份到當(dāng)前時(shí)間的事務(wù)日志變更，它解決了數(shù)據(jù)庫完全備份過程中事務(wù)日志一直增長(zhǎng)的問題；差異備份上一次完全備份到當(dāng)前時(shí)間的數(shù)據(jù)變更，它解決了事務(wù)日志備份鏈過長(zhǎng)的問題。

將SQL Server這三種備份方式的工作方式，優(yōu)缺點(diǎn)總結(jié)如下表格：

從這個(gè)表格，我們知道每種備份有其各自的優(yōu)缺點(diǎn)，那么我們?nèi)绾蝸碇贫ㄎ覀兊膫浞莺瓦€原策略以達(dá)到快速災(zāi)難恢復(fù)的能力呢？這個(gè)話題，我們將在下一期月報(bào)中進(jìn)行分享。

來自：https://zhuanlan.zhihu.com/p/31355859