數(shù)據(jù)備份對(duì)于DBA來說是一項(xiàng)最基本的工作，但又是十分關(guān)鍵的，每個(gè)SQL Server上面執(zhí)行的最重要的任務(wù)之一都是運(yùn)行備份和恢復(fù)，可以說數(shù)據(jù)備份是確保數(shù)據(jù)安全的最后一道防線。在進(jìn)行數(shù)據(jù)庫(kù)備份時(shí)有許多不同的選項(xiàng)，特別是隨著SQL Server新版本的不斷推出，為了滿足用戶不斷增長(zhǎng)的需要，微軟也與時(shí)俱進(jìn)的引入一些新的功能，這里僅僅談一些在備份過程中最有用的幾個(gè)選項(xiàng)。

壓縮(Compression)

備份壓縮是從SQL Server 2008企業(yè)版開始出現(xiàn)的，SQL Server 2008 R2的標(biāo)準(zhǔn)版也開始引進(jìn)的這個(gè)功能，它不僅僅能使你的備份文件變的更小，意味著占用了更少的存儲(chǔ)空間(微軟內(nèi)部測(cè)試，平均壓縮比5:1，注意，備份壓縮率和數(shù)據(jù)庫(kù)有關(guān)系，包括數(shù)據(jù)類型、數(shù)據(jù)是否加密以及表的設(shè)計(jì)等)，通過網(wǎng)絡(luò)進(jìn)行備份拷貝所需的網(wǎng)絡(luò)帶寬也相應(yīng)的減小，在提高你的備份和恢復(fù)操作的速度同時(shí)，相應(yīng)的也就減少了停機(jī)時(shí)間，這是很有用的一個(gè)特點(diǎn)，當(dāng)然，壓縮也需要消耗資源，它要使用更多的CPU,但是對(duì)于大多數(shù)的SQL Server系統(tǒng)來講，和I/O相比，CPU都應(yīng)該被排到后面，建議最好是在訪問的非高峰期備份時(shí)使用壓縮選項(xiàng);如果要在高峰期進(jìn)行備份，壓縮進(jìn)程所消耗的額外CPU會(huì)對(duì)并發(fā)操作產(chǎn)生不利影響,SQL Server 2014引入了資源調(diào)控器，通過將特定SQL Server用戶的會(huì)話映射到限制CPU使用的資源調(diào)控器工作負(fù)荷組，來對(duì)這些會(huì)話進(jìn)行分類(詳細(xì)內(nèi)容請(qǐng)查看SQL Server聯(lián)機(jī)叢書)。

復(fù)制(Copy_only)

根據(jù)需要滿足的down機(jī)時(shí)間和數(shù)據(jù)丟失可以制定一個(gè)備份策略，日復(fù)一日相同的操作應(yīng)該交由SQL Agent來自動(dòng)完成執(zhí)行。假設(shè)有一天你因?yàn)槠渌蛐枰粋€(gè)當(dāng)時(shí)的數(shù)據(jù)庫(kù)的完整備份，如果你進(jìn)行了完整備份，那隨后的所有備份(差異備份和日志備份)都會(huì)以此完全備份為新的起點(diǎn)，也就是說 自此次完全備份創(chuàng)建新的備份鏈，如果不想影響現(xiàn)有的備份策略，可以在完全備份時(shí)使用copy_only選項(xiàng)。

數(shù)據(jù)傳輸選項(xiàng)Buffercount和Maxtransfersize

數(shù)據(jù)庫(kù)會(huì)慢慢地變大，幾十個(gè)GB甚至?xí)讉€(gè)TB，這時(shí)即使壓縮也會(huì)消耗掉大量的時(shí)間完成完全備份，這時(shí)建議使用并行備份——即將數(shù)據(jù)庫(kù)備份到多個(gè)物理驅(qū)動(dòng)器上，進(jìn)一步的話我們還可以使用Buffercount和Maxtransfersize進(jìn)行在備份過程中的性能優(yōu)化。 BUFFERCOUNT指定用于備份操作的 I/O 緩沖區(qū)總數(shù)。 可以指定任何正整數(shù);但是，較大的緩沖區(qū)數(shù)可能導(dǎo)致由于 Sqlservr.exe 進(jìn)程中的虛擬地址空間不足而發(fā)生“內(nèi)存不足(out of memory)”錯(cuò)誤。

緩沖區(qū)使用的總計(jì)空間由下面公式確定：buffercount*maxtransfersize，建議備份使用的緩沖區(qū)空間是物理內(nèi)存的1/16。當(dāng)執(zhí)行備份和恢復(fù)操作時(shí)可以使用Trace Flag 3213查看你的備份和恢復(fù)參數(shù)。

MAXTRANSFERSIZE是指定要在 SQL Server 和備份介質(zhì)之間使用的最大傳輸單元(字節(jié))。 可能的值是 65536 字節(jié) (64 KB) 的倍數(shù)，最多可到 4194304 字節(jié) (4 MB)。如果備份的緩沖取空間超出了1/16物理內(nèi)存的大小，建議調(diào)整Buffercount和Maxtransfersize的值達(dá)到要求。

描述和文件名(Description和Names)

