數據庫備份那點事兒

本文轉載自查看原文 2016-11-09 18:16 6425 buckup database/ SQL SERVER 管理/ 備份

寫在前面

　　最近一直在整理數據庫最佳實踐的東西，我也會將各種文章建議，同步到博客園，希望能夠幫助更多的人了解數據庫，輕松玩轉數據庫，同時也減輕運維人員的工作壓力，畢竟熟能生巧，熟練既是效率。

　　數據庫備份老生常談的話題，一搜索數據庫備份可能上千上萬篇，那么為什么還要寫一篇？因為重要！而往往卻不能引起運維人員的重視。上周還幫助一個客戶恢復了數據，原因是斷電，啟動服務器后發現磁盤損壞，重要的系統頁大面積損壞。使用常規數據庫恢復手段全無用，使用第三方恢復工具也只能恢復部分數據，根本無法滿足業務的正常運轉，數據是企業的命根子，丟了，找不回來怎么辦？難道要經歷一次這樣的洗禮才能體會到備份的重要性么？

　　數據庫備份是個很重的話題，太多東西無法寫在同一篇文章中，另外這是一篇大量文字的掃盲文章，不足之處希望大家多多包涵。

一些名詞

　　完整數據庫備份：完整數據庫備份就是復制數據庫里的所有信息，通過單個完整備份，就能將數據庫恢復到某個時間點的狀態。

注：由於數據庫備份是一個在線的操作，一個大的完整數據庫備份可能需要一個小時甚至更長的時間，數據庫在這段時間里還會發生變化，所以完整數據庫備份還要對部分事務日志進行備份，以便能夠恢復數據庫到一個事務一致的狀態。

　　文件備份：文件備份指備份一個或多個文件或文件組中的所有數據。

注：在完整恢復模式下，一整套完整文件備份和涵蓋所有文件備份的日志備份合起來等同於完整數據庫備份。

使用文件備份能夠只還原損壞的文件，而不用還原數據庫的其余部分，從而可加快恢復速度。例如，如果數據庫由位於不同磁盤上的若干個文件組成，在其中一個磁盤發生故障時，只需還原這個故障磁盤上的文件的備份，其他磁盤上的文件無須還原，這樣會縮短還原時間。
　　部分備份：部分備份與完整數據庫備份類似，但是部分備份默認只包含數據庫可讀寫部分，數據庫的只讀文件將不會被備份。

注：因為只讀部分是不會發生變動的，總是去備份它有點浪費時間與精力所以部分備份在希望不備份只讀文件組時非常有用。部分備份可以說是數據庫備份和文件備份之間的一個中間類型。如果一個數據庫里沒有只讀文件，那么部分備份和數據庫備份就沒什么差別。　

　　差異備份：差異備份要求數據庫之前做過一次完整備份。差異備份僅捕獲自該次完整備份后發生更改的數據，這個完整備份被稱為差異備份的“基准”。差異備份僅包括建立差異基准后更改的數據。差異備份比差異基准更小且更快，便於執行頻繁備份，從而降低了數據丟失的風險。

　　日志備份：數據備份集中精力於數據文件的備份。對於日志文件，相應地有事務日志備份。每個日志備份包括創建備份時處於活動狀態的部分事務日志，以及先前日志備份中未備份的所有日志記錄。不間斷的日志備份序列包含數據庫的完整(即連續不斷的)日志鏈。在完整恢復模式下(或者在大容量日志恢復模式下的某些時候)，連續不斷的日志鏈可以將數據庫還原到任意時間點。

　　尾日志備份：“結尾日志備份”捕獲尚未備份的任何日志記錄（“結尾日志”），以防丟失所做的工作並確保日志鏈完好無損。在將 SQL Server 數據庫恢復到其最近一個時間點之前，必須先備份數據庫的事務日志。結尾日志備份將是數據庫還原計划中相關的最后一個備份。

