很多數(shù)據(jù)恢復工程師包括一些數(shù)據(jù)恢復技術愛好者經(jīng)常會問同樣一個問題：“數(shù)據(jù)一旦被覆蓋了，還能不能恢復呀？我聽說國外能恢復被覆蓋以后的數(shù)據(jù)，據(jù)說只要是覆蓋操作在7次以內(nèi)，都能恢復出來，國內(nèi)有沒有這種技術呀？”這種問題困惑很多人，也困惑很多年，到現(xiàn)在也只是停留在傳說階段，沒有人能夠證實！市面上有一些數(shù)據(jù)擦除工具，在進行數(shù)據(jù)毀滅擦除的時候往往有一個選項：擦除1遍？擦除3遍？擦除7遍？我在懷疑是不是一種心理作用。在我目前認知的數(shù)據(jù)恢復技術領域，我堅決的認為：只要覆蓋一遍，數(shù)據(jù)就不可恢復！如果說能恢復，那已經(jīng)超出目前世界商業(yè)數(shù)據(jù)恢復技術領域，可能是個傳說吧。

本文的重點是要揭開數(shù)據(jù)覆蓋假象問題，并不討論數(shù)據(jù)被覆蓋以后的恢復技術。所謂的“數(shù)據(jù)覆蓋假象”，就是數(shù)據(jù)丟失或者被破壞以后，數(shù)據(jù)恢復工程師沒能恢復出用戶需要的文件，就主觀的認為數(shù)據(jù)“被”覆蓋了，其實丟失的數(shù)據(jù)“尸體”可能完整的躺在硬盤中，或者以支離破碎的“尸體”碎片散落在硬盤的多個位置上。真正的數(shù)據(jù)恢復高級技術，就是把數(shù)據(jù)“尸體”從硬盤中撈出來，運氣好的話，一個丟失的文件數(shù)據(jù)“尸體”連續(xù)存放在硬盤中，恢復就較為簡單。如果數(shù)據(jù)分成多段存放在硬盤中，數(shù)據(jù)恢復工程師就得把所有的數(shù)據(jù)段（數(shù)據(jù)碎片）撈出來，然后進行拼接，最終化腐朽為神奇，還原出丟失的數(shù)據(jù)完整的“尸體”，再進行文件內(nèi)容確認，數(shù)據(jù)恢復就基本結束。

我們以一個實際的數(shù)據(jù)恢復案例來講解：

實際環(huán)境：

在Windows 2003 Server操作系統(tǒng)下，采用NTFS分區(qū)類型，裝了一個MS SQL Server 2005數(shù)據(jù)庫，一共有10個數(shù)據(jù)庫在用，其中有一個數(shù)據(jù)名稱是xiangmu01，對應兩個物理文件xiangmu01.mdf和xiangmu01.ldf，這個數(shù)據(jù)庫使用有兩年多時間，xiangmu01.mdf大小有18GB，xiangmu01.ldf大小有30GB，存放路徑為d:\database\。

數(shù)據(jù)丟失過程：

某個粗心的工程師在使用服務器時，從MS SQL Server企業(yè)管理器中創(chuàng)建了一個新的數(shù)據(jù)庫，名稱為xiangmu001，創(chuàng)建時使用默認存儲路徑，默認路徑把數(shù)據(jù)庫xiangmu001的物理文件創(chuàng)建在了C盤的MS SQL Server安裝路徑上，他及時發(fā)現(xiàn)，想把數(shù)據(jù)xiangmu001刪除了，重新創(chuàng)建，把物理文件存放到d:\database\下，災難就在這一步降臨，錯誤的把xiangmu01數(shù)據(jù)庫刪除了，然后再創(chuàng)建xiangmu001數(shù)據(jù)庫，把物理文件路徑更改成d:\database\，企業(yè)管理器出現(xiàn)提示“該數(shù)據(jù)庫名稱已經(jīng)存在”，停下來檢查，腦袋嗡的一聲“刪錯了數(shù)據(jù)庫！”。

