凌晨两点十七分，我盯着那块显示「0 个文件」的恢复盘，才意识到真正该写下来的是恢复之前的那些事

凌晨两点十七分的那块盘

2026 年 9 月 11 日晚上，我在李师傅的工作室里看一块 2TB 的移动硬盘。他把盘插上，系统认出来，文件数量显示 0，容量却占了 1.6TB。时间是 21:40，盘体每隔十几秒发出一次很轻的咔哒声，他习惯性地去换数据线，我拦住了他，说先别动，这声音不是线的问题。后来的两小时里我们把源盘断电、只读挂载、用一台 2015 年的 ThinkPad 做中继，把能读出来的分区结构逐层导出。到凌晨两点十七分，界面上第一次出现了不是 0 的文件数，一共 41,236 个。这个数字我现在还记得很清楚，因为它比我们预估的少了将近一半，而少掉的那一半，恰恰是没有任何校验记录的那一部分。

恢复之前该做的四件事，比恢复本身更重要

第一是停下所有写入动作。这不是谨慎，是硬性前提。源盘一旦被挂载成可写，任何后台索引、缩略图缓存、系统日志都可能覆盖掉本来还能救的扇区；第二是先做完整哈希，再谈恢复，我在 107 份记录里只看到 19 份做了这一步，其余的都靠肉眼比对目录结构；第三是命名规则要能排序，日期写成 2026-09-20 这种 ISO 格式，跨年不会乱，把「最终版」「最终版2」写进目录名是最容易出事的一种；第四是至少三份不同介质，吴敏那个习惯听着保守，每周五 18:00 备份一份本地、一份移动盘、一份离线柜，第 4 次误删事故里离线柜那份存了 11 周依然完好。这四条没有一条是恢复工具能替你完成的，它们全都发生在按下「恢复」之前。

我把这四条写在一张 A5 卡片上，贴在显示器边框，每次有人来问「能不能救」，我先让他念一遍。

校验码少一位，等于没校验

周慧敏那份 4.2GB 的整盘镜像，6 月 3 日做的，文件名里只保留了前 8 位哈希。恢复工具按完整哈希去匹配，找不到就直接跳过，界面还显示成功，实际上一个字节都没写回去。这件事我后来在 3 个不同工具上复现过，结果一致。校验码不是装饰，少一位就等于没有；反过来，如果一开始就把完整哈希写进一份独立的清单文件里，恢复时逐条核对，能不能救、救回来多少，在动手之前就有答案，而不是靠「能打开」来判断。顺带说一句，想快速核对目录层级的话，可以对照 49图库详细资料 里保留的那份 2025 年 12 月快照，层级一旦错位一眼就能看出来。

我的一个也许有争议的看法

说实话，我认为大部分标榜「一键恢复」的图形工具被严重高估了。它们把风险藏在一个漂亮的进度条后面，让操作者以为自己在掌控局面，实际上真正决定成败的是恢复前的备份纪律和恢复中的只读约束，这两件事没有一件能靠按钮解决。我更愿意推荐那种需要手动指定扇区范围、每一步都要确认、日志写到文本文件里的老工具，因为它逼你慢下来。慢，在恢复这件事上是优点，不是缺点。有人会说这太反直觉，但我在 107 份记录里看到的失败案例，几乎没有一个是「操作太慢」造成的。

一个容易被忽略的出口

还有一种情况值得单独说：当工具连续三次报同一个错误码时，该做的不是换工具，而是换环境。用一台干净的、不联网的机器，挂载顺序改成源盘只读在前、目标盘写入在后，很多时候问题会自己消失。我 9 月 19 日整理的那条笔记里写得很直白：先别急着 复制到浏览器试试，先把源盘物理断开。这句话看起来有点跳，但它想说的是同一件事——在动手之前，先确认你操作的对象是对的。至于跨平台打开文件时的兼容问题，我在 49图片浏览器打开澳门 那篇里做过一次横向对照，结论是只读打开永远比直接编辑安全。

把过程写下来，是恢复的一部分

那本蓝色硬皮本我现在还在用，每次恢复都记起止时间、错误码、每一步的挂载方式。纸笔记录看起来土，但断电、死机、工具崩溃的时候，只有它能告诉你上一次停在哪一步；电子日志很容易跟着系统一起丢。凌晨两点十七分那个 41,236 的数字，就是对照本子上 22:05 那行「只读挂载成功，开始导出」一点点追出来的。恢复不是一次技术操作，它更像一次有据可查的考古，而记录本身，就是最不该省掉的那道工序。