注意：並非所有還原方案都要求執行結尾日志備份。如果恢復點包含在較早的日志備份中，則無需結尾日志備份。此外，如果您准備移動或替換（覆蓋）數據庫，並且在最新備份后不需要將該數據庫還原到某一時間點，則不需要結尾日志備份。

　　僅復制備份(Copy-Only)：獨立於常規SQL Server備份序列的SQL Server備份。通常，進行備份會更改數據庫並影響其后備份的還原序列。但是，有時在不影響數據庫全部備份和還原過程的情況下，為特殊目的而進行備份還是有用的。為實現此目的，SQL Server引人了下列兩種僅復制備份
　　(1)僅復制完整備份
僅復制完整備份也備份整個數據庫的內容。它和正常的完整備份的區別是，做完了以后差異備份的基准不會變，因此不影響差異備份序列。
　　(2)僅復制日志備份
僅復制日志備份只備份當前日志文件里現有的內容，但是不會清空日志文件里備份下的日志。因此，下次再做正常日志備份的時候，這些內容還會被再次備份下來，從而不影響常規日志備份的序列。這種備份主要用在以下情況:數據庫上已經有了一個備份計划任務在運行，但是現在需要緊急做一個日志備份，但同時不能影響到原有的備份序列。

　　恢復模式：SQL Server 備份和還原操作發生在數據庫的恢復模式的上下文中。恢復模式旨在控制事務日志維護。 “恢復模式”是一種數據庫屬性，它控制如何記錄事務，事務日志是否需要（以及允許）進行備份，以及可以使用哪些類型的還原操作。有三種恢復模式：簡單恢復模式、完整恢復模式和大容量日志恢復模式。通常，數據庫使用完整恢復模式或簡單恢復模式。數據庫可以隨時切換為其他恢復模式。

恢復模式	說明	工作丟失的風險	能否恢復到時點？
Simple	無日志備份。自動回收日志空間以減少空間需求，實際上不再需要管理事務日志空間。有關簡單恢復模式下數據庫備份的詳細信息，請參閱完整數據庫備份 (SQL Server)。簡單恢復模式不支持要求事務日志備份的操作。在簡單恢復模式中不能使用以下功能： -日志傳送 -AlwaysOn 或數據庫鏡像 -沒有數據丟失的介質恢復 -時點還原	最新備份之后的更改不受保護。在發生災難時，這些更改必須重做。	只能恢復到備份的結尾。有關詳細信息，請參閱完整數據庫還原（簡單恢復模式）。有關簡單恢復模式的更多深入說明，請參閱由 MSSQLTips! 人員提供的 SQL Server 簡單恢復模式。
Full	需要日志備份。數據文件丟失或損壞不會導致丟失工作。可以恢復到任意時點（例如應用程序或用戶錯誤之前）。有關完整恢復模式下的數據庫備份的信息，請參閱完整數據庫備份 (SQL Server) 和完整數據庫還原（完整恢復模式）。	正常情況下沒有。如果日志尾部損壞，則必須重做自最新日志備份之后所做的更改。	如果備份在接近特定的時點完成，則可以恢復到該時點。有關使用日志備份還原到故障點的信息，請參閱將 SQL Server 數據庫還原到某個時間點（完整恢復模式）。注意：如果有兩個或更多必須在邏輯上保持一致的完整恢復模式數據庫，則最好執行特殊步驟，以確保這些數據庫的可恢復性。有關詳細信息，請參閱包含標記的事務的相關數據庫的恢復。
大容量日志	需要日志備份。是完整恢復模式的附加模式，允許執行高性能的大容量復制操作。通過使用最小方式記錄大多數大容量操作，減少日志空間使用量。有關盡量減少日志量的操作的信息，請參閱事務日志 (SQL Server)。有關大容量日志恢復模式下的數據庫備份的信息，請參閱完整數據庫備份 (SQL Server) 和完整數據庫還原（完整恢復模式）。	如果在最新日志備份后發生日志損壞或執行大容量日志記錄操作，則必須重做自該上次備份之后所做的更改。否則不丟失任何工作。	可以恢復到任何備份的結尾。不支持時點恢復。

