很多数据恢复工程师包括一些数据恢复技术爱好者经常会问同样一个问题：“数据一旦被覆盖了，还能不能恢复呀?我听说国外能恢复被覆盖以后的数据，据说只要是覆盖操作在7次以内，都能恢复出来，国内有没有这种技术呀?”这种问题困惑很多人，也困惑很多年，到现在也只是停留在传说阶段，没有人能够证实!市面上有一些数据擦除工具，在进行数据毁灭擦除的时候往往有一个选项：擦除1遍?擦除3遍?擦除7遍?我在怀疑是不是一种心理作用。在我目前认知的数据恢复技术领域，我坚决的认为：只要覆盖一遍，数据就不可恢复!如果说能恢复，那已经超出目前世界商业数据恢复技术领域，可能是个传说吧。

本文的重点是要揭开数据覆盖假象问题，并不讨论数据被覆盖以后的恢复技术。所谓的“数据覆盖假象”，就是数据丢失或者被破坏以后，数据恢复工程师没能恢复出用户需要的文件，就主观的认为数据“被”覆盖了，其实丢失的数据“尸体”可能完整的躺在硬盘中，或者以支离破碎的“尸体”碎片散落在硬盘的多个位置上。真正的数据恢复高级技术，就是把数据“尸体”从硬盘中捞出来，运气好的话，一个丢失的文件数据“尸体”连续存放在硬盘中，恢复就较为简单。如果数据分成多段存放在硬盘中，数据恢复工程师就得把所有的数据段(数据碎片)捞出来，然后进行拼接，最终化腐朽为神奇，还原出丢失的数据完整的“尸体”，再进行文件内容确认，数据恢复就基本结束。

实际案例

我们以一个实际的数据恢复案例来讲解。

实际环境：

在Windows 2003 Server操作系统下，采用NTFS分区类型，装了一个MS SQL Server 2005数据库，一共有10个数据库在用，其中有一个数据名称是xiangmu01，对应两个物理文件xiangmu01.mdf和 xiangmu01.ldf，这个数据库使用有两年多时间，xiangmu01.mdf大小有18GB，xiangmu01.ldf大小有30GB，存放路径为d:\database\。

数据丢失过程：

某个粗心的工程师在使用服务器时，从MS SQL Server企业管理器中创建了一个新的数据库，名称为xiangmu001，创建时使用默认存储路径，默认路径把数据库xiangmu001的物理文件创建在了C盘的MS SQL Server安装路径上，他及时发现，想把数据xiangmu001删除了，重新创建，把物理文件存放到d:\database\下，灾难就在这一步降临，错误的把xiangmu01数据库删除了，然后再创建xiangmu001数据库，把物理文件路径更改成d:\database\，企业管理器出现提示“该数据库名称已经存在”，停下来检查，脑袋嗡的一声“删错了数据库!”。

这个时候工程师想的第一件事就是找备份来还原!!!!于是在E盘中找到xiangmu01.bak文件，还记得核准时间，又一阵心慌意乱，这个备份是半年前的，检查一下这个库的备份脚本，早在半年前不起用了，不知道什么原因。于是又做了一个大胆的操作--“还原这个备份文件”。

他还原的步骤是，先创建xiangmu01数据库，物理文件名称和路径跟原来数据库一样，于是在d:\database\下由于删除xiangmu01数据库丢失掉的两个物理文件xiangmu01.mdf和 xiangmu01.ldf，又出现在d:\database\目录下，按照数据恢复行业词汇就是“同名覆盖”。创建好了新的xiangmu01数据库，就用xiangmu01.bak来还原，祸不单行，这个xiangmu01.bak文件是坏的，还原不了。到了这里，瞒也瞒不住，上报领导，挽救数据!!

数据恢复是否有可能?

