王東所在的社?；鹬行氖褂玫氖悄硣H品牌的集群服務器，運行Microsoft SQL 2005，連接到大約有3TB可用空間的存儲陣列上，構成雙機熱備方案。該社?；鹬行牡臄祿彀ù蠹s1.5TB的數據和圖像文件，而且以每年300-500MB的數據量遞增。
社?；鹬行牡臄祿熘饕４娴挠杉堎|文件掃描得來的數字圖像文件。因為圖像文件對于磁盤空間的要求很高，所以數據庫中圖像文件的部分包括一個分割成文件組的分區表，以年為單位在文件組中作為一個單獨的分區來保存相應的文件。
當年的數據是一個讀/寫文件組，而一旦關閉，就標記成只讀。然后整個數據庫使用文件組（部分的）備份，接著備份事務日志。這些數據庫備份文件再備份到磁帶上，并妥善保管在各處。分區表是SQL 2005的新功能，可以讓備份大型數據庫的操作變得更加簡便。因為在只讀文件組里的數據不會改變，就不需要像讀/寫文件組里的信息那樣經常性地做備份了。
然而，這種靈活性增加了文件管理的復雜度。當新的讀/寫文件組加入數據庫中時，這個文件組必須在同一時間作為另一個文件組進行備份，同時還要備份事務日志，這樣才能完全恢復數據庫并上線使用。
問題的根源
去年六月，一個磁盤陣列處理器報錯了，王東給硬件的廠商打了一個電話，得到的建議是運行后臺校驗來修復RAID數據，這個建議非常合理，但是實際操作中卻并沒有奏效。
要修復RAID數據，首先必須先解除LUN綁定，然后重新綁定兩個損壞的LUNs。因此，王東必須把損壞的LUNs上存儲的數據庫文件組移動到另外一個準備好的LUN上。這個步驟是修復RAID數據必不可少的步驟，然而無法挽回的損失也正是發生在這個步驟。
王東通過一臺遠程計算機上進行解除和重新綁定的操作，與此同時還有一個廠商工程師在幫助做相同的操作，在實際操作中，由于以前備份策略的設置的文檔已經完全丟失，無論是王東還是廠商工程師都很難把LUN編號和服務器驅動器編號對應起來，而且有些文件被錯誤的挪到了要重新綁定的LUNs上。兩個人最終勉強完成了重新綁定的工作，他們卻發現有一個重新綁定的LUN里面錯誤的包含了數據文件和SQL備份文件。
王東試圖從磁帶上恢復數據庫的備份文件，有一個重要的文件，對于社?；鹬行牡臄祿靵碚f最主要的文件組（MDF），在正常的備份過程中被不經意地忽視了，這個文件就沒有備份到磁帶上。而如果沒有這個文件，數據庫就不能恢復并正常工作。這個時候王東才意識到，要想從備份磁帶中把數據恢復完成，已經徹底不可能了。而他們平時所依賴的數據備份系統，在真正的問題來臨的時候，并不能保護數據安全。
王東在周末加班，使用以前手工備份的MDF文件把所有只讀的歷史文件都恢復了，也就是2000年至2005年的數據，但是2006年的所有數據卻永遠丟失了，因為即使有2006年當前的備份和事務日志的備份，相對應的MDF文件的備份也是需要的。為了盡快恢復業務，系統先調用了一個沒有數據的2006年的文件組。2006年夏天，王東和他的同事們用了三個半月的時間把紙質文檔重新進行了掃描。
全新的備份架構
這次意外的災難給社保中心帶來不小的損失，社保中心也因此開始重視數據保護方面的投入和評估，并重新審視了以往的備份架構。
以前，王東他們是文件組和日志每天都做備份，完全備份（包括所有的文件組）則是一個季度做一次。
現在，王東和他的同事對于如何從文件組備份成功恢復數據庫有何要求已經相當清楚了，其中有一些是MS SQL 2005的新功能?，F在，王東增加了額外的磁盤到陣列中，保證有7TB的可用空間，恢復數據庫和執行常規檢查的操作變得更加容易了，同時備份方案也變得更加完善和成熟。
現在該社?；鹬行陌才帕艘唤MIT人員每天都會檢查和驗證備份日志，每月都會檢查所有的數據庫性能、備份程序和腳本。循環備份的文件也會得到檢查，而且每一個預定的備份現在要三個人檢查才算完成。該社?；鹬行倪€執行端到端的備份，并每季度保存一次，保證整個數據庫可以通過磁帶上保存的每季度的完全備份得到恢復。
該社?；鹬行牡氖鹿蕩Ыo我們的經驗就是一定要保證備份/恢復的過程是有效的。沒有實時記錄一個重要的地址文件是該社?；鹬行膫浞莼謴褪〉年P鍵，這樣的人為錯誤而造成的數據損失比我們想象的更為普遍，雖然一般并沒有這么大的損失量。
在意外刪除之后，人們使用備份、快照或其他方式來恢復數據的過程，就叫做數據恢復。然后我們通常就會發現備份、快照或檔案文件不起作用的情況，這就是向Ontrack這類恢復服務提供商尋求幫助的時候了，看看他們能不能幫你從服務器或者存儲陣列中恢復你想要的數據。
此外，整個故事還包括一個隱藏的信息：如果只依賴于RAID鏡像，本地或遠程復制/鏡像，如果在一個地點有什么文件被刪除了，另一個地方的也同樣會被刪除。所以如果你只依賴于復制和鏡像，那么至少要使用常規快照作為補充，另外，盡快把這些快照備份到別的介質上去。
