在上一期月報中我們分享了SQL Server三種常見的備份技術及工作方式，本期月報将分享如何充分利用三者的優點來制定SQL Server資料庫的備份和還原政策以達到資料庫快速災難恢複能力。
<a href="http://mysql.taobao.org/monthly/2017/11/03/">上期月報：MSSQL · 最佳實踐 · SQL Server三種常見備份</a>
在詳細介紹SQL Server的災備政策之前，我們先簡要介紹三個重要的術語：
RTO (Recovery Time Objective)恢複時間目标，是指出現災難後多長時間能成功恢複資料庫，即企業可容許服務中斷的最大時間長度。比如說災難發生後一天内恢複成功，則RTO值就是二十四小時；
RPO (Recovery Point Objective)恢複點目标，是指服務恢複後，恢複回來的資料所對應的最新時間點。比如企業每天淩晨零晨進行完全備份一次，那麼這個全備恢複回來的系統資料隻會是最近災難發生當天那個淩晨零時的資料；
ERT(Estimated Recovery Time)預估恢複時間，是指根據備份鍊路的長度和備份檔案的大小以及裝置的還原效率來估算的服務恢複時間。
從以上的三個術語解釋來看，最優的災備方案是RTO極小，即出現故障能夠立馬恢複資料；RPO無線接近故障時間點，即最少的資料丢失；ERT最小，即可快速恢複服務。但是，現實場景中的災備方案往往很難達到如此優化的方案。
以上三個術語是衡量災備方案和還原政策優劣的重要名額，我們的災備政策的目标也是無限的靠近RTO、RPO和ERT的最優值。以下我們列舉一個典型的災備場景來分析和解答：
假設某個企業對SQL Server資料庫DBA提出的災難恢複要求是資料丢失不超過一小時（RPO不超過一小時），在盡可能短的時間内（RTO盡可能短）恢複應用資料庫服務，且災備政策必須具備任意時間點還原的能力。
綜合上一期月報分享，我們先抛開災備政策的優劣來看，我們看看三種典型的災備政策方案是否可以實作RPO？
每個小時一次完全備份：備份檔案過大，備份還原效率低下，這種方案無法實作任意時間點的還原；
每天一個完全備份 + 每小時一個日志備份：解決了備份檔案過大和效率問題，也可以實作任意時間點還原，但是拉長了日志還原鍊條；
每天一個完全備份 + 每六個小時一個差異備份 + 每小時一個日志備份：具備任意時間點還原的能力，綜合了備份檔案大小、效率和備份鍊條長度。
從這個分析來看，也恰好應證了上一期的月報中的結論，即：完全備份集是所有備份的基礎，但資料量大且備份耗時；事務日志備份集相對較小且快速，但會拉長備份檔案還原鍊條，增大還原時間開銷；差異備份解決了事務日志備份鍊條過長的問題。
我們假裝置份資料增量為每小時1GB，初始完全備份大小為100GB，按照時間次元計算每小時産生的備份集大小，統計如下：
假設我們非常重要的訂單資料庫，在13:30被人為的錯誤删除掉了，災備系統在14:00進行了一個事務日志備份。那麼，這個事務日志備份對我們業務的災難恢複就非常關鍵和重要了，它使得我們有能力将資料庫還原到13:29:59這個時間點。如此，我們隻會丢失13:30 - 14:00之間的這半個小時的資料（實際上我們也有能力找回13:30 - 14:00）。但是，如果沒有14:00這個事務日志備份檔案，但存在13:00的事務日志備份檔案的話，我們的系統資料會丢失13:00 - 14:00之間這一個小時的資料，一個小時的資料丢失是公司不被允許的。場景如下圖展示：
我們可以使用以下方法模拟災備方案和災難恢複的步驟：
第一步：建立測試資料庫并修改為FULL模式
第二步：建立一個完全備份
第三步：每一個小時做一次事務日志備份
第四步：每六個小時做一個差異備份
詳細的模拟方法和語句如下所示：
我們看看測試表的資料情況，方框選中的這條資料是需要我們恢複出來的：
我們也可以再次檢查資料庫備份曆史記錄，來確定災備資訊準确性：
查詢的災備曆史記錄展示如下：
從這個備份曆史記錄來看，和我們的測試表中的資料是吻合且對應起來的。
接下來，我們需要根據TestDR資料庫的備份檔案，将資料庫恢複到模拟時間點2017-12-17 23:04:45.130（即真實場景中的發生人為操作失誤的時間點13:30），為了包含ID為15的這條資料，我們就恢複到2017-12-17 23:04:46.130時間點即可，然後檢檢視看ID等于15的這條記錄是否存在，如果這條記錄存在，說明我們備份和還原政策工作正常，否則無法實作公司的要求。為了試驗的目的，我們先把TestDR資料庫删除掉（真實環境，請不要随意删除資料庫，這很危險）：
為了實作災難恢複，我們需要先把完全備份檔案恢複，然後一個接一個的事務日志備份按時間升序恢複，在最後一個事務日志恢複的時候，使用STOPAT關鍵字恢複到時間點并把資料庫Recovery回來帶上線，詳細的代碼如下：
從測試表中的資料展示來看，我們已經成功的将ID為15的這條資料還原回來，即發生人為失誤導緻的資料丢失（災難）已經恢複回來了。
細心的你一定發現了這個恢複方案，使用的是完全備份 + 很多個事務日志備份來恢複資料的，這種方案的恢複鍊條十分冗長，在這裡，恢複到第13個備份檔案才找回了我們想要的資料。有沒有更為簡單，恢複更為簡潔的災難恢複方案呢？請看恢複方案二。
為了解決完全備份 + 日志備份恢複鍊條冗長的問題，我們接下來采取一種更為簡潔的恢複方案，即采用完全備份 + 差異備份 + 事務日志備份的方法來實作災難恢複，方法如下：
從這個災難恢複鍊路來看，将災難恢複的步驟從13個備份檔案減少到4個備份檔案，鍊路縮短，方法變得更為簡潔快速。當然同樣可以實作相同的災難恢複效果，滿足公司的對資料RPO的要求。
當然災難恢複的方法除了使用腳本以外，微軟的SSMS工具通過IDE UI操作也是可以達到相同的效果，可以實作相同的功能，方法如下：右鍵點選你需要還原的資料庫 => Tasks => Restore => Database，如下如所示：
選擇Timeline => Specific date and time => 設定你需要還原到的時間點（這裡選擇2017-12-17 23:04:46） => 确定。
時間點恢複還原時間消耗取決于你資料庫備份檔案的大小，在我的例子中，一會功夫，就已經還原好你想要的資料庫了。
本期月報是繼前一個月分享SQL Server三種常見的備份技術後的深入，詳細講解了如何制定災備政策來滿足企業對災難恢複能力的要求，并以一個具體的例子來詳細闡述了SQL Server災備的政策和災難恢複的方法，使企業在資料庫災難發生時，資料損失最小化。但是，這裡還是有一個疑問暫時留給讀者：為什麼我們可以使用多種災難恢複（我們這裡隻談到了兩種，實際上還有其他方法）的方法呢？到底底層的原理是什麼的？預知後事如何，我們下期月報分享。
<a href="https://sqlbak.com/academy/point-in-time-recovery/">典型場景中的場景圖</a>
<a href="https://sqlbak.com/academy/point-in-time-recovery/">Point-in-time recovery</a>