我们先不评价数据丢失过程怎样的XXX，就这个案例而言，数据恢复成功的可能性到底有没有??根据不同的数据恢复公司，接到这样的数据恢复案例，会有如下3种处理情况：

  1. 直接认为要恢复的数据发生了“同名覆盖”，起码数据库文件头部被破坏，不可恢复!
  2. 会按照数据库mdf文件类型对整个分区进行扫描，提取出若干个mdf文件，挨个去验证，看看有没有好的，(这种恢复方式几乎不能成功)，最后宣告恢复失败!
  3. 尝试按照MS SQL Server数据库页面碎片对整个分区进行扫描，因为数据库比较多，数据库页面碎片个数非常多，如果再加上对NTFS文件系统结构的熟悉了解，在扫描数据库页面碎片的时候，排除掉当前分区中正常存在的mdf文件的页面信息，单独提取硬盘分区NTFS文件系统中正常情况下不存放数据区域的数据库页面碎片，就是丢失掉的或者以前曾经存放过的mdf文件内容。通俗的讲，就是该分区被认为空闲的、可用的那部分空间中，就是我们丢失的数据所在的地方。提取出被遗失的所有数据库碎片页面，然后按照一定规律来拼接，最终还原出删除的mdf文件。

数据库碎片页面的概念

数据库文件在设计的时候都是按照一定的有规律的形式来存放的，数据库文件内部结构相当于一个小型的文件系统，我们了解NTFS文件系统，它有“簇”的概念，就是文件存放分配的最小单元。在数据库文件里头，有Page即“数据页”的概念，就是数据库文件结构按照一页一页存放，每一个页面占用16sec或者 32sec或者别的更大点的数，对于MS SQL Server来说，每一页的大小有16sec，每个数据页有自己的页面编号等信息，每个页面有自己的校验方式等等，我们在提取数据库页面的时候，就根据这些规律来的。当把所有数据库页面碎片提取出来以后，怎样把这些页面拼接成一个文件，又是一门数据恢复艺术!

数据恢复结果

本案例使用达思D-Recovery For MS SQL Server数据库恢复软件得以恢复，目前是国内少有的基于MS SQL Server数据库恢复软件。首先，它有数据库碎片提取功能，有一定的碎片智能组合功能，如果某条组合线路出现分叉，可以人工查看，确定正确的组合线路，最终能把mdf文件相对完整的拼接出来。

其次，它可以直接读取mdf文件内容，如果有某些数据页面被覆盖或者被破坏，它可以绕过这些坏页面，把mdf文件中正常的数据记录提取出来，然后进行数据还原。在mdf文件局部损坏的情况下，MS SQL Server环境没有办法修复mdf文件，没办法读取mdf文件中的数据，这时候D-Recovery For MS SQL Server就发挥它强大的数据库内容提取功能!

揭开数据覆盖假象

对本案例而言，出现了同名文件覆盖的现象，大多数人都认为是数据被覆盖了!在NTFS文件系统中，同名覆盖，往往意味着原先文件MFT表项和后面覆盖过来的文件的 MFT表项是同一个，MFT表项ID号(如果有ID号)不会更改，更改的只是MFT表项内部的数据指针!这样通过任何数据恢复工具扫描，不会找出原始文件 MFT内部数据指针，找到的都是新覆盖的文件的MFT表项信息。

数据区会不会也被新文件覆盖呢?答案是不一定!Windows操作系统在分配新覆盖过来的文件空间的时候，有可能会按照旧文件的指针分配，有可能分配新的数据空间，这就看Windows NTFS 文件系统文件空间分配机制了!如果说，新文件分配新空间，跟原始文件空间不发生重叠，那原始文件内容将不会受影响!

为什么按照mdf文件类型来恢复，没能找出正确的文件?数据库文件xiangmu01.mdf已经使用了两年多，数据库在创建的时候，数据库文件根据需要分配空间，而不是一开始就分配很大的空间，所以在以后使用过程中，空间分配分散很严重，在硬盘上不可能连续存放!按照类型扫描恢复文件大都基于数据文件连续存放，否则恢复出来的文件只正确包含文件地一段数据信息!

数据覆盖不是想当然，要经过最底层的分析，才能得出正确的恢复方法。