1. 備份策略

RPO（Recovery Point Objective, 恢復(fù)點目標(biāo)）

- 可以接受多少數(shù)據(jù)遺失

RTO（Recovery Time Objective, 恢復(fù)時間目標(biāo)）

- 還原可以花費多久時間，直接影響業(yè)務(wù)需要停多久時間。

備份策略對應(yīng)的需求

- 備份的類型與頻率：全量，增量，差異，日志，多久備份一次。

- 使用的備份介質(zhì)：磁帶、機械磁盤、ssd

- 備份與介質(zhì)的保存期限，過期失效

- 備份測試原則，保證備份的數(shù)據(jù)完整，正常的測試方法就是再恢復(fù)一下，看備份的數(shù)據(jù)是否都存在。

2.?恢復(fù)模式

2.1 事務(wù)日志

首先了解下事務(wù)日志，任何數(shù)據(jù)庫在寫的時候都包括兩個部分，一部分是數(shù)據(jù)，一部分是日志。微軟的MS SQL Server稱為事務(wù)日志，mysql的日志稱為binlog。

當(dāng)增、刪、改數(shù)據(jù)時，會修改buffer cache（此修改是在內(nèi)存里），然后將修改操作記錄到磁盤上的日志文件里面，當(dāng)?shù)竭_(dá)checkpoint點時，再將buffer cache中的數(shù)據(jù)寫入到數(shù)據(jù)文件中，當(dāng)把數(shù)據(jù)寫完之后，buffer cache中的臟數(shù)據(jù)（提交過的內(nèi)容）會被清空。所以物理備份一般都會包括兩部分?jǐn)?shù)據(jù)：日志和數(shù)據(jù)。

2. 事物日志作用

2.1 在需要時，回滾交易

2.2 出現(xiàn)故障時，還原數(shù)據(jù)庫

裝好數(shù)據(jù)庫之后，最好將數(shù)據(jù)和日志設(shè)置在不同的磁盤lun上，這樣當(dāng)其中一個磁盤壞了時，使用另一個磁盤也可以恢復(fù)數(shù)據(jù)。

2.3 事務(wù)日志依時間順序循環(huán)寫入

當(dāng)數(shù)據(jù)文件滿了，會清空數(shù)據(jù)文件，從頭寫入；那如果想讓日志一直寫下去，那日志文件就會無限增大，那這里就涉及到日志的截斷原則。

2.4 日志的截斷原則基于恢復(fù)模式

恢復(fù)模式和數(shù)據(jù)庫恢復(fù)沒有關(guān)系，恢復(fù)模式指的是日志的記錄方式或者記錄機制。

2.4.1 簡單模式

• 自動截斷日志以保持小的空間需求。

  日志分活動日志和不活動日志。活動日志就是操作數(shù)據(jù)還沒有寫入到數(shù)據(jù)庫里；不活動日志就是操作的數(shù)據(jù)已經(jīng)寫入到數(shù)據(jù)庫里了，日志可以截斷了，截斷就是說，我這條日志（假設(shè)是一條不活動日志）以及之前的日志對應(yīng)的數(shù)據(jù)都已經(jīng)寫入到數(shù)據(jù)庫里，可以截斷了，后面的日志可以接著我往后寫，寫到文件尾巴，然后再循環(huán)到日志文件頭寫入，因為日志文件前面的不活動日志截斷了，對應(yīng)的日志會自動清空，這就是循環(huán)寫入。

• 不允許做日志備份。

  由于非活動日志的自動截斷清空，導(dǎo)致做不了日志備份。

簡單模式下，數(shù)據(jù)庫絕大多數(shù)的高可用做不了，因為微軟的數(shù)據(jù)庫高可用依賴日志備份。

簡單模式下，如果數(shù)據(jù)壞掉了，也做不了數(shù)據(jù)庫還原，因為日志被刪掉了。

生產(chǎn)環(huán)境下不建議使用簡單模式；用作測試的時候或者數(shù)據(jù)不重要的時候可以考慮使用簡單模式。

2.4.2 完整模式

• 日志備份管理

  完整模式是最常用的一種模式，但是需要我們自己管理日志，不像簡單模式那樣做自動截斷清空的操作，完整模式會一直無限的往日志文件里增加。那日志文件越來越大怎么辦？有且只有一種方法，那就是后面3.4小節(jié)說的事務(wù)日志備份。
  

• 避免因為數(shù)據(jù)文件損壞或遺失導(dǎo)致數(shù)據(jù)遺失

  因為日志文件一直在的，所以數(shù)據(jù)文件壞了，我們也可以結(jié)合日志進(jìn)行恢復(fù)。

