很多数据恢复工程师包括一些数据恢复技术爱好者经常会问同样一个问题：“数据一旦被覆盖了，还能不能恢复呀？我听说国外能恢复被覆盖以后的数据，据说只要是覆盖操作在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文件，挨个去验证，看看有没有好的，(这种恢复方式几乎不能成功)，最后宣告恢复失败!

　　很多数据恢复工程师包括一些数据恢复技术爱好者经常会问同样一个问题：“数据一旦被覆盖了，还能不能恢复呀？我听说国外能恢复被覆盖以后的数据，据说只要是覆盖操作在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文件，挨个去验证，看看有没有好的，(这种恢复方式几乎不能成功)，最后宣告恢复失败!