適當(dāng)?shù)谋４鎮(zhèn)浞菸募此茖?duì)于很多人來講都不為重視，比如說應(yīng)該保留多長(zhǎng)時(shí)間周期的備份文件，一些人為了簡(jiǎn)單化，就保留了最近一份的備份，顯然，這也有可能在恢復(fù)時(shí)帶來災(zāi)難，原因是你的備份文件中的數(shù)據(jù)是正確的嗎?完全可以因?yàn)槟銈浞輹r(shí)驅(qū)動(dòng)器的問題導(dǎo)致數(shù)據(jù)失敗，如果避免這樣的情況發(fā)生，我們就可以通過保留多個(gè)數(shù)據(jù)庫(kù)備份，可以通過恢復(fù)頁(yè)來保證數(shù)據(jù)的安全有效。一般建議保留4個(gè)備份周期的文件。這又可能帶來一個(gè)問題，可能你的磁盤上堆積了大量的文件，如果沒有正確的命名，如果需要你在緊急情況下恢復(fù)數(shù)據(jù)庫(kù)你就有可能變得手忙腳亂(當(dāng)然，你可以查看各個(gè)日子文件的LSN來確認(rèn)恢復(fù)順序)，所以建議在備份時(shí)為備份添加適當(dāng)?shù)拿枋龊臀募秃苡袔椭?，比如說20130609_1330_SalesDB_Log.bak ，從名字一目了然就可以看出備份時(shí)間、哪一個(gè)數(shù)據(jù)庫(kù)和備份類型，同樣你也可以使用描述Description，通過添加適當(dāng)?shù)拿枋觯瑸閷?比如恢復(fù))時(shí)提供更多的有用信息。

加密

如若說你的數(shù)據(jù)庫(kù)備份丟失，也會(huì)帶來安全問題，考慮到之前某著名網(wǎng)站的用戶信息泄露事件，就是因?yàn)閭浞莸臄?shù)據(jù)庫(kù)文件丟失造成的，當(dāng)然，保存在一個(gè)安全的地方也是一個(gè)要考慮的問題，但是在現(xiàn)在的網(wǎng)絡(luò)環(huán)境下，還需要文件本身的安全，這就是對(duì)數(shù)據(jù)庫(kù)備份進(jìn)行加密，在SQL Server 2014之前對(duì)數(shù)據(jù)庫(kù)備份的加密一般通過對(duì)整個(gè)數(shù)據(jù)庫(kù)加密或者使用第三方備份加密工具，但是都有一定的問題存在(請(qǐng)參看：SQL Server 2014新特性-原生備份加密http://www.cnblogs.com/CareySon/p/3853016.html)，而SQL Server 2014引入的加密功能對(duì)數(shù)據(jù)安全提供了非常好的解決方案，主要是因?yàn)镾QL Server的備份加密基本不會(huì)增加備份文件的大小，并且在一般情況下，除了使用3DES算法的加密外，其他的AES算法加密對(duì)CPU也不會(huì)造成瓶頸問題。

校驗(yàn)和Checksum

這個(gè)選項(xiàng)有兩個(gè)作用：

1、從數(shù)據(jù)文件讀取數(shù)據(jù)頁(yè)時(shí)，用來驗(yàn)證他們的頁(yè)面校驗(yàn)和，如果發(fā)現(xiàn)無效的校驗(yàn)和現(xiàn)，默認(rèn)情況下備份將會(huì)失敗并產(chǎn)生一個(gè)具體頁(yè)面損壞的信息

2、計(jì)算整個(gè)備份文件的校驗(yàn)和并存儲(chǔ)在備份文件的頭部

注意隨著時(shí)間的推移頻繁的讀寫數(shù)據(jù)對(duì)于I/O子系統(tǒng)來講會(huì)比較容易的損壞磁盤上的數(shù)據(jù)文件和日志文件包括備份文件，這時(shí)雖然不會(huì)影響數(shù)據(jù)庫(kù)的訪問，但是當(dāng)你需要讀取損毀的頁(yè)面時(shí)，SQL Server會(huì)報(bào)告損害的信息;所以說對(duì)于一個(gè)合格的DBA來講，僅僅進(jìn)行簡(jiǎn)單的備份是不夠的，同時(shí)還要保證備份文件的完整性，頁(yè)面校驗(yàn)和是在數(shù)據(jù)頁(yè)從磁盤讀出再被寫入磁盤時(shí)進(jìn)行的檢查，對(duì)于SQL Server來講是用來確認(rèn)I/O子系統(tǒng)已經(jīng)損壞了一個(gè)數(shù)據(jù)頁(yè)的一種方法。

狀態(tài)Stats

這個(gè)選項(xiàng)可以使備份時(shí)顯示完成的進(jìn)度，默認(rèn)是每完成10%改變一下進(jìn)度顯示，你也可以使用Stats=X來指定，當(dāng)你對(duì)一個(gè)大的數(shù)據(jù)庫(kù)進(jìn)行手動(dòng)備份時(shí)這個(gè)選項(xiàng)就特別有用，可以提示你備份的進(jìn)度，同樣這個(gè)選項(xiàng)在恢復(fù)Restore數(shù)據(jù)庫(kù)時(shí)也同樣適用。

備份到URL

把SQL Server 備份到 URL實(shí)際上是將數(shù)據(jù)庫(kù)備份到Windows Azure Blob 存儲(chǔ)服務(wù)中。首先需要?jiǎng)?chuàng)建 Windows Azure 帳戶,這個(gè)功能自從SQL Server 2012 SP1 CU2 就開始支持，不過只能通過 Transact-SQL、PowerShell和 SMO實(shí)現(xiàn)此功能。在SQL Server 2014 中，最大的變化就是 SQL Server Management Studio 界面上開始支持備份到 Windows Azure Blob 存儲(chǔ)服務(wù)或從中還原。