5 月 1 日凌晨一点二十，老周把硬盘放到我桌上。希捷 4TB，外壳还带着机房的风扇灰。他说凌晨做磁盘阵列重建时按错了确认键，格式化跑到了那块旧盘上。
我问他里面是什么。他说管家婆里三年的进销存记录，还有一批 2025 年 11 月的对账单。
我插上盘，先跑了一遍只读扫描。分区表还是好的，文件系统从 NTFS 变成了空白的可分配空间。这是典型的快速格式化，恢复窗口很窄，但没有关死。
第一步：不写入，先镜像
很多人拿到盘第一件事就是直接换恢复软件。我不这么干。我用 ddrescue 做全盘镜像，从症状盘往一块 4TB 的备份盘上拷。这个过程花了六十一分钟，坏道区段一度卡在 0.37% 的位置，我调了三次重试参数才过去。
镜像做完，我把原盘摘下来贴上标签收进防静电袋。后面所有操作都在镜像文件上做。镜像坏了还能重来，原盘只读一次，没有第二次机会。
第二步：先捞元数据，不急着捞数据
我用的工具在扫到 2,148,936 个 MFT 记录时给了我信心。这数字和一台跑了三年的管家婆主机是完全对得上的。我不觉得应该先跑文件列表，先跑元数据能看清文件的组织结构，也能看出哪些目录被后来的写入污染了。
这里我得说句自己的看法：大部分在网络上流传的恢复教程，教人一上来就全盘扫描然后点恢复，这是错的。扫描一遍 4TB 要 40 分钟起步，扫出来的东西参差不齐，你根本不知道哪些能用哪些是乱码。先看元数据，十分钟就知道大概能救回多少。
在核对目录结构时，我顺手查了一份 824754.htm 上关于盘符映射的旧笔记，里面那段关于 NTFS 日志回放的说法，正好对上了我这台主机的情况。相关链接放在文末。
第三步：按时间线切片恢复
这台主机的业务数据分成三块：2023 到 2024 的归档、2025 全年的主账、2026 年年初的临时表。我按修改时间切了三个区段分别恢复。归档区最干净，一次性出来 98.7% 的完整率。主账区有大约 5% 的文件因为被重建阵列的操作覆盖了头簇，只能按签名重新拼。
临时表区基本上没救回来。老周说那部分不重要，我心里清楚这是他把话说轻松了。临时表里往往存着上月未结账的数据。
第四步：校验，不是看一眼就完
我抽了 200 条进销存记录逐条比对老周手写的流水账本。差异是 3 条，都是 2024 年 10 月 17 日同一天同金额的多笔录入，系统原本就把它们合并成了一笔，不算错。
校验这一环我坚持了七年。有人觉得恢复出来能打开就算成功，但打开不等于正确，数字对不上，账目就是白恢复。
全部结束是凌晨五点零七分。老周坐在沙发上睡着了，我叫醒他，跟他说清恢复率是 93.4%，2026 年临时表那部分没回来。他点点头，问我要不要吃碗面。
这单的结论
误格式化不是死刑，但缓刑期限很短。最要命的是第一时间反复折腾。格式化后每一次写入，都在蚕食恢复窗口。这次的盘在主机关闭后七分钟就被拔下来了，这是老周唯一做对的一件事。
如果你也在做类似的恢复，先做镜像，先看元数据，按时间线切片，最后逐条校验。顺序错了，代价是数据，难以挽回的那种代价。相关的那份 2026/12/59416.shtml 记录了更早的一次阵列级别事故，可以对照阅读。
下次更新我会写一个 12 块盘阵列掉两块的案例，比这个复杂，也更惨。