修复U盘卷位图损坏故障的经验小记

背景

这周在修复一个U盘的卷位图损坏故障时，因操作流程不当，导致丢失了部分数据。因此回顾记录整个处理过程，总结一下经验。

硬件&软件环境

• • U盘型号：金士顿USB3.0 32GB
• • U盘主控型号：群联Phison PS2251-07(PS2307)
• • U盘文件分区格式：exFAT
• • 执行chkdsk命令程序的系统版本：Windows11 25H2

科普：卷位图（Volume Bitmap）是什么？

在exFAT分区格式中，Volume Bitmap是指分配位图Allocation Bitmap。用大白话理解就是一张表，用于记录磁盘上每一个簇（Cluster）的占用状态，比如空闲或者已被占用。

簇大小（Cluster Size）是操作系统在硬盘上读写文件的最小逻辑单位。大伙们在使用Windows自带的格式化分区功能时，看到的「分配单元大小」指的就是簇大小。

平常我们使用的文件数据就是按照簇的大小被分割并存储在磁盘上，即使一个文件只有1字节，也会占用一个完整的簇。因此在创建或者格式化分区的时候，有时候也会根据使用特点来设置合适的簇大小，来保证磁盘空间的利用率和读写性能。

现代操作系统，默认分配的基本都是4096字节（4KB），这个方案对于小文件和大部分应用情况，拥有比较好的平衡性能和空间利用率。

卷位图损坏故障产生的原因

笔者这个U盘，经常需要插到其他终端电脑上拷贝写入数据。为了偷懒，笔者经常没有点击弹出U盘设备，而是直接物理拔掉U盘。

一般来说，U盘没有读写活动时，不执行弹出设备，直接物理拔掉也不会有什么影响。因为现在的系统基本都可以智能处理设备的挂载和卸载。

例如像Windows系统自Win10起，外部存储设备的默认策略就是「快速删除」。如下截图就是「磁盘管理工具」，选中整个金士顿U盘设备，查看「属性->策略」的信息。

「快速删除」这个策略就是允许用户直接物理拔掉U盘，而不需要使用「安全删除硬件」通知图标选项来断开设备连接。

但笔者情况是U盘不单只会在Windows系统中使用，也会有插入到Linux系统环境中的终端电脑上使用。Linux中虽有像udisks2系统服务实现U盘的自动挂载mount，但是卸载一般都还是需要手动点击「弹出」umount或者点击「安全移除驱动器」udisksctl power-off。

笔者就因为偷懒没有手动操作弹出，这个U盘终于在上个月某次非安全拔插的操作中出现了「卷位图损坏」。之后使用的几个星期内，我虽然察觉U盘出现了几个异常现象，但是一直也没太放在心上，因为这期间读写一些常用的数据文件并未遇到异常。

U盘的几个异常现象如下：

1. 1. 实际存储的文件总大小远大于U盘显示的已用空间。这是卷位图损坏的常见故障现象之一，即空间计算错误。因为位图数据本身就是错误的，很多簇本应该是标记为「已被占用」，但却被错误地标记为「空闲」，因此系统中读取到已用空间小于实际文件总大小。像笔者的情况，U盘磁盘总大小是29.7GB，系统读取到的可用空间是21GB左右，但所有文件实际存储大小约为17GB左右。
2. 2. 近期存储的好几个小图片文件，经常提示文件损坏，图片浏览工具提示无法识别图片格式。这是卷位图损坏导致系统以为某个簇（Cluster）是空闲状态，因此把新数据写入该簇（Cluster）指向的空间，但实际上该簇实际是存有图片文件数据的一部分，即文件重叠写入覆盖。这种情况使用chkdsk扫描基本扫描之后都会提示「文件xxx在分配单元 xxx 上交叉链接」，就相当于有两个文件同时声明「我有数据块存储在分配单元xxx上」，这种情况肯定至少有一个文件的数据已经是被损坏。

鉴于上周经常出现有不少的小图片文件损坏的情况，因此本周笔者专门抽空来处理这个U盘异常故障了。

PS：U盘闪存颗粒老化出现物理坏块，也可能会导致这种卷位图损坏故障的产生。这里就不展开说了。本文主要介绍「非安全拔插」操作引起的卷位图损坏的逻辑错误。

chkdsk修复命令

在Windows系统中，一般在终端命令行窗口中执行chkdsk命令可以执行扫描和修复错误。

@REM /f：修复错误
@REM /r：查找不良扇区并恢复可读信息，这个参数可以不使用
@REM /x：首先强制该卷卸载（如有必要）
@REM c:为磁盘盘符（如果U盘盘符是H盘，则输入h:）
chkdsk /f /r /x c:

修复磁盘错误，其实也有图形可视化操作「文件管理器 -> 右键磁盘 -> 属性 -> 工具 -> 查错 -> 检查」，如下图。不过一般也不推荐用这个方式，因为使用终端命令行窗口运行chkdsk工具，可以更方便查看命令的信息输出。