2.4.3 大容量日志模式

• 日志備份管理

• 可以增強大容量復(fù)制操作的效率

• 為許多大容量操作使用最少記錄以減少日志的空間使用量

大容量日志模式使用場景不多，大容量日志模式是針對批量導(dǎo)入數(shù)據(jù)的，比如一次性導(dǎo)入上千萬條數(shù)據(jù)，數(shù)據(jù)庫系統(tǒng)會先記錄日志，再導(dǎo)入數(shù)據(jù)，使用大容量日志模式，只記錄導(dǎo)入的頭和尾，中間導(dǎo)入的數(shù)據(jù)就不記錄了，這樣就可以減少記錄以減少日志的空間使用量。導(dǎo)入失敗了，因為數(shù)據(jù)文件一直是存在的，大不了重新導(dǎo)入一次。

使用大容量日志模式，可以加快大容量數(shù)據(jù)導(dǎo)入速度。

上面的恢復(fù)模式?jīng)Q定著備份機制。

3. 數(shù)據(jù)庫備份

Microsoft SQL Server備份類型

3.1 完整數(shù)據(jù)庫備份策略

所有數(shù)據(jù)文件與事務(wù)日志中的部分日志。

完整備份是其他備份模式的基礎(chǔ)。

首先思考一個問題：假設(shè)完整備份從9：00開始，12:30結(jié)束，那9:00 - 12:30之間數(shù)據(jù)庫里產(chǎn)生的日志會不會備份走？

答案是：會備份走。

那就會又有疑問了，如果是結(jié)束時間點，那什么時候結(jié)束呢？數(shù)據(jù)一直寫，備份就結(jié)束不了了嗎？這里微軟借助了日志功能，備份開始的時候，會在日志上打一個標(biāo)志，備份結(jié)束的時候再在日志上打一個標(biāo)志。備份期間產(chǎn)生的數(shù)據(jù)，先記的日志，結(jié)束的時候再把這部分?jǐn)?shù)據(jù)寫到備份里面。日志標(biāo)志之間的數(shù)據(jù)會備份，之后再產(chǎn)生的日志就不會備份了。

完整備份包含所有數(shù)據(jù)文件，同時也會備份部分日志，也就是備份開始點和結(jié)束點之間生成的日志以及對應(yīng)的數(shù)據(jù)。

在簡單模式中，數(shù)據(jù)庫只能還原到上次備份執(zhí)行的時候。

在數(shù)據(jù)不常被修改的生產(chǎn)環(huán)境中，可當(dāng)作最佳解決方案或在測試環(huán)境中使用。

創(chuàng)建好數(shù)據(jù)庫之后，必須做一次完整備份，這樣數(shù)據(jù)庫才會切換為完整模式，之后如果數(shù)據(jù)庫數(shù)據(jù)文件換了，就可以基于日志進(jìn)行恢復(fù)，否則數(shù)據(jù)庫是以簡單模式運行。

當(dāng)全備很慢的時候，原因很大概率是出在你網(wǎng)絡(luò)速度和磁盤介質(zhì)讀寫速度上，，底層備份是以多線程的形式，多個頁同時往介質(zhì)上寫。

推薦業(yè)務(wù)低峰期去做備份。

3.2 差異備份策略

從上次完整數(shù)據(jù)庫備份后數(shù)據(jù)庫變更過的部分。

包含執(zhí)行完整與差異數(shù)據(jù)庫備份。

差異備份只包括變更過的數(shù)據(jù)。

用于數(shù)據(jù)庫的某部分較其他剩余部分更頻繁地被修改時的場景。

時間長了，可以想到差異備份的數(shù)據(jù)量也會很大。

3.3 部分與文件群組備份策略

主要文件組，每個讀/寫文件組以及任何指定的只讀文件組。

原理圖：

特點：

• 適用于大型數(shù)據(jù)規(guī)模的數(shù)據(jù)庫，可以更快地備份與還原。

• 管理更復(fù)雜。

• 可以加快恢復(fù)速度，比如上圖中為了業(yè)務(wù)快速恢復(fù)，可以先恢復(fù)G8，其他組可以延遲恢復(fù)。

建議把文件組看做一個存儲邊界，不建議對單個文件做備份，單個文件里的數(shù)據(jù)是不全的，無法恢復(fù)，最好是文件組級別。如果文件組里本身就是一個文件的話，那個備份單個文件是一樣的。

只要不是恢復(fù)主要文件組，在企業(yè)版上，恢復(fù)過程中，可以保持?jǐn)?shù)據(jù)庫聯(lián)機。只有恢復(fù)的那一部分才需要脫機。

