SQL Server

了解 SQL Server 備份

Paul S. Randal

 

一眼:

  • 完整備份
  • 交易記錄檔備份
  • 差異式備份
  • 備份策略計劃和備份的完整性

內容

完整備份
差異式備份
交易記錄檔備份
備份策略計劃
備份的完整性
摘要

您真的需要進行 SQL Server 備份嗎吗? [是]。 除非您不在意您的資料,或您不在乎不必完全重新建立您的資料庫損毀的事件中您需要將資料庫還原到可用的點的方法。 有些人認為有其他地方,資料庫的重複複本移除需要有備份,但要是的複製已損壞或無法存取吗? 備份是仍然需要以確保您永遠可以復原。

但是,您會採取何種備份應該呢? 您頻率應該把它們? 效果為何他們對資料庫與工作負載會? 而且如何執行確定它們都是有效嗎?

放在一起的備份策略是您可能會認為,比實際更加容易,即使 [備份] 和 [還原] 指令有一個眾多的選項。 我會協助您找出所有。

這是三個部分數列中的第一個文件。 下面第 1 部份中我會討論備份。 在組件 2 (9 月 2009年問題) 中我將探討從使用備份在嚴重損壞復原。 並在組件 3 (11 月 2009年問題) 中我會查看從備份不嚴重損壞復原。 我要到有點深度比平常這些的文件,但您應該可以跟隨的背景材質。

本月份的本文我將說明如何的基本概念各種類型的備份工作而且方式可能會想要在備份策略中使用它們。 如果您有一些交易記錄檔方式 (請參閱我的文件 」 的知識,它會協助 了解記錄和 SQL Server 中的復原." 還有沒有點中有備份,如果它們證實為損毀,當您嘗試使用,所以我也會說明如何加入某些完整性檢查它們。 一路我將 debunk 常見 misconceptions 部分,並提供進一步資訊的連結。

我不會要執行這項操作是說明備份語法的運作方式,以及如何執行各種不同的備份類型。 SQL Server 線上叢書 》 有很好的區段涵蓋這個,為什麼浪費此處複製它的空間? 請參閱 [] 主題 備份 (Transact-SQL)」 的詳細資訊,特別範例 > 章節結尾。 主題 」 備份及還原使用說明主題 (SQL Server 管理 Studio)"說明如何使用工具來執行備份。 您最好閱讀此的文件之後檢閱使用說明,因為在此我要說明什麼,以及原因。

您的備份策略的實作是相當簡單的一部份。 設計有效的策略是非常重要,雖然經常被忽略組件。

完整備份

最簡單類型是備份的完整的資料庫備份。 也可能的執行單一的資料檔案或檔案群組的完整備份。 不過,這些不常使用,而且所討論的所有原則套用至它們,太,我將焦點在資料庫層級的備份。 但的 SQL Server 2005,每一種更細微的備份類型使用完全相同 (這不是在 SQL Server 2000 中,則為 True)。 相同套用於差異式備份 — 可以在檔案、 檔案群組或資料庫層級執行,但這些相同的所有工作,如就也無論的元件被都備份。

完整資料庫備份提供完整的資料庫複本,並提供一個單一的時間點可以還原資料庫。 即使它可能需要執行備份處理程序的許多小時,您仍然可以還原備份到單點 (有效結尾的備份,但我會討論內容完全點是在本文稍後)。 在完整備份中不允許任何時間點復原時間執行備份時。 這也是相同的差異式備份。

沒有關於此,但是,fuelled 的事實您可以使用的] STOPAT 一個 misconception = < 時間或記錄檔序號 > 上完整及差異備份的還原選項。 雖然語法可讓它,[] 選項不會有任何作用,就有為了方便起見。

完整備份的相關的另一個 misconception 是它們只包含資料。 完整備份與差異式備份也包含某些交易記錄檔記錄,以便還原的元件 (資料庫、 檔案或檔案群組) 可以進行交易一致性。