修复磁盘错误的可视化操作

笔者错误的操作

• • 执行chkdsk工具命令之前，没有对U盘数据进行一次备份。并且U盘最近的一次全量备份，已经是三周前。
• • 在「卷位图损坏」的情况下，多次重复执行chkdsk命令，并在其修复过程内中断执行chkdsk命令。
• • 中断这个操作，其实笔者也是无可奈何，主要U盘的主控太拉跨，性能不行。chkdsk工具在操作「通过复制解决交叉链接问题」时，观察任务管理器的U盘性能，发现读写活动呈现间歇性的十几KB的速率。但观察所修复的交叉文件很多，执行复制确实太费时间。
• • 「通过复制解决交叉链接问题」原理：这是chkdsk工具的一种补救措施，目的是让两个文件不再共用这一个簇，通过复制该簇的内容，原簇给其中一个文件，复制的新簇给另外一个文件。

由于上述愚蠢的操作，导致U盘数据产生更多的“交叉链接”和“孤立文件”。有一些原本不应该丢失的数据，却因为中断chkdsk命令导致变成了“孤立文件”。

下面展示一部分chkdsk输出的信息：

C:\Users\admin>chkdsk /f f:
文件系统的类型是 exFAT。
卷序列号为 2A8B-3D91
Windows 正在校验文件和文件夹...
卷标是 工作数据。
正在清除驱动器上细微的不一致性。
检查目录 \ (83)中的文件时发现损坏。
检查目录 \新建文件夹\ (28)中的文件时发现损坏。
检查目录 \新建文件夹\ (43)中的文件时发现损坏。
检查目录 \新建文件夹\ (46)中的文件时发现损坏。
检查文件和目录时出错。
检查卷位图时发现损坏。
Windows 正在验证文件分配...
\测试工具\xxx.png 在分配单元 78757 上交叉链接。
通过复制解决交叉链接问题。
磁盘空间不足，无法复制交叉链接部分。
已截断文件。
遇到关键错误。00。..
恢复丢失文件时出错。

U盘丢失数据的恢复思路

笔者发现中断命令导致丢失数据之后，立马停止了任何U盘的写入操作。

chkdsk命令修复过程也有写入操作的，数据丢失的情况下，就不要再执行了。

以下是恢复数据的操作思路：

1. 1. 使用DiskGenius工具对全盘进行了扫描（菜单->工具->恢复丢失的文件）

• • 注意数据恢复功能需要专业版才能支持。

• • 一种位置是孤立的文件：注意：孤立的文件已经是丢失文件夹路径结构的信息了，因此只能导出之后，通过查看文件内容、文件创建修改时间来判断原本存储的路径。
• • 第二种位置是标记成删除的文件。在原本存储的文件夹路径中会有一些被标记成「删除」数据，这类数据有一些是在移动文件夹或者重命名时产生的，只要丢失的数据之前恰好有这种操作，就能通过这种方式找回。

• • 笔者实测deCHK工具只成功还原2个xlsx的表格文件，其余均是无法识别，可能是chkdsk找回的CHK数据本来就是损坏的数据。

通过这一波操作下来，笔者恢复了70%左右的丢失文件（基本是近一周前写入的数据）。剩余30%丢失的数据都是近两周前写入的一些小文件，已经是完全丢失了。所幸这些数据之前已有整理，不是十分重要的，因此这次损失不大。

chkdsk成功修复磁盘错误的命令输出：

...
通过复制解决交叉链接问题。
已完成文件和文件夹验证。
Windows 正在验证可用空间...
  已处理 361137 个可用簇。
已完成可用空间验证。

Windows 已更正文件系统。
无需采取进一步操作。

总共有   31193056 KB 磁盘空间。
1246 个文件中有   19628640 KB。
271 个索引       7872 KB。
坏扇区          0 KB。
系统正在使用        160 KB。
磁盘上   11556384 KB 可用。

每个分配单元中有      32768 字节。
磁盘上共有     974783 个分配单元。
磁盘上有     361137 个可用的分配单元。

老生常谈：数据备份的原则

数据备份真的很重要！！！

重要数据还是建议按照经典的3-2-1备份原则进行备份。

• • 3份副本：除了原始数据外，至少保留2份额外的备份。
• • 2种介质：将备份存储在2种不同的存储介质上。
• • 1份异地：至少有1份备份存放在物理位置不同的地方。

U盘的使用习惯建议

• • 坚持安全删除：养成点击右下角“安全删除硬件”的习惯。
• • 定期执行chkdsk命令检测磁盘是否存在错误（如果每天都经常写入数据的话，并且懒得手动安全删除硬件的话，建议每天或者两天检查一次）

参考文献

[1] Allocation Bitmap Directory Entry[EB/OL]. https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification#71-allocation-bitmap-directory-entry.

#U盘 #数据恢复 #卷位图损坏 #目录损坏 #数据丢失 #chkdsk