如果你做DBA時間不長對數據庫的備份有些擔心希望能找到一種讓你放心的備份方案那麼本文絕對適合你
關於數據庫的備份恢復原理大家多少都比較熟悉了但是你目前做的數據庫備份有多可靠?你可以安心睡覺了嗎?如果答案是肯定的那就不用多花時間看下文了如果覺得還不夠安心總擔心數據庫哪一天壞了修不好那麼請接著看
我有RAID還需要做數據庫備份嗎?需要有了RAID萬一部份磁盤損壞可以修復數據庫有的情況下數據庫甚至可以繼續使用但是如果哪一天你的同事不小心刪除了一條重要的記錄怎麼辦?RAID是無能為力的你需要合適的備份策略把那條被誤刪的數據恢復出來所以有了RAID仍需要做備份集群磁盤鏡像同理
如果你只做全備份那麼受限於全備份的大小和備份時間不可能常做而且只有全備份不能將數據庫恢復至某個時間點所以我們需要全備份+日志備份比如每天一個全備份每隔小時或若干分鐘一個日志備份說到差異備份因為微軟的差異備份記錄的是上一次全備份以來發生的變化所以如果數據庫的改動很頻繁的話沒過多久差異備份就會和全備份的大小接近因此這種情況下就不合適了因此全備份+日志備份的方案適合絕大多數的用戶
如果你僅在數據庫本地做備份萬一磁盤損壞或者整個服務器硬件損壞備份也就沒了就沒法恢復數據庫因此你需要把備份文件傳送至另一個物理硬件上大多數用戶不用磁帶機因此不考慮一般我們需要另一台廉價的服務器或者PC來存放數據庫的備份來防止硬件損壞造成的備份丟失
你可以在數據庫服務器本地做完備份然後使用某些方式將備份文件傳送至備機你是在備份完成後就馬上穿送的嗎?其實可以考慮將傳送備份的腳本用TSQL語句來寫
備份文件傳送至備機後就可以高枕無憂了嗎?不作為DBA的你還需要檢查備機上的備份文件是否能將數據庫恢復至最新如果采用日志備份會不會因為丟失某一個日志備份文件而導致數據庫不能恢復至最新?如何檢查日志備份文件之間存在斷檔?
為了將數據庫盡可能的恢復到最新你可能會每隔分鐘(甚至分鐘)執行一次日志備份那麼萬一數據庫壞了在恢復的時候手動恢復成百上千個日志文件是不是不太現實?
如果你所在公司有很多的數據庫服務器(就像我所在的公司)而且磁盤空間有限那麼你不得不經常登錄服務器來刪除舊的備份文件如果哪天忘了或者五一十一長假磁盤空間用完了就麻煩了
數據庫在備份的時候並不會檢查數據頁面的完整性如果數據頁壞了備份作業仍會執行而且不會報錯等到你發現數據頁有錯誤的時候你也很可能已經因為磁盤空間不足而刪除了早期的備份而此時剩下的那些備份可能都是包含損壞的數據頁如果損壞的數據頁是某個表的表頭的話那這個表你就再也沒辦法恢復了
所以你需要定期執行DBCC檢查來盡早發現數據庫頁面的完整性在未作完DBCC檢查之前你不能刪除舊的備份以防止新的備份存在問題所以刪除備份文件的工作變的有些麻煩
你可能知道SQL Server提供了數據庫維護計劃沒錯使用它可以定期做備份執行DBCC檢查但這一切僅限於本機操作為了使數據庫可靠你還是需要自己把本地備份傳送至備機
綜上你的備份做好了嗎?檢查了嗎?刪除舊的備份是不是花去你很多時間特別是在網絡條件不好的時候?如果數據庫備份文件的傳送在某一時刻停止了你多久才能發現?公司值晚班的同事有權限檢查數據庫的備份情況嗎?
From:http://tw.wingwit.com/Article/program/SQL/201311/16320.html
