一块 2019 年的移动硬盘，让我重新做了一遍「找回删除的 49 图库」这件事。

从一块被放在抽屉第三层的硬盘说起

四月初我把一个旧抽屉清空，第三层压着一块 2019 年买的 2TB 移动硬盘，外壳磨得发白，标签上是我自己用圆珠笔写的「2019 备份 勿动」。接上电脑后，它发出了大约六秒钟的电流声，然后才被识别出来，盘符是 F。里面有一个名为「49图库」的文件夹，大小显示 0 字节，点进去是空的，但盘符属性里那张饼图证明分区确实占了 4.7GB。我意识到这是一次典型的「文件被删除、但空间没被释放」的现场，而我要做的，是找回删除的49图库这件事。

我用的是 Redler 数据恢复工具，版本 4.62，扫描耗时 41 分钟。扫描结果里跳出 2,301 个可用条目，其中可预览的 1,842 张。恢复之前我做了一个表，把每一张的原始路径、文件头 hex、修改时间三栏并排对照，因为我不想只拿回一堆「能打开但不确定是不是原物」的图。这件事后来变成了一种近乎偏执的整理习惯，我在49图库资料库免费打开49图库使用里写过一次，但这次的方法更细。

我是怎么给这 1,842 张图排序的

排序标准上我不接受「按文件大小」这种偷懒做法。我按三件事来：时间戳（精确到秒）、JPEG 的 EXIF 拍摄参数是否完整、以及同一批文件是否共享相同的 DCF 目录编号。第一批 611 张，时间集中在 2018 年 11 月 3 日到 12 月 19 日，EXIF 里相机型号写作 "DC-49A"，我查不到这个型号，倾向于认为它是某个压缩工具的伪写入。第二批 903 张，时间戳有规律的 50 秒间隔，明显是批量导出。剩下的 328 张没有任何元数据，只能靠像素哈希去重，最后删掉了 47 张重复。

去重这一步我用了两天。方法不复杂：算感知哈希，汉明距离小于 5 的归入同组，人眼复核。有人说这没必要，图库嘛，能看就行。但我的看法有一点争议——把一张来历不明的图放进「找回」的成果里，比没找回来更糟，因为你从此失去判断它的依据。这一条我不打算让步。顺手补充，如果只是要看，不涉及恢复，浏览器在线使用网页版其实够用，没必要折腾硬盘。

三个细节，三个麻烦

第一个麻烦来自目录。恢复出来的路径大多被截断成 "F:\RECOVER\0491~1.JPG" 这类短名，我原本想按原路径重建目录树，失败了。第二个麻烦来自缩略图缓存：Windows 的 thumbcache_*.db 里居然残留了 213 张原图的缩略图，128×128 那种，这让我至少能确认「当时的图确实存在过」。第三个麻烦是我自己在 2020 年 6 月 8 日干的事——我在笔记里留了一行「49 库已清理，勿再翻」，现在看来是给自己埋了个坑。

我在 4 月 9 日下午 3 点 17 分给做恢复的朋友林栎打了电话，问他能不能从 MFT 里再挖一层。他回了句："你这不是恢复，你这是在考古。"然后还是帮我把主文件表的残余项导了出来。文件名叫 mft_dump_20260409.txt，11.4MB，纯文本，我读了一整个晚上。后来我把这套流程的取舍写在49图库资料获取优化方案里，核心只有一句：先固定证据，再动手。

收录标准：我为什么坚持写"来源"一栏

整理到第 1,400 张左右的时候，我停下来重新定了收录标准。一张图要进最终库，必须满足三条中的两条：有可解析的 EXIF、有匹配的缩略图缓存、有可追溯的路径残余。三条都不满足的，单独放进 "unresolved" 目录，但不删除，标红。听起来啰嗦，但这是唯一能让我在半年后还敢说「这是我找回来的」的依据。有点讽刺的是，很多演示性质的页面——比如imtoken安卓版下载v2.9.5那种只负责展示下载链接的页面——恰恰缺的就是这一栏。

至于存储介质，我最后选了一块 512GB 的 SSD 做冷备，理由是机械盘在 2019 年那批产品上平均无故障时间标称只有 60 万小时，而实际使用里电机启动次数才是杀手。这段讨论我在474747浏览器最建议买吗的评论区里跟人争过一次，没争出结论，但至少把参数摆清楚了。

意外的收获

找回的 1,842 张里，有 317 张我完全不记得拍过或存过。它们大多是 2018 年冬天某个下午的连续截图，分辨率 750×1334，界面已经过时得厉害。这批图我没有放进主库，而是单独建了一个叫 "2018-winter-unknown" 的目录，写上"来源不明，保留待查"。失望的是主库最终只比恢复前多了 1,525 张能确认来源的；收获是，我第一次把"确认"这件事本身变成了可以量化的东西——1,525 / 1,842，83%。

这 83% 不是一个漂亮的数字，但它诚实。写到这儿我想起一件事：整理的最后一天，我把那块硬盘重新装回抽屉，标签换成了「2019 备份 已恢复 2026-04-10」。笔迹还是圆珠笔，只是这次我写了两行。