3.4 事務(wù)日志備份策略

任何已記錄在記錄文件的數(shù)據(jù)庫變更。

事務(wù)日志備份也叫增量備份，依賴于完整備份，不能獨立存在。

至少包含完整與事務(wù)日志備份。

事務(wù)日志可以恢復(fù)到特定時間點。

在發(fā)生數(shù)據(jù)文件遺失時，允許數(shù)據(jù)庫能夠完整還原。

事務(wù)日志備份的潛在風(fēng)險：

事務(wù)日志可以多頻次的備份，備份鏈太長的話，如果其中某一次的事務(wù)日志備份丟失了，那丟失點后的數(shù)據(jù)就恢復(fù)不回來了。

一般會結(jié)合差異備份制定備份策略方案，比如差異備份數(shù)據(jù)量超過30G，后面的我就改成增量備份，這樣也可以減少備份鏈節(jié)點數(shù)量。

3.5 尾部日志

就在還原操作之前對日志文件結(jié)尾執(zhí)行記錄備份。

“尾部日志備份”捕獲尚未備份的任何日志記錄，以防丟失所做的工作并確保日志鏈完好無損。

每次執(zhí)行尾部日志備份時，必須使用完整恢復(fù)模式或是大容量日志恢復(fù)模式。

其他備份只會備份一部分?jǐn)?shù)據(jù)，備份結(jié)束點之后的數(shù)據(jù)就不會備份了。當(dāng)數(shù)據(jù)庫壞掉之后，不會再有新的正常備份了，剩余未備份的日志就是尾部日志，尾部日志備份就是為了備份這部分?jǐn)?shù)據(jù)。因此一般都是在災(zāi)難發(fā)生時，要執(zhí)行尾部日志備份。下面是我的理解：

3.6?只復(fù)制

數(shù)據(jù)庫或日志文件（不影響備份順序）

3.7 其他考慮

• 系統(tǒng)數(shù)據(jù)庫是一定要備份的，微軟的系統(tǒng)數(shù)據(jù)庫包括：master（賬號、配置數(shù)據(jù)）、msdb（備份序列，各個job）、tempdb（不需要備份）、template(模板，也可以不用備)

• 為了可以恢復(fù)損壞頁，建議啟動checksum。

• 備份時可以指定64個備份設(shè)備，一份數(shù)據(jù)被拆分成64份，可以極大提高備份速度，設(shè)備間構(gòu)建的是帶區(qū)集。

• 使用mirror選項可以生成多個備份（最多4個）。

• 通過壓縮備份選項可以提高備份設(shè)備的速度，壓縮一般可以達(dá)到4-10倍之多，相對應(yīng)的恢復(fù)速度也會加快。

4. 數(shù)據(jù)庫恢復(fù)

SQL Server數(shù)據(jù)庫的還原流程，是由3個階段組成的：

• Data copy

  新建文件以及復(fù)制數(shù)據(jù)到文件中。

• Redo

  還原應(yīng)用被提交的交易。

• Undo

  還原在還原時間點未被提交的交易，撤銷未提交的操作。

當(dāng)發(fā)生故障時，比如9點時誤刪除了幾條數(shù)據(jù)，一般的恢復(fù)操作是通過全備和事務(wù)日志恢復(fù)到一個新的數(shù)據(jù)庫里，然后把對應(yīng)的數(shù)據(jù)select出來，插入到原先的數(shù)據(jù)庫里。

例子：

備份計劃：

• 在星期六晚間22:00，執(zhí)行完整數(shù)據(jù)庫備份

• 在星期一、星期二、星期四、星期五晚間22:00執(zhí)行差異備份

• 從9:00-18:00，每個小時執(zhí)行一次事務(wù)日志備份（每個小時整）

星期四的上午10點發(fā)生了故障，應(yīng)該采取什么樣的還原程序作業(yè)？

答案：

• 先做尾部日志備份

• 恢復(fù)全量備份

• 恢復(fù)周二的差異備份

• 恢復(fù)周三全天的日志備份

• 恢復(fù)周四9:00-10:00之間的事務(wù)日志

• 恢復(fù)尾部日志備份

5. 專業(yè)術(shù)語

5.1 LUN，Logical Unit Number， 邏輯單元號

其主要作用是為了給相連的服務(wù)器分配邏輯單元號。服務(wù)器識別到的最小的存儲資源，就是LUN級別的。實際環(huán)境里，LUN可以是磁盤空間、磁帶機或者media changer。

6. 參考資料

6.1?MS SQL Server數(shù)據(jù)庫備份與恢復(fù)

6.2?