一次客戶資料庫恢復的過程

前一段時間給一個客戶恢復了一個資料庫。

事情其實已經過去一段時間了，而且整個過程無非是一個資料庫的基於時間的不完全恢復，從技術角度講，沒有什麼太多可以值得描述的，而且由於所有的操作都是在客戶的主機上進行，因此沒有留下任何的痕跡，因此這件事情很難寫成一篇技術相關的文章，所以也就一直沒有寫出來。

今天打算簡單描述一下這個問題，主要是受Eygle的影響，Eygle最近剛剛寫完一本新書《資料安全警示錄》，我在幫他進行一些文字上的檢查工作。在這本書中，Eygle用他幫別人恢復資料庫的案例來警示大家，希望大家能利用別人的失敗教訓來警醒我們自己。

雖然我的這個案例在技術上並沒有太多值得描述的，但是這個案例本身卻很有借鑑意義，在這裡和大家分享一下。

我們接到客戶的請求是週五的下午，據說客戶的資料庫在週四夜裡DOWN機，隨後負責維護的人員對資料庫進行了恢復，但是資料庫丟失了部分資料，客戶對於恢復的程度不認可，於是找到了我們。

開始以為只是由於不完全恢復的RESETLOGS導致了少量的資料丟失，可能需要透過類似LOGMINER的方法來看看能否多恢復一些資料，但是到了現場進行了簡單的溝通後，發現我們之前得到的資訊非常的不準確。

客戶的資料庫在週四夜裡11點左右DOWN機，隨後負責維護的人員對資料庫進行了恢復，但是資料庫最終只恢復到了週四上午10點左右，客戶對於這種程度的恢復當然是不認可的，以致於最終對於現場負責維護的技術人員的不信任，最終找到了我們。

而對於現場環境的檢查後，發現了很多的問題。

資料庫DOWN機的原因是由於當前日誌損壞，由於資料庫的日誌每組只有一個，這個當前日誌的損壞不但導致資料庫的DOWN機，而且會造成資料的丟失。但是損失僅此而已，只是當前日誌中少部分已經COMMIT但是還沒有寫到資料檔案的資料。對於這種情況，最差的情況是丟失一個小時的資料，也就是說到上一個日誌切換時刻資料都是正常的。而對於當前日誌丟失的情況，完全沒有必要也沒有理由去執行全庫的恢復，只要清除當前損壞的日誌就可以開啟資料庫。執行全庫的恢復說明維護人員根本不理解Oracle的備份恢復機制，只是發現資料庫無法正常開啟，就去盲目的還原並恢復資料庫，導致更多的問題產生。

維護人員水平不高，因此備份策略的不嚴謹以及備份和恢復過程的混亂也是意料之內的事情。首先，Oracle的備份策略存在比較嚴重的問題，客戶的環境中有儲存備份的帶庫，這對於資料庫備份而言，應該是更安全的保障，但是備份策略的設定不但沒有提高備份的安全性，反而使得備份的可用性下降。

客戶的資料庫每週執行一次全庫備份，每天進行一次增量的備份，此外每天要進行多次的歸檔日誌的備份。除了全庫備份一定儲存在帶庫上之外，增量備份和歸檔日誌的備份有可能儲存在帶庫上，也有可能儲存在磁碟上，且沒有任何一個位置上的備份是齊備的。以這次的問題為例，進行資料庫的恢復首先需要恢復4天前帶庫上的全備，然後需要應用3天前帶庫上的增量，2天前磁碟上的增量，1天前帶庫上的增量，以及帶庫和本地磁碟上最近一天的歸檔備份。這種備份策略導致的一個問題就是，如果磁碟或帶庫任意出現一點損壞，就會導致資料庫無法完全恢復。帶庫裝置本來可以增加備份的可靠性，但是這種備份策略的設定使得備份的安全性和可靠性被降到最低。此外這種備份的儲存和恢復也會給備份恢復的效能帶來很大的影響。

除了備份策略的問題之外，操作過程也存在非常嚴重的問題。其中一點就是，資料庫恢復過程的RMAN輸出日誌被刪除。由於缺少當時恢復過程的日誌，無法確定維護人員當時具體執行的操作是什麼，所有的資訊只能來自當事人的口述，本來口述這個方式就不靠譜，何況還是一個概念本身就不很清晰的人，而且問題產生的後果已經比較嚴重，很難說他在描述的過程中是否為自己開脫。總之，按照當事人的描述，恢復步驟應該是沒有問題的，但是恢復後資料庫中的資料只到早上10點左右，缺少了最後一天12個小時的資料。

最後維護人員還犯了一個更加嚴重的錯誤，第一次在進行資料庫恢復的過程中，有一些帶庫上的歸檔日誌檔案被恢復到本地磁碟上。在資料庫恢復完成後，出於空間的考慮，所有硬碟上恢復出來的歸檔日誌被刪除。但是由於刪除的時候沒有進行限定，刪除操作刪除了資料庫硬碟上所有的歸檔，不僅包括恢復過程中從帶庫恢復到硬碟上的，還包括最新的幾個還沒有進行過備份的歸檔檔案。這個刪除的操作最終導致了資料庫再次進行恢復時，丟失了最後兩個小時的資料。

可以看到，原本一個只是損失幾分鐘資料，造成半個小時左右停機時間的故障，由於維護人員的錯誤，導致問題一步步放大，最終造成了損失2個小時左右的資料，且資料庫停機一天半以上的重大事故。