這個時候工程師想的第一件事就是找備份來還原！！！！于是在E盤中找到xiangmu01.bak文件，還記得核準時間，又一陣心慌意亂，這個備份是半年前的，檢查一下這個庫的備份腳本，早在半年前不起用了，不知道什么原因。于是又做了一個大膽的操作--“還原這個備份文件”。

他還原的步驟是，先創(chuàng)建xiangmu01數(shù)據(jù)庫，物理文件名稱和路徑跟原來數(shù)據(jù)庫一樣，于是在d:\database\下由于刪除xiangmu01數(shù)據(jù)庫丟失掉的兩個物理文件xiangmu01.mdf和xiangmu01.ldf，又出現(xiàn)在d:\database\目錄下，按照數(shù)據(jù)恢復行業(yè)詞匯就是“同名覆蓋”。創(chuàng)建好了新的xiangmu01數(shù)據(jù)庫，就用xiangmu01.bak來還原，禍不單行，這個xiangmu01.bak文件是壞的，還原不了。到了這里，瞞也瞞不住，上報領導，挽救數(shù)據(jù)！！

數(shù)據(jù)恢復是否有可能：

我們先不評價數(shù)據(jù)丟失過程怎樣的XXX，就這個案例而言，數(shù)據(jù)恢復成功的可能性到底有沒有？？根據(jù)不同的數(shù)據(jù)恢復公司，接到這樣的數(shù)據(jù)恢復案例，會有如下3種處理情況：

1、直接認為要恢復的數(shù)據(jù)發(fā)生了“同名覆蓋”，起碼數(shù)據(jù)庫文件頭部被破壞，不可恢復！

2、會按照數(shù)據(jù)庫mdf文件類型對整個分區(qū)進行掃描，提取出若干個mdf文件，挨個去驗證，看看有沒有好的，（這種恢復方式幾乎不能成功），最后宣告恢復失敗！

3、嘗試按照MS SQL Server數(shù)據(jù)庫頁面碎片對整個分區(qū)進行掃描，因為數(shù)據(jù)庫比較多，數(shù)據(jù)庫頁面碎片個數(shù)非常多，如果再加上對NTFS文件系統(tǒng)結構的熟悉了解，在掃描數(shù)據(jù)庫頁面碎片的時候，排除掉當前分區(qū)中正常存在的mdf文件的頁面信息，單獨提取硬盤分區(qū)NTFS文件系統(tǒng)中正常情況下不存放數(shù)據(jù)區(qū)域的數(shù)據(jù)庫頁面碎片，就是丟失掉的或者以前曾經(jīng)存放過的mdf文件內(nèi)容。通俗的講，就是該分區(qū)被認為空閑的、可用的那部分空間中，就是我們丟失的數(shù)據(jù)所在的地方。提取出被遺失的所有數(shù)據(jù)庫碎片頁面，然后按照一定規(guī)律來拼接，最終還原出刪除的mdf文件。

數(shù)據(jù)庫碎片頁面的概念：

數(shù)據(jù)庫文件在設計的時候都是按照一定的有規(guī)律的形式來存放的，數(shù)據(jù)庫文件內(nèi)部結構相當于一個小型的文件系統(tǒng)，我們了解NTFS文件系統(tǒng)，它有“簇”的概念，就是文件存放分配的最小單元。在數(shù)據(jù)庫文件里頭，有Page即“數(shù)據(jù)頁”的概念，就是數(shù)據(jù)庫文件結構按照一頁一頁存放，每一個頁面占用16sec或者32sec或者別的更大點的數(shù)，對于MS SQL Server來說，每一頁的大小有16sec，每個數(shù)據(jù)頁有自己的頁面編號等信息，每個頁面有自己的校驗方式等等，我們在提取數(shù)據(jù)庫頁面的時候，就根據(jù)這些規(guī)律來的。當把所有數(shù)據(jù)庫頁面碎片提取出來以后，怎樣把這些頁面拼接成一個文件，又是一門數(shù)據(jù)恢復藝術！

