你遇到的最糟糕的事莫過於備份文件無法還原數據庫了。我這裡並不是說缺少磁盤空間或者類似的事導致的無法還原，而是一個100%確認已經被損壞的備份文件。你會問，那我怎麼辦呢？別著急，SQL Server有一個完善的還原功能來驗證備份文件。
舉個例子，當你第一次創建了一個備份文件，它應該是好的，但這僅僅是“應該”。每一次，這個文件被拷貝到另一個地方時，文件就會存在被損壞的風險。確認這個備份文件可以繼續使用的最好的方法就是還原它，然後立即運行DBCC CHECKDB。如果當時條件不允許持續還原和檢查，那麼使用RESTORE VERIFYONLY命令就是你另一個最好的選擇了。
不幸的是，這裡面有個小問題。在SQL Server 2000裡，在RESTORE VERIFYONLY會話期間，會發生下面這種情況：
現在，假如你使用一個16進制的編輯器(比如UE)，任意修改備份文件中存儲的數據，然後再次運行RESTORE VERIFYONLY，SQL Server仍然會告訴你“備份設備有效(The backup set is valid)”。
在SQL Server 2000裡，RESTORE VERIFYONLY僅僅檢查文件是否符合Microsoft Tape Format (MTF)規范，是否可以從磁盤讀取數據。所以你的備份數據可能含有垃圾數據。
現在在SQL Server 2005裡面，缺省的備份設置和2000一樣。也就是說，假如你的備份文件在數據備份區域有垃圾數據的話，SQL Server 2005依然會報告：備份設置有效。
那我們應該如何應對呢？答案就是使用備份時使用CHECKSUM選項，例如：
BACKUP DATABASE AdventureWorks TO DISK = 'G:\backups\AdventureWorks_full.bak' WITH CHECKSUM
現在，假如你更改文件數據備份區域的一個字節，然後在那個文件上運行RESTORE VERIFYONLY的話，會產生如下提示：
Server: Msg 3189, Level 16, State 1, Line 1
Damage to the backup set was detected.
Server: Msg 3013, Level 16, State 1, Line 1
VERIFY DATABASE is terminating abnormally.
下圖顯示了運行過程：
RESTORE VERIFYONLY終於按照我們期望的方式工作了。在備份期間使用CHECKSUM選項會引起SQL Server執行如下操作：
為備份數據計算校驗和。這個校驗和可來與RESTORE VERIFYONLY過程中產生的校驗和進行對比。
校驗頁的校驗和。如果校驗失敗，備份就會被中止。這也是一個好辦法，用於確認你從一開始，就正在備份一個“良好”狀態的數據庫。
那麼，使用CHECKSUM會給你帶來什麼負面影響呢？
備份和還原時，會占用大量處理器時間
增加備份和還原時間
總之，在SQL Server 2000和2005中，使用默認備份設置的話，RESTORE VERIFYONLY不能檢查出來備份文件的數據是否已經被破壞。僅僅在SQL Server 2005中當創建備份時使用了CHECKSUM選項的話，才能驗證備份數據的完整性。
但是也許你們部門預算有限，並沒有另外購買SQL Server 2005的license，怎麼辦呢？當然我們可以使用SQL Server 2005的Express版本。雖然SQL Server 2005Express是免費的，但是它僅僅支持4GB以下的數據庫。不過很少有人知道，當使用RESTORE VERIFYONLY命令時，Express版本可以工作在大於4GB的文件上。沒問題，你可以在你的備份文件服務器上安裝Express，然後盡情的驗證你的備份文件是否有效。
