SQL Server數(shù)據(jù)庫恢復(fù)案例分享
很多數(shù)據(jù)恢復(fù)工程師包括一些數(shù)據(jù)恢復(fù)技術(shù)愛好者經(jīng)常會問同樣一個問題：“數(shù)據(jù)一旦被覆蓋了，還能不能恢復(fù)呀?我聽說國外能恢復(fù)被覆蓋以后的數(shù)據(jù)，據(jù)說只要是覆蓋操作在7次以內(nèi)，都能恢復(fù)出來，國內(nèi)有沒有這種技術(shù)呀?”這種問題困惑很多人，也困惑很多年，到現(xiàn)在也只是停留在傳說階段，沒有人能夠證實!市面上有一些數(shù)據(jù)擦除工具，在進行數(shù)據(jù)毀滅擦除的時候往往有一個選項：擦除1遍?擦除3遍?擦除7遍?我在懷疑是不是一種心理作用。在我目前認(rèn)知的數(shù)據(jù)恢復(fù)技術(shù)領(lǐng)域，我堅決的認(rèn)為：只要覆蓋一遍，數(shù)據(jù)就不可恢復(fù)!如果說能恢復(fù)，那已經(jīng)超出目前世界商業(yè)數(shù)據(jù)恢復(fù)技術(shù)領(lǐng)域，可能是個傳說吧。
本文的重點是要揭開數(shù)據(jù)覆蓋假象問題，并不討論數(shù)據(jù)被覆蓋以后的恢復(fù)技術(shù)。所謂的“數(shù)據(jù)覆蓋假象”，就是數(shù)據(jù)丟失或者被破壞以后，數(shù)據(jù)恢復(fù)工程師沒能恢復(fù)出用戶需要的文件，就主觀的認(rèn)為數(shù)據(jù)“被”覆蓋了，其實丟失的數(shù)據(jù)“尸體”可能完整的躺在硬盤中，或者以支離破碎的“尸體”碎片散落在硬盤的多個位置上。真正的數(shù)據(jù)恢復(fù)高級技術(shù)，就是把數(shù)據(jù)“尸體”從硬盤中撈出來，運氣好的話，一個丟失的文件數(shù)據(jù)“尸體”連續(xù)存放在硬盤中，恢復(fù)就較為簡單。如果數(shù)據(jù)分成多段存放在硬盤中，數(shù)據(jù)恢復(fù)工程師就得把所有的數(shù)據(jù)段(數(shù)據(jù)碎片)撈出來，然后進行拼接，最終化腐朽為神奇，還原出丟失的數(shù)據(jù)完整的“尸體”，再進行文件內(nèi)容確認(rèn)，數(shù)據(jù)恢復(fù)就基本結(jié)束。
實際案例
我們以一個實際的數(shù)據(jù)恢復(fù)案例來講解。
實際環(huán)境：
在Windows 2003 Server操作系統(tǒng)下，采用NTFS分區(qū)類型，裝了一個MS SQL Server 2005數(shù)據(jù)庫，一共有10個數(shù)據(jù)庫在用，其中有一個數(shù)據(jù)名稱是xiangmu01，對應(yīng)兩個物理文件xiangmu01.mdf和 xiangmu01.ldf，這個數(shù)據(jù)庫使用有兩年多時間，xiangmu01.mdf大小有18GB，xiangmu01.ldf大小有30GB，存放路徑為d:\database\。
數(shù)據(jù)丟失過程：
某個粗心的工程師在使用服務(wù)器時，從MS SQL Server企業(yè)管理器中創(chuàng)建了一個新的數(shù)據(jù)庫，名稱為xiangmu001，創(chuàng)建時使用默認(rèn)存儲路徑，默認(rèn)路徑把數(shù)據(jù)庫xiangmu001的物理文件創(chuàng)建在了C盤的MS SQL Server安裝路徑上，他及時發(fā)現(xiàn)，想把數(shù)據(jù)xiangmu001刪除了，重新創(chuàng)建，把物理文件存放到d:\database\下，災(zāi)難就在這一步降臨，錯誤的把xiangmu01數(shù)據(jù)庫刪除了，然后再創(chuàng)建xiangmu001數(shù)據(jù)庫，把物理文件路徑更改成d:\database\，企業(yè)管理器出現(xiàn)提示“該數(shù)據(jù)庫名稱已經(jīng)存在”，停下來檢查，腦袋嗡的一聲“刪錯了數(shù)據(jù)庫!”。
這個時候工程師想的第一件事就是找備份來還原!!!!于是在E盤中找到xiangmu01.bak文件，還記得核準(zhǔn)時間，又一陣心慌意亂，這個備份是半年前的，檢查一下這個庫的備份腳本，早在半年前不起用了，不知道什么原因。于是又做了一個大膽的操作--“還原這個備份文件”。
他還原的步驟是，先創(chuàng)建xiangmu01數(shù)據(jù)庫，物理文件名稱和路徑跟原來數(shù)據(jù)庫一樣，于是在d:\database\下由于刪除xiangmu01數(shù)據(jù)庫丟失掉的兩個物理文件xiangmu01.mdf和 xiangmu01.ldf，又出現(xiàn)在d:\database\目錄下，按照數(shù)據(jù)恢復(fù)行業(yè)詞匯就是“同名覆蓋”。創(chuàng)建好了新的xiangmu01數(shù)據(jù)庫，就用xiangmu01.bak來還原，禍不單行，這個xiangmu01.bak文件是壞的，還原不了。到了這里，瞞也瞞不住，上報領(lǐng)導(dǎo)，挽救數(shù)據(jù)!!
數(shù)據(jù)恢復(fù)是否有可能?
我們先不評價數(shù)據(jù)丟失過程怎樣的XXX，就這個案例而言，數(shù)據(jù)恢復(fù)成功的可能性到底有沒有??根據(jù)不同的數(shù)據(jù)恢復(fù)公司，接到這樣的數(shù)據(jù)恢復(fù)案例，會有如下3種處理情況：
- 直接認(rèn)為要恢復(fù)的數(shù)據(jù)發(fā)生了“同名覆蓋”，起碼數(shù)據(jù)庫文件頭部被破壞，不可恢復(fù)!
- 會按照數(shù)據(jù)庫mdf文件類型對整個分區(qū)進行掃描，提取出若干個mdf文件，挨個去驗證，看看有沒有好的，(這種恢復(fù)方式幾乎不能成功)，最后宣告恢復(fù)失敗!
- 嘗試按照MS SQL Server數(shù)據(jù)庫頁面碎片對整個分區(qū)進行掃描，因為數(shù)據(jù)庫比較多，數(shù)據(jù)庫頁面碎片個數(shù)非常多，如果再加上對NTFS文件系統(tǒng)結(jié)構(gòu)的熟悉了解，在掃描數(shù)據(jù)庫頁面碎片的時候，排除掉當(dāng)前分區(qū)中正常存在的mdf文件的頁面信息，單獨提取硬盤分區(qū)NTFS文件系統(tǒng)中正常情況下不存放數(shù)據(jù)區(qū)域的數(shù)據(jù)庫頁面碎片，就是丟失掉的或者以前曾經(jīng)存放過的mdf文件內(nèi)容。通俗的講，就是該分區(qū)被認(rèn)為空閑的、可用的那部分空間中，就是我們丟失的數(shù)據(jù)所在的地方。提取出被遺失的所有數(shù)據(jù)庫碎片頁面，然后按照一定規(guī)律來拼接，最終還原出刪除的mdf文件。
數(shù)據(jù)庫碎片頁面的概念
數(shù)據(jù)庫文件在設(shè)計的時候都是按照一定的有規(guī)律的形式來存放的，數(shù)據(jù)庫文件內(nèi)部結(jié)構(gòu)相當(dāng)于一個小型的文件系統(tǒng)，我們了解NTFS文件系統(tǒng)，它有“簇”的概念，就是文件存放分配的最小單元。在數(shù)據(jù)庫文件里頭，有Page即“數(shù)據(jù)頁”的概念，就是數(shù)據(jù)庫文件結(jié)構(gòu)按照一頁一頁存放，每一個頁面占用16sec或者 32sec或者別的更大點的數(shù)，對于MS SQL Server來說，每一頁的大小有16sec，每個數(shù)據(jù)頁有自己的頁面編號等信息，每個頁面有自己的校驗方式等等，我們在提取數(shù)據(jù)庫頁面的時候，就根據(jù)這些規(guī)律來的。當(dāng)把所有數(shù)據(jù)庫頁面碎片提取出來以后，怎樣把這些頁面拼接成一個文件，又是一門數(shù)據(jù)恢復(fù)藝術(shù)!
數(shù)據(jù)恢復(fù)結(jié)果
本案例使用達思D-Recovery For MS SQL Server數(shù)據(jù)庫恢復(fù)軟件得以恢復(fù)，目前是國內(nèi)少有的基于MS SQL Server數(shù)據(jù)庫恢復(fù)軟件。首先，它有數(shù)據(jù)庫碎片提取功能，有一定的碎片智能組合功能，如果某條組合線路出現(xiàn)分叉，可以人工查看，確定正確的組合線路，最終能把mdf文件相對完整的拼接出來。
其次，它可以直接讀取mdf文件內(nèi)容，如果有某些數(shù)據(jù)頁面被覆蓋或者被破壞，它可以繞過這些壞頁面，把mdf文件中正常的數(shù)據(jù)記錄提取出來，然后進行數(shù)據(jù)還原。在mdf文件局部損壞的情況下，MS SQL Server環(huán)境沒有辦法修復(fù)mdf文件，沒辦法讀取mdf文件中的數(shù)據(jù)，這時候D-Recovery For MS SQL Server就發(fā)揮它強大的數(shù)據(jù)庫內(nèi)容提取功能!
揭開數(shù)據(jù)覆蓋假象
對本案例而言，出現(xiàn)了同名文件覆蓋的現(xiàn)象，大多數(shù)人都認(rèn)為是數(shù)據(jù)被覆蓋了!在NTFS文件系統(tǒng)中，同名覆蓋，往往意味著原先文件MFT表項和后面覆蓋過來的文件的 MFT表項是同一個，MFT表項ID號(如果有ID號)不會更改，更改的只是MFT表項內(nèi)部的數(shù)據(jù)指針!這樣通過任何數(shù)據(jù)恢復(fù)工具掃描，不會找出原始文件 MFT內(nèi)部數(shù)據(jù)指針，找到的都是新覆蓋的文件的MFT表項信息。
數(shù)據(jù)區(qū)會不會也被新文件覆蓋呢?答案是不一定!Windows操作系統(tǒng)在分配新覆蓋過來的文件空間的時候，有可能會按照舊文件的指針分配，有可能分配新的數(shù)據(jù)空間，這就看Windows NTFS 文件系統(tǒng)文件空間分配機制了!如果說，新文件分配新空間，跟原始文件空間不發(fā)生重疊，那原始文件內(nèi)容將不會受影響!
為什么按照mdf文件類型來恢復(fù)，沒能找出正確的文件?數(shù)據(jù)庫文件xiangmu01.mdf已經(jīng)使用了兩年多，數(shù)據(jù)庫在創(chuàng)建的時候，數(shù)據(jù)庫文件根據(jù)需要分配空間，而不是一開始就分配很大的空間，所以在以后使用過程中，空間分配分散很嚴(yán)重，在硬盤上不可能連續(xù)存放!按照類型掃描恢復(fù)文件大都基于數(shù)據(jù)文件連續(xù)存放，否則恢復(fù)出來的文件只正確包含文件地一段數(shù)據(jù)信息!
數(shù)據(jù)覆蓋不是想當(dāng)然，要經(jīng)過最底層的分析，才能得出正確的恢復(fù)方法。
原文鏈接：http://www.cnblogs.com/qintl/archive/2011/09/16/2178296.html
【編輯推薦】