請考慮具有單一的非叢集索引的資料表中插入一筆記錄的範例交易。 資料表和索引的頁面是透過資料檔案散佈。 內部交易分割成兩個部分: 一個資料錄插入資料表,然後插入在非叢集索引中的索引分頁中需要記錄的資料頁。 如果備份程序只是發生閱讀前資料錄插入,非叢集索引頁,但讀取資料表的資料頁記錄插入後,只是在備份資料以表示資料庫是交易不一致的。

這是交易記錄檔進入遊戲。 藉由也包含某些交易記錄檔記錄在備份,修復可以執行在還原資料庫是使其成為交易一致的複本。 此範例筆交易的認可時而定的復原部份還原可能它向前復原 (也就是說,它會為認可還原資料庫的複本中) 或復原它回 (表示它不會出現在所有在還原資料庫的複本)。 在任何的情況下會維護交易一致性,這是很重要。

完整備份會執行下列動作:

  1. 強制資料庫檢查點,並在此時請記下記錄順序編號。 這會清除至磁碟之前備份的還原復原部份必須執行的工時量最小化任何已讀取的所有更新的記憶體中的網頁。
  2. 從資料庫中的資料檔案,啟動 [讀取]。
  3. 停止讀取資料檔及產生記錄的開頭,最舊現用交易在該點的記錄檔順序編號 (請參閱這些條款我文章瞭解記錄和修復的 SQL 伺服器 」 的說明)。
  4. 讀取時所需的最多交易記錄檔。

說明必要的多少交易記錄檔最是與 [圖 1 ] 中視覺輔助工具。 在時刻表上紅色的數字會說明此清單中:

  1. 檢查點,並開始從資料庫讀取。
  2. 讀取的作業讀取第 X 頁。
  3. 交易 A 開始。
  4. 交易 A 第 X 頁,讓變更。 在備份複本現在已過期。 請注意,備份將無法讀取頁 X 一次,它已經是傳遞該點在資料庫中。
  5. 交易 B 開始。 無法完成作業完成讀取資料前。
  6. 認可交易 A。 這第 X 頁認可所做的變更。
  7. 讀取備份資料的作業完成,並讀取的交易記錄檔開始。

fig01.gif

[圖 1] 範例時刻表的變更,在完整的備份

因此在還原期間可以成功執行復原,使資料庫的所有網頁的時間都位於相同的點,足夠的交易記錄檔備份則是需要 — 資料讀取部份備份作業已完成 (點 7) 的時間。 交易記錄檔從最舊現用 (或未認可) 交易 (5 點,交易 B) 開頭至結尾的備份 (點 7),才能允許執行復原。 若要允許到相同的時間帶到的所有頁面需要交易記錄檔備份的檢查點 (點 1) 從備份 (點 7) 的結尾。

如果交易記錄檔只包含從最舊的現用交易 (點 5) 的開頭,然後從備份中還原的 X 讀取點 2 頁的複本就不會更新,以從交易 A,變更的發生點 4。 這表示它就不與其他時間完成讀取的資料作業 (點 7) 的資料庫的交易一致。

因此,交易記錄檔包含在完整備份中的最小記錄順序編號 (LSN) MIN (備份的檢查點的 LSN,最舊的現用交易的 LSN) 並可能的開始,甚至在備份開始之前的交易。 這樣可以確保資料庫的已還原的複本 (或任何您所還原 — 頁]、 [檔案]、 [檔案群組]、 [資料庫) 是完全一致。

這項機制表示所備份的作業不能以任何方式暫停交易雖然在資料庫上額外的 I/O 工作負載會降低它們稍微。 這個機制的缺點是完整備份的持續期間無法清除的交易記錄檔,因為它是必要。 如果還有很多的更新活動完整備份會花很長的時間完成這可能導致交易記錄檔成長,我已經討論在數個先前發行項中,以及 [SQL 問答] 欄位中的問題。