數(shù)據(jù)恢復結果：

本案例在達思數(shù)據(jù)恢復公司最終成功恢復，達思D-Recovery For MS SQL Server數(shù)據(jù)庫恢復軟件是在軟件研發(fā)人員耗費大量時間和精力出品的的國內(nèi)少有的MS SQL Server數(shù)據(jù)庫恢復軟件。在數(shù)據(jù)庫恢復技術領域，往往能化腐朽為神奇！

首先，它有數(shù)據(jù)庫碎片提取功能，有一定的碎片智能組合功能，如果某條組合線路出現(xiàn)分叉，可以人工查看，確定正確的組合線路，最終能把mdf文件相對完整的拼接出來。

其次，它可以直接讀取mdf文件內(nèi)容，如果有某些數(shù)據(jù)頁面被覆蓋或者被破壞，它可以繞過這些壞頁面，把mdf文件中正常的數(shù)據(jù)記錄提取出來，然后進行數(shù)據(jù)還原。在mdf文件局部損壞的情況下，MS SQL Server環(huán)境沒有辦法修復mdf文件，沒辦法讀取mdf文件中的數(shù)據(jù)，這時候D-Recovery For MS SQL Server就發(fā)揮它強大的數(shù)據(jù)庫內(nèi)容提取功能！

揭開數(shù)據(jù)覆蓋假象：

對本案例而言，出現(xiàn)了同名文件覆蓋的現(xiàn)象，大多數(shù)人都認為是數(shù)據(jù)被覆蓋了！在NTFS文件系統(tǒng)中，同名覆蓋，往往意味著原先文件MFT表項和后面覆蓋過來的文件的MFT表項是同一個，MFT表項ID號（如果有ID號）不會更改，更改的只是MFT表項內(nèi)部的數(shù)據(jù)指針！這樣通過任何數(shù)據(jù)恢復工具掃描，不會找出原始文件MFT內(nèi)部數(shù)據(jù)指針，找到的都是新覆蓋的文件的MFT表項信息。

數(shù)據(jù)區(qū)會不會也被新文件覆蓋呢？答案是不一定！Windows操作系統(tǒng)在分配新覆蓋過來的文件空間的時候，有可能會按照舊文件的指針分配，有可能分配新的數(shù)據(jù)空間，這就看Windows NTFS 文件系統(tǒng)文件空間分配機制了！如果說，新文件分配新空間，跟原始文件空間不發(fā)生重疊，那原始文件內(nèi)容將不會受影響！

為什么按照mdf文件類型來恢復，沒能找出正確的文件？數(shù)據(jù)庫文件xiangmu01.mdf已經(jīng)使用了兩年多，數(shù)據(jù)庫在創(chuàng)建的時候，數(shù)據(jù)庫文件根據(jù)需要分配空間，而不是一開始就分配很大的空間，所以在以后使用過程中，空間分配分散很嚴重，在硬盤上不可能連續(xù)存放！按照類型掃描恢復文件大都基于數(shù)據(jù)文件連續(xù)存放，否則恢復出來的文件只正確包含文件地一段數(shù)據(jù)信息！

小結：

數(shù)據(jù)覆蓋不是想當然，要經(jīng)過最底層的分析，才能得出正確的恢復方法！

本文首發(fā)于達思硬盤數(shù)據(jù)恢復公司，作者：達思總工覃廷良，轉(zhuǎn)載請注明出處http://www.bnuol.com

轉(zhuǎn)載于:https://blog.51cto.com/199818/665951

總結

以上是生活随笔為你收集整理的数据“被”覆盖有假象，SQL数据库恢复终极绝招（数据恢复高级技术）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。