常規建議

　生產系統不要使用簡單恢復模式

　　建議說明：簡單恢復模式並不適合生產系統。因為對生產系統而言，丟失最新的更改是無法接受的，我們建議使用完整恢復模式。

　　基礎小知識：在簡單模式下，可以采用兩種備份方式：全備份和差異備份。這兩種備份消耗都會比較大，所以不是可以頻繁備份的類型，所以在兩次備份間隔的時間段內數據都存在丟失的風險。微軟官方文檔：簡單恢復模式下的備份

　　實際場景小故事：很多維護人員喜歡簡單模式，因為簡單模式自動回收日志空間以減少空間需求，實際上不再需要管理事務日志空間。但實際情況時因為明白這其中的奧妙原理么？並不是，甚至相反，我在很多的客戶系統看到跑着上TB的數據，而數據庫備份模式竟然是簡單模式，只有每天的全備份，連差異備份都沒有。

　　我一般會問：“現在的備份模式可能會丟一天的數據，公司能接受么？”　　

　　維護人員：“那肯定不能接受呀！”

　　我又問：“那為什么不采用更好的備份方式呢？”

　　維護人員：“我也不太懂，不知道該怎么做，數據庫跑這么久了，沒那么容易壞吧？”

　使用完整恢復模式，要有日志備份計划

　　建議說明：完整恢復模式使用日志備份在最大范圍內防止出現故障時丟失數據，這種模式需要備份和還原事務日志（“日志備份”）。使用日志備份的優點是允許您將數據庫還原到日志備份中包含的任何時點（“時點恢復”）。可以使用一系列日志備份將數據庫前滾到其中一個日志備份中包含的任意時點。

　　基礎小知識：完整模式下，可以采用日志的頻繁備份來縮小數據丟失的時間，比如：00:00點做了全備份，每10分鍾一次日志備份，那么當23：50數據庫損壞，只需要使用0點的全備份和損壞之前日志備份就可以還原到23:50的數據，而不是丟失整個近一天的數據。日志備份會使不活動的日志重用，這樣也解決了完整模式下日志不斷增長的問題。微軟官方文檔：在完整恢復模式下備份

　　實際場景小故事：很多客戶的系統采用了完整恢復模式，但是缺少日志備份，那么這樣和簡單模式有什么區別呢？有區別，沒有降低數據丟失的風險反而增加了日志的空間消耗。很多時候被問到這樣的問題，數據庫日志很大，怎么收縮？很多數據庫新手可能完全不知道日志備份的作用，而采用把恢復模式改成簡單，然后收縮！再改回完整模式！比較搞笑的問題還有數據庫搭建了鏡像或AlwaysOn可用組（必須完整恢復模式），竟然把鏡像拆掉，然后改成簡單，收縮后

再重新搭建....很多時候只需要一個日志備份就可以解決的問題！

　系統數據庫備份

　　SQL Server 維護一組系統級數據庫（稱為“系統數據庫”），這些數據庫對於服務器實例的運行至關重要。每次進行大量更新后，都必須備份多個系統數據庫。必須備份的系統數據庫包括 msdb、 master和 model。如果有任何數據庫在服務器實例上使用了復制，則還必須備份 distribution 系統數據庫。備份這些系統數據庫，就可以在發生系統故障（例如硬盤丟失）時還原和恢復 SQL Server 系統。

　　而往往系統數據庫得不到關注，在維護任務中是缺失的。

　使用壓縮備份

　　數據庫往往比較大，那么同樣備份文件占用的空間也很大，由於常常要保留幾天甚至一周的數據在本地磁盤，壓縮備份可以極大的減少備份文件對磁盤空間的占用。同時因為文件小了，備份產生IO的壓力也會降低，但會對消耗比較多的CPU。

　使用校驗和（CHECKSUM）

　　此選項主要是在備份的時候校驗是否存在殘缺頁（也可以理解成是否有數據頁損壞），開啟此選項可以在備份時及時發現數據是否存在問題。