包含在完整備份中不一定所有的所有資料檔案的內容。 備份只會包含配置的頁面,從資料檔案。 就例如單一檔案資料庫可能很 100 GB,但是只包含 15 GB 的配置的資料。 在這種情況下,15 GB 的配置的資料加上必要的交易記錄檔,將只包含完整的備份。 (不過,還原的資料庫都是相同原始的大小 (在本例 100 GB)

另一個 misconception 是備份程序會檢查或變更它備份的資料。 這是 untrue,但不包括在單一的情況下時備份加總檢查碼已啟用,我會稍後說明,。

差異式備份

其他類型的資料是備份的差異式備份。 差異式備份執行相同的作業為一的完整備份,但只包含已變更或新增前一個完整備份之後的所有資料。 一個常見的 misconception 是差異式備份增量。 它們是實際累積及後續差異式備份,完整備份之後,並變更或新增更多的資料時,會增加的大小。

在每個 4 GB (稱為一個 GAM 間隔) 的每個資料檔案的區段是特殊的資料庫頁面稱為差異的點陣圖,會追蹤最後一次完整備份,指出已變更或被新增到資料庫的資料之後變更的 4 GB 區段 (稱為範圍) 的部分。 (有數個其他的配置點陣圖的太,而且您可以找到這些我的部落格文件中的相關資訊 」 內的儲存引擎: GAM SGAM,PFS,其他配置對應").

差異式備份會掃描透過這些點陣圖,並只會備份資料標記為變更的檔案範圍。 點陣圖會重設的下一次的完整備份,以便可以看見,越來越多的資料庫的變更多個它會標示差異的點陣圖中,且連續的差異式備份會較大及較大。 最後,如果大部分的資料庫已變更,差異式備份可能會在完整備份一樣大。 您可以發現多少您下一次差異式備份將會使用指令碼撰寫可從 [我的部落格文章" 新的指令碼: 如何多資料庫之後已經變更上次完整備份嗎?." 順便一提,這段指令碼也可以用,了解的資料庫的變換率,對於執行個體在 SharePoint 內容資料庫。

為一的快速筆記如果您想要採取的臨機操作的完整備份,而且不讓它重設差異的點陣圖您應該使用 BACKUP 陳述式上的 [的 COPY_ONLY] 選項。 這是非常有用,否則為下一個差異式備份會根據臨機操作完整備份您所採用而不是在規則 (可能排定) 的完整備份。 這可能會導致大問題當您嘗試在嚴重損壞的情況下還原。

所以為何差異式備份有用? 當我將討論的備份策略一節中,則藉由允許略過在還原處理程序中的許多交易記錄檔備份還原作業真的可以加速差異式備份因素。 很基本上是使用差異式備份比要必須重新顯示交易記錄檔記錄大量的時間取得相同的點的時間向前跳快得多。

交易記錄檔備份

交易記錄檔備份是滿或 BULK_LOGGED 復原模式中, 僅能完整及差異備份也有可能在 SIMPLE 復原模型。

交易記錄檔備份中包含最後一次記錄檔備份後所產生的所有交易記錄檔記錄 (或完整備份開始記錄檔備份鏈結),用來允許資料庫復原至特定的點的時間 (通常是時間右嚴重損壞攻擊之前)。 這表示這些累加不同於這是累積的差異式備份。 因為這些是累加如果您要將資料庫還原至特定的點的時間,式您需要的所有交易記錄檔記錄最多重新執行資料庫的變更所需的時間點。 包含在記錄檔備份鏈結。

記錄檔備份鏈結是包含所有交易記錄檔記錄復原資料庫至某一點的時間所需的記錄檔備份的未中斷的系列。 鏈結啟動以一個的完整資料庫備份,並繼續,直到項目中斷因此防止直到另一個完整或差異備份會採取所採取的多個記錄檔備份鏈結。

中斷記錄檔備份鏈結的作業包括,切換至 SIMPLE 復原模式,還原從一個的資料庫快照集和強制清除記錄檔使用的 NO_LOG 或 TRUNCATE_ONLY 選項 (也就是不適用於 SQL Server 2008)。 是 inadvisable 中斷記錄檔備份鏈結的因為它會強制另一個 (可能大) 的完整備份,所要採取。

雖然記錄檔備份鏈結回到完整備份大小時向的延伸,但是您不需要修復時還原所有這些記錄檔備份。 如果您進行完整備份,說,在星期日晚上和星期三] 晚上的記錄檔備份後星期日晚上,每半個小時再還原資料庫星期五嚴重損壞之後可以使用星期三的完整備份以及之後的所有記錄檔備份星期三晚上,而不是一直移回星期日晚上的完整備份。 (我們數列中的第二個發行項將會進入更深入本主題)。

記錄檔備份也需要幫助管理交易記錄檔的大小。 在 FULL 或 BULK_LOGGED 復原模式,記錄檔不會清除直到記錄檔備份已執行 (請參閱二月文件以取得詳細資料的哪些記錄檔清除方法),一般的記錄檔備份必須執行以防止記錄檔成長超出控制項。 如果無法清除記錄檔,記錄檔會增加,直到空間用完。 就這樣若不想要使用記錄檔備份的時間點復原,最簡單的選項是切換至 SIMPLE 復原模型和不使用 [滿或 BULK_LOGGED 復原模式。 我討論這個部落格文章中的多個深度" 適當的交易記錄檔大小管理的重要性."

藉由允許某些作業,以執行最少式記錄的作業,會記錄頁面配置,不實際的插入的資料可以改善效能的記錄中沒有一種特殊情況。 這可改善執行效能的作業,例如大量載入,並重建索引。 在這些的情況下,不是所有相關作業會記錄,如此備份記錄檔記錄不包含足夠的資訊來完全重新執行此作業。 在這種情況下可以還原與修復可能運作方式如果沒有足夠的資訊?

答案是最少式記錄的作業之後的第一個記錄檔備份也會包含一些資料。 如同先前所述的點陣圖差異,沒有另一個呼叫最少式記錄的點陣圖 (有時也稱為大量變更對應) 的點陣圖。 這個點陣圖會追蹤已變更資料檔的範圍,因為最少式記錄作業。

將掃描這些點陣圖中的最少式記錄的作業之後,記錄檔備份,並也備份標示為已變更的那些資料範圍。 點陣圖會清除之後被掃描。 這表示記錄檔備份有足夠的資訊完全在還原記錄檔備份時,重新執行的資料庫中作業將最少式記錄的效果。 還有一書的不過: 有什麼在任何特定的資料範圍已變更時,該記錄檔備份。 因此也包含最少式記錄的作業的資料記錄檔備份無法還原的任何位置的時間以外的時間期間涵蓋結尾 (或欠如果記錄檔備份是您正在還原從一個記錄檔備份鏈結的一部分)。 因此時您可以取得的效能改進,切換至 BULK_LOGGED 復原模式時,, 您必須考慮變更它為暫存作業 — 只以改善您的批次程序和批次程序完成後您應該切換回滿儘速執行記錄檔備份。

也沒有特殊大小寫記錄檔備份,讓記錄檔備份之後的損毀資料檔損毀。 這就稱為位置可以資料檔損毀或損毀,但可以備份到損毀所導致的所有交易記錄檔一的記錄尾端 (或尾端記錄) 備份。 這可讓 (稱為最新的復原) 的最小的工作遺失之後還原資料庫的是,但,它支援 FULL 復原模式中執行資料庫時,只。 這些資訊越來越限制最少式記錄的作業都可以在線上叢書 》 主題中找到" 機尾的記錄檔備份." 第一個畫面轉換所附本文顯示展示的記錄尾端備份。

在 SQL Server 到 SQL Server 2005 之前的版本中,交易記錄檔備份不能執行與完整資料庫或差異式資料庫備份的同時,它們會被封鎖直到資料庫層級備份已完成。 檔案與檔案群組為基礎的備份並不會造成封鎖記錄檔備份。 此複雜的檔案與檔案群組備份的復原程序時它給它們的優點不封鎖記錄檔備份。 在 SQL Server 2005 中, 所有的完整及差異備份 (不論是元件) 會在相同的方式。 並行交易記錄檔備份完成,但交易記錄檔不會清除直到完整或差異式備份 (也就需要記錄檔) 也會完成,現在會行為。

備份策略計劃

現在,就瞭解三種類型的備份,以及它們如何運作我將示範如何您可能會將它們放在一起到備份策略。

我收到一個常見的問題是如何開始思考備份策略。 我一定要說您不應該設計備份策略。 您應該設計還原策略 — 可讓您還原一些儘嚴重損壞的事件是您的停機時間越小越同時仍然保留您的資料。 完成您的已處理的出之後再運作出您需要您需要讓您可以執行還原哪個備份。 亦即您的備份策略應該讓您以符合您的修復時間目標 (RTO) 和修復點目標 (RPO)。

僅包含完整的備份策略與您有些限制中您可以還原用做什麼。 基本上,您可以只還原 圖 2 ] 中的每個完整備份的時間。 如果損毀的星期六攻擊在 23: 59,只排定在下一個完整備份之前先然後自上次完整備份之後的所有工作可能都會遺失。 這個原因如果需要避免資料遺失,而且無法重新建立資料,記錄檔備份也是包含, [圖 3 ] 所示。

fig02.gif

[圖 2 只完整備份的備份策略

fig03.gif

[圖 3 記錄檔備份與完整的備份策略

想像一下記錄檔備份被採用每隔 30 分鐘。 只要可用的所有備份,這表示資料庫可以還原的任何位置的時間。 但是,這仍可能不是最佳的策略。 如果損毀攻擊在 23: 59 星期六與此項策略的地方嗎? 第一件事,就是需要一個尾端的--記錄備份,並啟動還原。

若要將資料庫還原最多在嚴重損壞的還原最後一個星期日的完整備份,然後 336 記錄檔備份 (就是每日,加上星期六 47 48 記錄檔備份加上的記錄尾端備份六天) 表示。 根據多少變換時發生資料庫中上一週的大量交易記錄檔將會需要很長的時間若要重新執行。 這很明顯地不是最佳的還原策略,但看在 [] 欄位中是常見的策略。 如果您有一個策略,就像這樣,請確定您已學會進行還原,因此您知道自己是否可以符合您的 RTO 嚴重損壞的事件。

若要減輕這個問題,一些策略,請使用更頻繁的完整備份,但這些可能是極大,取得每一天,執行個體。 替代方案是使用只包含資料的前次完整備份後已有所變更的差異式備份。 在繼續我們的範例該策略說明在 [ 圖 4]

fig04.gif

[圖 4 以完整、 記錄和差異備份的備份策略

這項策略 23: 59 星期六在嚴重損壞修復是許多更快。 請記住差異式備份是累積 — 還原策略是星期日完整備份、 00: 00 星期六差異式備份,加上從星期六的所有記錄檔備份。 有差異式備份從 00: 00 星期六表示可以略過前的所有記錄檔備份,如差異式備份中包含的還原所有這些網路結果相同記錄檔備份。

這是一個很簡單,且 contrived 的範例,但它清楚地顯示每一種備份類型的優點。 一旦您設計完您的備份策略,確定您測試以確保它可以讓您執行您想要的還原。

以下是我看到一個客戶圖示回幾年的範例。 客戶損毀的資料庫,並且想要復原的零資料遺失。 使用其備份 reluctant 和它們嘗試一份的資料庫上執行修復,但是它必須刪除強制它們到使用其備份的資料。 它已經開啟時所必須一月的完整備份,加上一個記錄檔備份到 4 月的每個 half-hour — 超過 5,000 的備份磁帶總計及所有! 我確定您正在復原您的眼睛,想: 「 我當然它無法運作,"但事實上一樣 ; 但是,花三天來執行這個動作 ! 客戶認為他們有很好的備份策略 — FULL 復原模型以及記錄檔備份,但其備份策略不允許它們要他們想在還原。

備份的完整性

還有沒有點中有備份,如果您發現它們損毀當您嘗試從其還原。 就說最好的方式檢查您備份的有效性是其他的伺服器上對它們進行還原,但在 SQL Server 2005 中引進的新功能允許某些備份的完整性檢查,以執行而不必實際還原它們。 您可以使用 WITH CHECKSUM 選項,當進行備份 (任何不同)。

這在整個備份資料流,儲存在備份本身中建立加總檢查碼。 如果備份是完整或差異式,且資料庫啟用頁總合檢查碼,然後這個選項也會造成所有現有頁總合檢查碼進行測試,備份程序會讀取頁面。 如果找不到錯誤頁面總和檢查碼備份作業會失敗。 這提供好保護不小心備份已經以某種方式損毀的資料庫。 (您可以找到頁總合檢查碼的相關資訊 」 的有效資料庫維護的前提示 「 文件中從 2008 年 8 月)。

一旦完成備份,它可驗證使用類似下面的命令:

RESTORE VERIFYONLY FROM <backup device(s)> WITH CHECKSUM

這樣,就重新加總檢查碼計算整個備份的資料流傳送,而它比較則儲存在備份中。 完整及差異備份的它也會在備份中測試頁面上的任何頁面總和檢查碼。 如果找不到任何問題再您知道該備份已損毀以某種方式。

自然,有例外此項規則可能會想要備份損毀的資料庫 (如果它只有您和您要對執行個體執行修復,資料庫的複本)。 在這種情況下您可以強制備份完成使用的 CONTINUE_AFTER_ERROR] 選項。

您可以在找到需備份驗證的相關資訊 在我的部落格上的備份驗證資訊並也監看我示範備份的驗證,在第二個畫面轉換隨附這份文件中的某些方面。

摘要

如同任何複雜的主題中,有大量的備份,我沒有涵蓋,空間區域,但是,現在包含了基本概念您可以深入某些更深入的資訊的線上叢書和部落格連結。 最好在線上叢書 》 中啟動是主題" 備份概觀 (SQL Server)." 在 [我的部落格上您可以開始使用, 備份/還原類別.

一個區域,您可能會認為是 conspicuous 中它缺少是備份壓縮。 這是故意的因為我將會涵蓋它稍後在所有新壓縮技術在 SQL Server 2008 中的文件中年份中。 同時在您可以檢查線上叢書 》 主題 < 備份壓縮 (SQL Server)和也在 我的部落格.

如果我必須加上三個項目符號點本文,他們會是:

  • 請確定您有備份。
  • 請確定您有有效的備份。
  • 請確定您有正確的備份。

亦即會備份如果您希望能夠還原您的資料庫執行項目,就知道當您需要,並請確定您可以從備份還原時,能夠備份以及符合您的 RTO 和 RPO。

下一個本文我將說明所有關於從備份還原包含不同類型的還原作業以及它們如何運作、 從多個備份和可用性部分資料庫還原。

中,同時以及永遠,如果有任何意見或問題刪除我一條線在 Paul@SQLskills.com。

Paul S。 Randal 是在管理主管的 SQLskills.com,SQL Server MVP,則 Microsoft 地區主管。 他曾在 SQL Server 儲存引擎小組在 Microsoft 從 1999年 2007。 Paul 撰寫的 SQL Server 2005 的 DBCC CHECKDB/修復但負責核心的儲存引擎在 SQL Server 2008 開發期間。 Paul 是嚴重損壞修復、 高可用性和資料庫維護的專家,而且一般在世界各地的會議主持人。 在他部落格 SQLskills.com/blogs/paul.