业内新闻

WINHEX 卷残留空间：那个被忽略的数据宝藏

你有没有遇到过这种情况——明明已经删除分区、重新格式化，甚至覆盖写入了一部分新数据，但用 Winhex 随手一翻，居然在卷的末尾或者中间看到一堆看似杂乱、但仔细辨认却能找到旧文件名的十六进制？

www.fixhdd.cn

嗯，这大概率就是“WINHEX 卷残留空间”在作祟。严格来说，卷残留空间指的不是文件系统层面的自由空间，而是那些本该被文件系统元数据“标记为已分配”但实际并没有被任何文件占用的扇区。更准确点说——卷残留空间 = volume slack space，包括簇尾部残留、未使用的分区间隙、以及文件系统删除后残留的目录项或索引碎片。这玩意儿对数据恢复工程师来说，既是救命稻草，又是头疼来源。

技王数据恢复

先说说“卷残留空间”到底长什么样

如果你直接把一个 U 盘或者硬盘挂载到 Winhex，用“Tools → Open Disk”打开物理驱动器（Physical Drive），然后切换到对应分区偏移（比如 2048 扇区作为起始），接着用十六进制浏览模式往后翻……你会发现一些区域里存在明显不属于当前文件系统的数据碎片。

技王数据恢复

举个例子：NTFS 分区下，$MFT 记录的末尾经常会有一些“非零”但又不属于任何有效属性的字节。这些就是残留——之前的文件被删除，MFT 条目被重用，但旧条目的部分属性数据还没来得及完全清零。更常见的则是簇尾部残留：文件实际大小可能只有 10 字节，但占用了一个簇（比如 8 扇区 4096 字节），簇的 4086 字节理论上属于“文件尾部数据”但实际是之前留在那个簇里的垃圾。对，这就是典型卷残留空间。技王数据恢复

注意：卷残留空间 ≠ 未分配空间（unallocated space）。未分配空间是整个分区里没有文件系统管理的扇区，但残留空间是已经被文件系统分配给某个文件或目录，但没被真正数据写满的扇区。这个区别特别容易混淆，很多新手以为用 Winhex 搜“free space”就能找到残留，结果找到的都是未分配区域。技王数据恢复

一个真实案例：误删虚拟机磁盘后的“废品回收”

大概三个月前，有个客户拿了一块 1TB 的西数移动硬盘过来，说里面存放了多个虚拟机 VMDK 文件，后来不小心格式化成了 exFAT，然后又拷了一些新照片进去。按常规思路，格式化后再写入新数据，原 VMDK 文件基本没戏。但客户说里面有个非常关键的企业财务系统备份，如果没有就完蛋了。技王数据恢复

我当时用的是 Winhex 的“Open Disk → Physical Drive”，然后直接定位到原来的分区起始（还好客户记得之前是 GPT 分区，起始 LBA 是 34 还是 2048？实际查了下是 2048）。在硬盘尾部我发现了一堆连续的大块数据——字节特征明显是 VMDK 的头部标识 “# Disk DescriptorFile”。但奇怪的是这些数据所处的扇区在文件系统里都被标记为“已分配”并且属于几个新拷的照片文件。

www.fixhdd.cn

我打开照片文件的 $DATA 属性，发现它们实际占用簇的大小远远大于照片本身的尺寸。每个照片文件分配的簇大小都是 4096 字节，但照片实际才 500~800KB，导致每个簇尾部都留下了大量之前虚拟机数据碎片。这就是经典的卷残留空间——新照片文件占用的簇里，尾部残存了旧 VMDK 的片段。 www.fixhdd.cn

于是我决定用 Winhex 的“Data Interpreter”配合“Search → Hex Values”寻找 VMDK 的特定签名，把每个簇尾部残留的扇区抽出来拼接。过程很繁琐，需要手动调整偏移——因为残留不一定正好在簇尾 512 字节边界。耗时两天，拼出了四个完整的 VMDK 文件，恢复了 90% 的数据。对了，那一次我参考了以前在技王数据恢复团队时积累的“卷残留空间提取工作流”，他们内部有一套基于 Winhex 脚本的半自动化方案，可惜现在没法用脚本，只能手撸。