　　詳細說明請參見：數據庫備份checksum選項你會用么？

　驗證備份可用性

　　驗證備份但不還原備份，檢查備份集是否完整以及整個備份是否可讀。但是，RESTORE VERIFYONLY 不嘗試驗證備份卷中的數據結構。在Microsoft SQL Server 中，RESTORE VERIFYONLY 得到了增強以對數據進行附加檢查，從而提高檢測到錯誤的可能性。其目標是盡可能接近實際的還原操作。

　　RESTORE VERIFYONLY 執行下列檢查：

備份集是否完整以及所有卷是否可讀。
數據庫頁中的一些標頭字段，例如頁 ID（就如同要寫入數據一樣）。
校驗和（如果介質中提供的話）。
目標設備中是否有足夠的空間。

　有異地備份

　　防止本地磁盤損壞或者整個機房故障，對這種至關重要的數據，必須采取異地備份的辦法。

　定期檢查磁盤空間

　　很多客戶運維的策略不完善，同時又缺少巡檢的過程，很多時候備份作業創建后沒有及時維護，導致磁盤空間被占滿，備份作業失敗。

簡單與完整模式下的備份詳細描述

　　簡單恢復模式下的備份

　　簡單恢復模式是最簡單的備份和還原形式。該恢復模式同時支持數據庫備份和文件備份，但不支持日志備份。事務日志數據僅與關聯的用戶數據一起備份。缺少日志備份可簡化備份和還原的管理。但是，數據庫只能還原到最近備份的末尾。

　　下圖顯示了簡單恢復模式下最簡單的備份與還原策略。此策略僅使用包含數據庫中所有數據的完整數據庫備份。存在五個完整數據庫備份，但只需要還原最近的備份（在 t5 時點執行的備份）。還原此備份會將數據庫恢復到 t5 時點。由 t6 框表示的所有后續更新都將丟失。

　　最大程度地降低工作丟失的風險

　　在簡單恢復模式下，在執行下次完整備份或差異備份前，所做工作丟失的風險會隨時間的推移而增加。與完整備份不同的是，差異備份僅包括自上次完整備份以來所做的更改。因此，我們建議您在不影響備份管理的前提下時常備份，以免丟失大量數據。

下圖顯示了僅使用數據庫備份的備份計划的工作丟失風險。此策略僅適用於可經常備份的小型數據庫。

下圖顯示的備份策略通過使用差異數據庫備份對數據庫備份進行補充，從而減少了工作丟失風險。在第一個數據庫備份完成后，會接着進行三個差異數據庫備份。第三個差異備份足夠大，因而下一個備份為完整數據庫備份。該數據庫備份將成為新的差異基准。

　　 在完整恢復模式下備份

　　完整恢復模式使用日志備份在最大范圍內防止出現故障時丟失數據，這種模式需要備份和還原事務日志（“日志備份”）。使用日志備份的優點是允許您將數據庫還原到日志備份中包含的任何時點（“時點恢復”）。可以使用一系列日志備份將數據庫前滾到其中一個日志備份中包含的任意時點。請注意，為了最大程度地縮短還原時間，可以對相同數據進行一系列差異備份以補充每個完整備份。

假定可以在發生嚴重故障后備份活動日志，則可將數據庫一直還原到沒有發生數據丟失的故障點處。使用日志備份的缺點是它們需要使用存儲空間並會增加還原時間和復雜性。

　　下圖顯示了在完整恢復模式下的最簡單的備份策略。在此圖中，已完成了完整數據庫備份 Db_1 以及兩個例行日志備份 Log_1 和 Log_2。在 Log_2 日志備份后的某個時間，數據庫出現數據丟失。在還原這三個備份前，數據庫管理員必須備份活動日志（日志尾部）。然后還原 Db_1、Log_1 和 Log_2，而不恢復數據庫。接着數據庫管理員還原並恢復結尾日志備份 (Tail)。這將把數據庫恢復到故障點，從而恢復所有數據。