讓我們回首上半年IT領域數據相關的幾個事件，對數據備份的重要性重新加深一下認識：

2017年1月 MongoDB黑客贖金事件，發現了一些在互聯網上用戶的MongoDB沒有任何的保護措施，被攻擊者把數據庫刪除了，並留下了一個叫 WARNING 的數據庫。“老子把你的MongoDB裏的數據庫給轉走了，如果你要你的數據的話，給我0.2個的比特幣（大約USD200）。”

2017年2月 GitLab一名疲憊不堪的系統管理員在荷蘭工作到深夜，他在令人沮喪的數據庫復制過程中不小心刪除了一臺不該刪除的服務器上的目錄：他徹底刪除了一個含有300GB活動生產數據的文件夾。更為悲劇的是定時備份和雲端的備份都無效。

2017年4月 雲托管服務提供商Digital Ocean重蹈GitLab在2個月前的覆轍：因粗心大意而出亂子，刪除了一個生產級數據庫，結果引發了持續五個小時的故障。

2017年6月 位於荷蘭海牙的一家雲主機商 verelox.com，一名前任管理員刪光了該公司所有客戶的數據，並且擦除了大多數服務器上面的內容，客戶數據恢復希望渺茫。

對於這些頻繁發生的事件，讓我們更為深刻的認識到了DBA 守則的第一條：有效的備份重於一切。

深感急迫需要改進和完善備份工作，DBA對於備份做如下優化：

1.備份刪除優化
以前的刪除是根據時間一刀切，刪除30天前的所有文件。
現在，根據SQL Server備份恢復的原理，數據庫還原要基於完備，我們將刪除策略調整為刪除30天前最近的一次完備之前的所有文件。

2.備份連續性驗證
讀取當前時間之前最近的一次完備及之後的所有日誌備份，判斷LSN的連續性。

3.備份可用性驗證
輪訓近一天的所有備份文件，RESTORE VERIFYONLY驗證備份文件的可用性。

4.備份恢復驗證
考慮到資源不足，將一次驗證一個庫，數據庫按隊列驗證，讀取當前時間之前最近的一次完備及之後的所有日誌備份，做備份恢復操作。

恢復驗證的數據遠程UNC路徑掛載在遠端，驗證完一個庫後，立即清理，避免空間占用。

5.備份歷史和作業歷史自動清理
可配置不同粒度定期清理存儲在msdb裏的備份歷史和作業歷史數據，減少msdb的IO瓶頸。

基於以上5點，打造完整的數據備份體系，為數據的有效使用保駕護航。

本文出自 “SQL Server Deep Dive” 博客，請務必保留此出處http://ultrasql.blog.51cto.com/9591438/1948417

SQL Server 打造完整的數據備份體系