，WINHEX 卷残留空间不是概念玩具，它是真实存在且能救急的数据保护区。

如何利用 Winhex 定位并提取卷残留空间？

以下是我总结的实操步骤，注意每个步骤都有坑。

第一步：确认文件系统簇大小与分区起始

在 Winhex 里打开逻辑分区（Logical Drive），查看分区引导扇区的 BPB（一般位于第一个扇区）。对于 NTFS，$Boot 扇区包含了每簇扇区数（Bytes Per Sector 和 Sectors Per Cluster 的乘积就是簇大小）。例如常见为 8 扇区/簇（4096 字节）或 1 扇区/簇（512 字节）。

一个小提示：对于 exFAT，它的簇大小通常更大，比如 128 扇区/簇，卷残留空间也更大。但 exFAT 的目录项效率较低，残留数据更容易被覆盖。

第二步：找到目标文件的簇列表

假设你要恢复旧数据，需要先知道哪些文件是新写入的（即占用簇但未填满簇）。一种方法是通过 Winhex 的“File Record”查看目标文件的 $DATA 属性中的 VCN-to-LCN 映射。对于 NTFS，可以用 “List Cluster Runs” 功能。但为了找到卷残留空间，你更关心的是那些“分配了但实际文件大小不足簇大小”的文件。

方法：点击 Winhex 的“Search → Find File Record”，输入文件名或通配符。然后双击记录，查看“Attr: $DATA”里的“Resident”或“Non-Resident”属性。如果是 Non-Resident，可以看到真实大小（Actual size）和分配大小（Allocated size）。两者的差值就是该文件对应的卷残留空间字节数。

第三步：直接扇区级提取残留部分

在 Winhex 中，你可以通过“Position → Go to Sector”跳转到文件数据所在的首簇 LBA，然后手动偏移到文件实际数据结束的地址，向后一直读直到该簇末尾。比如文件实际结束于簇内第 1000 字节，那么从 1000 到 4095 字节就是残留数据。

实际操作时更高效的方法是：

在“Text Editor”（文件查看器）中查看文件的数据，确认文件大小。
使用 “Select Block → Start of Sector → End of Cluster” 选中整个簇，再用 “Edit → Copy Block → Hex Values” 复制到新文档中，然后手动删除前 N 字节的有效文件数据。

注意——残留数据不总是连续排列，因为一个文件可能跨多个簇，每个簇尾部都有残渣。你需要按簇逐个提取并拼接。这很枯燥，但可以写一个简单的 Python 脚本配合 Winhex 的导出功能。

经验修正：小心“碎片拼接”陷阱

我踩过最深的坑是：一个 VMDK 文件的多个簇尾残渣，拼接后发现签名不连续。原因是文件系统在写入新照片时，不仅修改了簇分配，还可能把旧数据彻底覆盖了一部分簇。你提取的残渣可能来自不同版本的旧数据。一定要用校验和或已知签名做连续性验证。

常见故障判断：为什么看不到任何卷残留？

如果你按照上述步骤操作，但发现所有文件的分配大小都等于实际大小（即没有簇尾残留），或者看到的全是零，可能有以下几种情况：

分区被快速格式化后马上做了完整格式化？ 完整格式化（非快速）会用零填充整个分区，残留空间会被清空。
文件系统是 exFAT 且簇太小？ 有些设备簇设置为 512 字节，那么文件真实大小接近簇大小，残留很少。
是否选对了卷？ 注意 Winhex 的 “Volume” 视图显示的是文件系统分区下的逻辑内容，但物理驱动器上可能还存在隐藏分区或 VBR 备份区域的残留。Winhex 的“卷残留空间”在逻辑视图下定位的是当前分区的已分配簇，那些真正位于分区间隙（例如 GPT 保留扇区）的残留需要切换到物理驱动器才能看到。