合区后文件恢复：一次看似简单的合并，差点毁掉全部照片
上个月接了个Case，用户把D盘和E盘用Windows的磁盘管理直接“跨区合并”了——其实不是真正的跨区，是把两个相邻分区删了重建一个大分区。结果E盘里几千张家庭照片、孩子从出生到三岁的记录，全没了。他以为系统提示“合并成功”就万事大吉，打开新的大分区只看到一堆乱码文件夹。我问他“你知道合区前后文件系统发生了什么吗？”他答不上来。这其实是个非常典型的合区后文件恢复场景，今天聊聊其中的门道。
技王数据恢复
先搞清楚：合区到底对数据做了什么？
大多数人以为“合并分区”就是把两个区的内容像倒水一样倒进一个桶里，文件还在。但现实很残酷——Windows自带的磁盘管理，在合并分区时实际上执行的是：删除所有原有分区，再创建一个跨越原来空间的新分区。这意味着每个分区的文件系统头（DBR、NTFS的$MFT等）都被覆盖了。文件数据本身还在磁盘扇区里躺着，索引全部丢失。合区后文件恢复的核心就是重建索引，而不是“恢复已删除文件”。 www.fixhdd.cn
我说“等等，还有一种情况”
如果用户是用第三方工具比如DiskGenius里的“合并分区”功能，工具可能会试图保留一个分区的数据结构，把另一个分区的文件移动到剩余空间。这种操作一旦中途断电或软件bug，后果更复杂。遇到任何合区后的数据丢失，第一件事：不要写入任何新数据！ 别往新大分区里存东西，别格式化，别跑磁盘检查。
www.fixhdd.cn
一次判断失误的教训
有个企业用户，服务器上两个RAID5卷被管理员用存储管理的“Volume Merge”合了，然后发现重要数据库文件消失。对方IT自己用R-Studio扫描整个盘，扫出几十万个碎片文件，根本没法用。后来找到我们，我们分析后发现：合区操作只改了卷的起始偏移，数据库文件的实际簇链几乎没断。我们直接用WinHex手动解析了原分区的$Bitmap碎片，然后重建了VCN到LCN的映射。这就是典型的“合区后文件恢复”场景——不一定需要全盘重组，但需要对文件系统底层有极深的理解。
说到这，想起我们技王数据恢复的同事处理过一个更极端的：合区后还做了几次写入，把部分目录文件覆盖了，靠备份的$LogFile回滚才救回来。这种技术很依赖运气。
www.fixhdd.cn
千万别做的三件事（按照严重程度排列）
- 立即关机或停用该磁盘——防止系统自动写入日志或索引。
- 不要运行chkdsk /f ——它会试图“修复”文件系统，极有可能把原有数据目录标记为错误并清理掉。
- 不要尝试重建分区 ——拿原来的分区表信息去重写，如果偏移不对会彻底破坏数据。
实战：合区后文件恢复的标准流程
假设你手头有一个硬盘，合区后文件全部消失。第一步，用硬件只读锁（比如PC-3000的写保护）挂载，或者直接用FTK Imager做完整位镜像。我一般先用WinHex打开物理盘，观察0扇区是否有正常的MBR或GPT头。如果合区是用Windows磁盘管理做的，通常0扇区会变成新的分区表。然后跳到新分区的起始扇区，看DBR（NTFS的$Boot文件）。正常情况下，新DBR的BPB参数（每扇区字节、簇大小、$MFT起始簇号）应该是针对整个大分区的，但原来的文件数据分布在整个磁盘范围内。合区后文件恢复的第一步不是扫描，而是要在镜像里找到原始某个分区的文件系统残留。 www.fixhdd.cn
怎么找？举个例子：原来的E盘是NTFS，它的$MFT一般会留在一段连续的区域里。因为合区操作只改了前几个扇区，$MFT的物理位置没有动。我通常用WinHex搜索文件签名（比如“FILE”字符串），找到$MFT的起始地址。然后看$MFT的$STANDARD_INFORMATION属性，里面记录的父目录参考号可以帮我们重建目录树。这听起来繁琐，但比直接跑数据恢复软件可靠——扫描软件往往会漏掉跨区的碎片。
www.fixhdd.cn
案例随机化：一块混合了家庭视频和工作文档的500GB硬盘
一个设计师的移动硬盘，本来分C盘系统（已卸除）、D盘素材、E盘项目。他为了省事，把50GB的E盘和200GB的D盘合成了一个250GB的分区，结果项目文件全部不可见。我拿到镜像后，发现新的分区表把原来D盘的起始扇区定为新分区起始，而原来的E盘区域变成了新分区的后半部分。关键：原来的E盘文件系统$MFT位于新分区的尾部，但文件数据可能分散在前半部分（因为原来的D盘文件也占了空间）。实际上，很多文件被“覆盖”的概率很小，只是索引丢失。我用了R-Studio先做个快速扫描，它找到了两个旧的MFT镜像（因为NTFS有$MFTMirr），然后手动比对，把两个旧分区的文件列表提取出来——这就完成了合区后文件恢复。事后用户说，其实他后来还往新分区里复制了几个小文件，好在只覆盖了空白扇区，没伤到核心数据。真的是命大。 技王数据恢复
这种案例里，技王数据恢复内部会使用一个叫“Volume Snapshot”的方法：先解析新分区的NTFS元文件，找到所有未被覆盖的MFT记录条目，然后对每个文件尝试拼接数据流。如果发现某文件的数据簇被新写入覆盖，就只能靠碎片重组——但那成功率就低了。 技王数据恢复
核心操作步骤摘要（适合自己动手的紧急情况）
- 制作完整镜像（dd或FTK Imager，不要直写）。
- 用WinHex打开镜像，定位到0扇区，分析分区表，记录原分区的起始LBA（如果还能回忆起分区大小，可以从分区表残留里推算）。
- 在镜像中搜索原分区的DBR备份（通常位于分区末尾的一个扇区），可以拿这个DBR的BPB计算出原始簇的大小和MFT位置。
- 手动提取$MFT文件，用解析工具（如NTFS Walk或自写脚本）列出所有文件和目录的物理簇信息。
- 将文件的簇偏移映射到新分区的逻辑偏移（因为新分区起始扇区变了，需要加上偏移量）。
- 使用工具将数据流导出。如果文件连续，可直接复制；如果碎片多，需按VCN顺序重组。
注意：以上操作要求对十六进制和NTFS结构非常熟悉。如果没有经验，建议找专业机构，比如我们技王数据恢复，因为手动操作一步错就可能永久丢失数据。
结论：合区后文件恢复，别慌，但要快
总结一下：合区后文件恢复的可行性其实很高，只要合区后没有大量写入新数据，文件系统残留完好。关键在于正确识别原分区的文件系统残骸，并理解新分区表如何掩盖了它们。我见过最多的失败案例都是用户自己用各种“一键恢复”工具反复扫描写入，或者直接格式化尝试重建分区表。记住：数据恢复跟抢救伤员一样，第一时间做对的事情，后面就好办。如果你遇到了合区后丢文件，先断电，然后带着磁盘找懂行的人——最好能提供合区之前的分区布局信息（比如用DiskGenius之类的软件查看过的截图）。再强调一次：不要再往那张盘里写任何东西。
（全文完）
