對於一個數據庫完整備份來說，備份的速度很大程度上取決於下面兩個因素：讀磁盤數據、日志文件的吞吐量，寫磁盤數據文件的吞吐量。
下圖是備份過程中磁盤的變化情況：
讀吞吐量
讀吞吐量的大小取決於磁盤讀取數據的速度，而磁盤讀取的速度又取決於數據文件在磁盤中的位置。因此，位於不同盤符上不同數據庫文件的讀取速度都不相同。
測量讀吞吐量的一個方法就是進行一次數據庫完整備份，然後使用Windows性能監控器(perfmon)來監控數據庫文件所在磁盤的Read bytes/sec 性能計數器。保存備份文件的磁盤應該在物理上區別於數據庫文件所在的磁盤，否則測量精度會不准確。當然備份同時也應該會有另外一些來自系統或是其他應用程序對磁盤的讀取操作。
注意：如果你使用完整備份來監測磁盤讀寫吞吐量的話，那麼這個測試用的備份文件應該和其他常規備份放在一起，以便恢復時使用。也就是說，如果你在測試備份文件之後又進行了常規差異備份，那麼這些差異備份就會以這個測試備份為還原的起始點。
假設數據庫所有文件的大小都是相等的，那麼你獲取的最小測量值就是你指定數據庫在系統中最大的備份吞吐量了。
另一個測量讀吞吐量的方法是在NUL設備上執行備份，如下：
BACKUP DATABASE AdventureWorks TO DISK = 'NUL' WITH COPY_ONLY
注意我們使用了COPY_ONLY選項，這個選項僅僅在SQL Server 2005及以上版本中才提供。你可以在SQL Server2000上執行相同的備份，只是要忽略這個選項，但是一定要小心。因為備份到NUL設備也會被認為是一個有效備份，這就意味著當你執行備份到NUL設備後，你後續的所有差異備份都將不可用，除非你在執行備份到NUL設備後，再執行一次常規的數據庫完整備份。假如你執行事務日志備份到NUL設備，那麼你將破壞日志恢復鏈，導致後續事務日志備份不可用。
如果你必須在SQL Server 2000上執行備份到NUL設備的話，一定要做好備災恢復的准備。
假設我現在已經測量出我的AdventureWorks讀吞吐量為46MB/sec。這就是說，46MB/sec是最大的備份吞吐量了，也是我的磁盤能提供給SQL Server備份讀線程最快的速度了。那我們如何提高這個速度呢？使用更快的磁盤肯定是一種方法。另外的方法就是把數據庫文件分散到多個物理磁盤上，以便於在讀數據時可以同步創建多個讀線程。減小數據庫文件的碎片級別也可以提高吞吐量，特別是當數據庫文件有大量碎片存在時。
寫吞吐量
現在開始說說寫吞吐量。執行一個文件備份，在我的系統中，我得到了如下的結果：
BACKUP DATABASE successfully processed 7529 pages in 3.300 seconds (18.688 MB/sec).
上面的結果表明寫吞吐量在這裡成為了瓶頸。我的磁盤可以提供46MB/sec的數據，但是寫速度僅為18.688MB/sec。實際上，我把備份文件放在了同數據文件相同的磁盤上，當我把備份文件放在不同的物理磁盤上時，我得到如下的結果：
BACKUP DATABASE successfully processed 7529 pages in 1.421 seconds (43.399 MB/sec).
上面的結果已經好很多了。現在讀寫速度都取決於磁盤了，整體的吞吐量已經明顯提高了。所以把備份文件放到不同的物理磁盤上就是一種提高寫吞吐量的方法。另一個方法就是把備份分散成不同的文件。如果磁盤可以控制它的話，那麼文件可以位於相同的物理磁盤上。如果不能，你最好把文件分散到不同的物理磁盤上。使用更快的磁盤存儲備份文件是另一個好的選擇。
然而，讓我們回到第一步，再看看那個整體圖。想一想備份吞吐量的第一步是讀吞吐量。也就是說即使你的寫吞吐量達到150MB/sec，但是如果讀吞吐量只有46MB/sec的話，也無濟於事，你能獲得的最大備份吞吐量還是46MB/sec。
總結
首先我們總結一下我們都做了什麼：
我們測量了讀吞吐量為46MB/sec，我們討論了如下方法來提高這個數值：
使用更快的磁盤。
把多個數據庫文件存儲在不同的物理磁盤上
減少數據庫文件碎片級別
我們在數據庫文件所在磁盤執行了備份執行，備份吞吐務為18MB/sec。很糟的速度，我們知道讀吞吐量為46MB/sec，所以我們把目標放到了寫吞吐量上。然後，我們把備份文件放到了與數據庫文件不同的物理磁盤上。備份吞吐量為43MB/sec。速度不錯。我也還可以提高這一數值嗎？看起來好像是不行了。但是如果我們的寫吞吐量僅僅為25MB/sec的話，我們還可以從以下幾方面來考慮：
使用更快的磁盤進行備份
把備份文件分割成多個文件（在相同或不同的物理磁盤上，這取決於磁盤的吞吐量）
使用備份壓縮工具。假如壓縮速度非常好的話，那麼就會減少寫到磁盤上的數據量，從而加大寫吞吐量。一般情況執行這種壓縮程序都會消耗大量的CPU資源
補充說明
為了獲得最好的備份吞吐量，下面這幾點在最開始創建數據庫時就應該考慮到。實際上，下面這幾點也同樣適用於提高你數據庫的應用性能。
磁盤速度：使用最快的磁盤或是在預算允許的前提下進行磁盤配置來提高備份吞吐量。
數據庫文件：把數據庫文件分散到多個物理磁盤上，以便於SQL Server使用多個讀線程去每個磁盤上讀取數據。對比單數據文件的數據庫存儲來講，多數據文件可以在很短時間內完成數據的讀取。
使用不同的物理磁盤：SQL Server的讀線程數量是基於你數據庫文件所在的盤符數量的。然而，假如你的盤符是相同物理磁盤上的分區，而且你的磁盤不能滿足讀線程的讀取要求時，你的備份吞吐量將會很差。
文件碎片：創建數據時指定的數據庫的初始大小就相當於指定的數據庫減少文件碎片的期望最大值。假如數據庫文件被設置為自動增長，且設置了一個最大增長值的話，這樣也要有助於減小碎片。
有計劃的存儲你的事務日志到獨立的磁盤中：把你的事務日志文件存儲在獨立於數據庫文件的磁盤中，甚至獨立於操作系統或是其他經常使用I/O的應用程序，有助於在執行事務日志備份時提高讀寫吞吐量。事務日志的磁盤的I/O操作是自然相連的，而不是數據文件I/O那種隨機的操作。把事務日志文件同數據文件放在同一個盤上的話，當數據庫忙碌時，會使事務日志備份變慢。
有計劃的存儲你的備份到獨立的磁盤中：把你的備份文件存儲在獨立於數據庫文件的磁盤中，甚至獨立於操作系統或是其他經常使用I/O的應用程序，有助於提高寫吞吐量。
獲取備份速度數據
你可以從msdb..backupset表中獲取備份速度數據。backup_start_date,backup_finish_date和backup_size列提供了計算備份速度所需的所有數據細節信息。注意備份大小不是定義數據庫大小所必需的，因為SQL Server 2005不備份包括已被刪除數據的數據頁。具體細節請參見article。
下面的腳本可以顯示出你所有數據庫的備份時間：
SELECT database_name, backup_start_date, CAST(CAST((backup_size / (DATEDIFF(ss, backup_start_date, backup_finish_date))) / (1024 * 1024) AS NUMERIC(8, 3)) AS VARCHAR(16)) + ' MB/sec' speed
FROM msdb..backupset
ORDER BY database_name, backup_start_date
