概述
昨天下午突然看到，《爐石傳說》游戲數據庫發生宕機並引發數據丟失事故的新聞。剛看到時，滿滿的不可思議。暴雪啊，網易啊。
都是很牛叉的公司。他們出的游戲我都是很喜歡的。
當我看到，第一時間着手搶修，重啟服務器，並嘗試數據恢復時，我的想法是他們的高可用方案呢？為什么不馬上切換？
當我看到相關備份數據庫也出現故障時，就更無語了。其實這樣的事情在我們的客戶每年都會遇到很多。前不久就有一個醫院， 數據庫和備份都同時損壞，而且沒有高可用的方案。
雖然最終幫他們修復了好數據庫，但還是丟失部分數據，而且中間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 無法處理此介質簇。
報警
備份有可能因為各種原因而失敗，比如備份磁盤的空間滿了，等數據庫損壞的時候，突然發現備份任務失敗了，再完美備份策略 百搭。所以對備份任務，增加郵件報警機制，如果備份失敗了，可以第一時間知道並解決。
總結
不好的備份策略，可能導致災難性的后果。 相反好的備份策略可以讓我們高枕無憂。看到這里的小伙伴們趕緊去檢查下，自家的備份做好了嗎？否則請自習下面武功秘籍：
