概述

昨天下午突然看到，《爐石傳說》游戲資料庫發生宕機並引發數據丟失事故的新聞。剛看到時，滿滿的不可思議。暴雪啊，網易啊。

都是很牛叉的公司。他們出的游戲我都是很喜歡的。

 當我看到，第一時間著手搶修，重啟伺服器，並嘗試數據恢復時，我的想法是他們的高可用方案呢？為什麼不馬上切換？

當我看到相關備份資料庫也出現故障時，就更無語了。其實這樣的事情在我們的客戶每年都會遇到很多。前不久就有一個醫院， 資料庫和備份都同時損壞，而且沒有高可用的方案。

雖然最終幫他們修複了好資料庫，但還是丟失部分數據，而且中間1天時間，業務都是手動操作，嚴重影響業務。

分析

當遇到同樣的問題時，相關的運維和DBA都是很絕望的。總結下上面的問題：

1.缺乏高可用方案

2.制定更好的備份的策略

解決

下麵是之前給某外企制定過備份策略，可以解決上面提到的備份的問題。小伙伴們可以參考下：

備份的位置

1.本地的備份，放置於和資料庫文件不同的物理磁碟

2.異機備份。使用自動同步軟體實時把備份同步到專門的NAS

3.異地備份（可選）

備份方式

首先，恢復模式強烈建議使用完整模式。為了保證資料庫損壞時，能最快速度恢復業務。

1.每周全備  

2.每天差異

3.每半小時日誌

備份的頻率根據具體的業務情況可自行調整。

備份的選項

到目前為止我們的備份策略看上去很完美了。可事實是這樣的嗎？答案是否定的。

我們做好了看似完美的備份。但是如果我們的資料庫本身已經存在頁損壞，那麼我們的做再多備份也是徒勞。因為備份的文件也是損壞的。

那我們如何解決呢？最好的方法就是定期還原備份，然後立即運行DBCC CHECKDB。如果當時條件不允許持續還原和檢查，那麼使用RESTORE VERIFYONLY命令就是你另一個最好的選擇了。但是RESTORE VERIFYONLY並不是單獨使用的。它必須配合WITH CHECKSUM.意思就是，在BACKUP 的使用使用WITH CHECKSUM 參數，然後定期對備份的文件運行RESTORE VERIFYONLY 來驗證備份文件的有效性。如果資料庫中的某些頁面損壞，使用WITH 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.

設備 'd:\tttttt.bak' 上的介質簇的結構不正確。SQL Server 無法處理此介質簇。

總結

不好的備份策略，可能導致災難性的後果。 相反好的備份策略可以讓我們高枕無憂。看到這裡的小伙伴們趕緊去檢查下，自家的備份做好了嗎？否則請自習下麵武功秘籍：