伺服器不同的故障導致資料丟失都怎麼解決的

北亞資料恢復發表於2019-09-26

伺服器資料恢復案例一、伺服器3塊硬碟離線資料恢復

本次進行資料恢復的是一組6塊750G磁碟的 RAID6,先後有兩塊磁碟離線,但維護人員在此情況下依然沒有更換磁碟,所以在第三塊硬碟離線後raid直接崩潰了。由此導致資料全部丟失。這臺伺服器是WEB伺服器,執行MYSQL資料庫,同時存放了大量其它檔案,管理員在資料丟失後便第一時間尋求資料恢復公司的幫助,但是經過某公司的操作後仍有近一個月的檔案損壞或丟失,MYSQL資料庫也嚴重損壞。後來經其它運維人員的介紹,這位管理員同志就聯絡到了我們。

瞭解了伺服器故障的基本情況以後,我們的工程師先將這6塊磁碟映象備份到我們的安全儲存池中,就不再對原儲存進行任何的操作,這樣就保障了客戶資料的原始性。透過對伺服器備份映象的分析,資料恢復工程師發現有兩塊磁碟離線時間很早,最新的資料已經不再寫入。此RAID6用的是雙校驗,第一個校驗是由普通的XOR運算生成,而第二個校驗是由Reed-Solomon演算法生成,相當複雜,運用了相當奇妙的數學原理。此RAID6有兩塊磁碟早已不寫入新資料,要想完整恢復資料就必須運用第二個校驗,否則會導致最新的資料丟失或損壞。目前市面上還沒有公開的資料恢復軟體能解決這個問題,雖然有部分軟體設有這一功能,但不過是擺設而已,實則無法使用。這也就是其他公司並沒能夠完整的恢復所有資料的根本原因所在。

伺服器資料恢復工程師分析出原始RAID的一些引數,然後使用了我們自己寫的完全RAID6恢復軟體,生成出一個完整映象,再將映象導回客戶用新磁碟搭好的儲存上,開機,一切正常,經過管理員的驗證,資料沒任何問題,本次伺服器資料恢復成功

伺服器資料恢復案例二、伺服器兩塊硬碟故障資料恢復成功

本次進行資料恢復的伺服器由4塊18GB的硬碟做成RAID 5磁碟陣列,其陣列卡是NetRaid;作業系統為Window 2000,資料庫是Server 2000。伺服器在正常工作時一塊硬碟紅燈閃亮,機器還在正常執行,但沒有多久,系統就不能正常執行,這時才發現另一塊硬碟的紅燈也在閃亮。

本次伺服器資料恢復的過程首先是由資料恢復國內工程師檢測伺服器。自檢至陣列時按Ctrl+M進入NetRaid管理程式。檢視陣列資訊,發現硬碟狀態為Failed,運用修改配置將一硬碟強行設定成OnLine。重新啟動伺服器,在進入系統前的硬體自檢時無效,啟動失敗。

資料恢復工程師再次啟動伺服器,自檢至陣列時按Ctrl+M進入NetRaid管理程式。選擇磁碟陣列,將原來OnLine掛起來的硬碟手工Fail掉,然後再把另一塊Failed的硬碟手工設定成OnLine,重新啟動伺服器就可以進入系統了。檢視系統及資料庫都執行正常後,再進陣列配置工具把Failed的硬碟手工設定成Rebuild,100%完成重建後再重啟伺服器,所有的陣列及系統都恢復原狀了,本次伺服器資料恢復成功。

伺服器資料恢復案例三、未知原因導致的伺服器崩潰資料恢復

本次資料恢復案例的背景是一臺裝有20塊硬碟的普通伺服器,由於未知原因上層業務突然崩潰,機房管理員對伺服器進行檢查發現導致伺服器崩潰的主要原因是伺服器上有3塊硬碟離線,管理員將伺服器內的所有硬碟按照現有盤序從槽位取出後攜帶硬碟來到北京某資料恢復中心進行伺服器資料恢復操作。

伺服器資料恢復工程師接到客戶的硬碟後使用資料恢復檢測裝置對20塊硬碟進行檢測,結果發現所有硬碟在資料恢復裝置下均可識別,這就避免了修復硬體的過程和由於硬碟物理損傷過於嚴重無法修復導致的伺服器資料恢復風險,是一件值得慶幸的事情,隨後對該伺服器內的所有硬碟進行映象,映象過程中發現原來伺服器中提示離線的3塊硬碟映象個過程十分緩慢,這也與之前硬碟離線的原因有一定的關係,多數原因是因為這三塊硬碟記憶體在大量的壞道或者不穩定扇區,所以在正常的伺服器環境下出現離線情況,在專業的資料恢復裝置中則可以識別,在映象過程中就會出現映象十分緩慢的情況,透過調整映象策略來調過硬碟的壞扇區來進行調整,直至所有硬碟都成功映象完成。

所有硬碟都成功映象以後,資料恢復工程師繼續使用伺服器資料恢復工具將所有的映象檔案展開進行底層資料分析,根據ext3檔案系統的逆向分析得到伺服器內硬碟的盤序和校驗資訊,分析過程這裡就不贅述了。最後利用這些分析出來的資訊進行重組raid陣列,透過和使用者溝通提取出了一些oracle的dmp檔案,在dmp恢復的過程中,資料庫報告為imp-0008錯誤,透過仔細分析匯入dmp檔案的日誌檔案,發現恢復的dmp檔案存在問題而導致dmp匯入資料失敗。立刻重新分析raid結構,以及進一步確定ext3檔案系統被破壞的程度,又經過數小時的工作,重新恢復dmp檔案和dbf原始庫檔案,將恢復出來的dmp檔案移交給使用者進行資料匯入測試,結果測試順利沒有發現問題,說明這次的資料恢復是成功的,接著對恢復出來的dbf原始庫檔案進行校驗檢測,所有檔案均能透過測試。

伺服器資料恢復工程師聯絡客戶進行資料恢復結果的驗證,經過客戶驗證所有資料均已經成功恢復,於是在伺服器上又搭建了一組新的raid陣列,由資料恢復工程師配合將所有恢復成功的伺服器資料遷移回客戶的伺服器上,本次伺服器資料恢復成功。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2658379/,如需轉載,請註明出處,否則將追究法律責任。

相關文章