歡迎您光臨本站 註冊首頁

高難度數據恢復案例:Linux Ext3文件系統誤刪除

←手機掃碼閱讀     火星人 @ 2014-03-12 , reply:0
  

為了更好的確保數據安全,企業級數據一般都存儲在安全性及穩定性更高的Linux及Unix內核系統的存儲設備上。據統計,企業級數據恢復案例較多的集中在Windows內核的伺服器。不過,Windows內核的數據恢復技術難度不大,而Linux及Unix出故障的概率比較小,但是一旦出現問題,數據恢復難度非常大,經過多年的艱苦研究,終於在Unix(IBM AIX,HP-Unix)及Linux系統下的各種文件系統(如:EXT3、JFS2、ReiserFS等)的數據恢復取得了突破性進展。

下面,我們看一個比較典型的Ext3文件系統誤刪除的成功案例。

客戶:日本某全球500強公司

伺服器環境:浪潮伺服器,3塊硬碟做的Raid5。

文件系統:EXT3

發生故障時間:2010年3月18 上午10點左右

工程師誤操作:維護工程師停掉Oracle服務,打算把Oracle做一個冷備份,然後把Oracle庫文件備份到windows PC Server上,再用CuteFTP的客戶端下載。在下載過程中,發現下載速度特別慢,想刪除下載任務,結果誤操作,把要下載的Oracle實例文件夾整個都刪除了,Oracle庫文件、控制文件、日誌文件全部刪除。

數據恢復:EXT3文件系統誤刪除數據恢復技術介紹

實際上,Linux操作系統的EXT3文件系統並沒有預留反刪除的功能。在EXT3文件系統中,每個文件都是通過Inode來描述其數據存放的具體位置,當文件被刪除以後,Inode的數據指針部分被清零,文件目錄區沒有太多變化。文件的讀寫都是通過Inode來實現,當Inode數據指針被清零以後,即便文件內容還在,也沒有辦法把文件內容組合出來。

EXT3文件系統是一種帶日誌功能的文件系統,Inode的變化會在日誌文件.journal中有記錄,.journal文件比較小,一般是32MB。當EXT3文件系統中的metadata數據發生變化時,相應的metadata在.journal文件會有一份COPY。比如一個文件被刪除了,它的Inode信息會在.journal文件中先保存一份,然後把要刪除文件Inode相關信息清零。這個.journal文件是循環使用的,當操作過多時,刪除的文件的Inode日誌記錄會被新的數據替換,這就徹底喪失了根據Inode找回數據的機會了。如果是大量文件的刪除,這個.journal文件會被反覆循環利用多次,只留給最後刪除的那些文件的恢復機會。

數據恢復專家上門服務 3天Oracle資料庫奇迹般成功恢復!

客戶在北京諮詢了五六家數據恢復公司,最終決定請數據恢復專家上門服務。數據修復專家開車抵達位於順義區天竺的客戶數據中心現場。

客戶要恢復的是Oracle資料庫,Oracle資料庫文件被刪除以後,只要是數據內容沒有被覆蓋,數據恢復技術是可以把文件單獨提取出來。DST專家經過深入分析,在.journal文件沒有找到刪除過的Oracle數據文件,原因是用戶刪除數據以後,系統還在開機運行,同時嘗試啟動過Oracle實例,Oracle產生一些日誌文件,這些日誌文件數量比較多,而要恢復的刪除過的文件數量只有16個,在.journal文件中已經沒有了刪除文件的Inode信息。最終,數據恢復的思路只有兩條:

第一種:根據Oracle數據文件內部結構,對全盤進行搜索,符合Oracle數據頁面的數據都提取出來,然後按照Oracle數據文件的ID號進行重新組合。

第二種:根據Oracle數據文件分佈規律,精確定位Oracle文件的數據指針地址,包括一級間接地址、二級間接地址和三級間接地址,重新構造出該文件的Inode信息,然後把數據讀取出來。

最終恢復的效果非常好。第二天下午,由於工作量比較大,現場編寫了腳本,以提高Oracle資料庫組合進度。第三天,Oracle能正常啟動。工程師把數據全部備份出來,最後發現有兩個表數據少了一些記錄,經查明,原因就是刪除文件以後,一些日誌文件的寫入該分區,破壞了Oracle數據文件的一些數據頁面,幸好這兩張表數據對用戶來說不是很重要,客戶接受數據恢復結果。

專家提示:

在LINUX/UINX下誤刪除了文件,當發現數據丟失以後,不要進行任何操作,馬上關機,保留現場。如果條件不允許關機,就要想辦法把數據丟失的文件系統經過DD鏡像到另外的存儲空間上作為最原始的備份,以便數據恢復專家現場診斷。



[火星人 ] 高難度數據恢復案例:Linux Ext3文件系統誤刪除已經有385次圍觀

http://coctec.com/docs/enterprise/show-post-73116.html