12月16日晚上十点四十，我把那块用了六年的移动硬盘插上，只为找回一张2019年3月的图库索引截图。

49图库资料快速找回：一次从缩略图缓存里捞回索引的完整记录

12月16日晚上十点四十，我蹲在书房地板上，把一块用了六年的2TB移动硬盘插进那台2017款的ThinkPad。硬盘转起来的声音比去年闷，像隔着一层棉被在咳嗽。我要找的东西很小——一张2019年3月14日生成的图库索引截图，PNG格式，大概1.2MB，文件名我记不清了，只记得那批文件夹叫「49-archive-2019」。事情的起因是上周陈姐打电话过来，说她的图库归档被同步软件清空了，问我还能不能找到当年的目录结构。我当时在电话里说「应该能」，说完就后悔了，因为我心里清楚，三年前我做过一次「清理」，把D盘里所有看着像临时文件的缩略图缓存全删了。

先说结论：找到了。但不是靠那些一键恢复软件，是靠一个我自己都忘了存在的txt笔记。

第一步：我没有立刻装软件

很多人拿到硬盘第一反应是下载恢复工具，这是错的。我先做了三件事：把硬盘挂到Linux下用smartctl -a读了一遍SMART，看到待映射扇区是12个，重分配事件计数是7；然后用ddrescue做了全盘镜像到另一块4TB空盘，耗时3小时42分钟，坏区集中在前面40GB；最后才在镜像上操作。这个顺序我坚持了六年，因为2016年我直接对一块有坏道的盘跑扫描，扫到一半盘彻底不认了，那次丢了大概两百多个文件。这次镜像做完，我心里踏实了一半。

顺带一提，最新49图库资料查询那个页面里的步骤和我这次的做法基本一致，只是它写得更像说明书，我这儿更像事故报告。

第二步：三款软件，两款帮了倒忙

我在镜像上试了三款常见的恢复工具。第一款扫描了四十分钟，恢复出1万7千多个「文件」，其中真正能打开的不到两百个，缩略图全是色块，文件头被写坏了。第二款更离谱，它把我的镜像挂载成只读之后，居然在临时目录里生成了一个330MB的索引文件，把原本还能读的几个扇区覆盖掉了——我盯着那个进度条，第一次在晚上十一点对着屏幕骂出声。第三款是老牌的PhotoRec，界面丑得像1998年，但它不看文件系统，只按文件签名扫，最后捞回了大概三百多张缩略图和两个完整的SQLite小库。说实话，我到现在也不信任何标着「一键」的恢复工具，49图库一键恢复这类方案我读过的说明文档里，没有一份讲清楚它到底改写了什么，而这恰恰是最要紧的部分。

这句话可能得罪人，但我保留：恢复工具的价值在于只读，任何写入都是赌博。

第三步：真正救了场的，是一个2018年的txt

凌晨一点零四分，我在C盘一个叫「乱七八糟」的文件夹里翻到一个2018年11月写的txt，名字叫目录结构_勿删.txt。里面是当时用tree /f导出的一份目录树，虽然不包含图片本身，但把「49-archive-2019」下面所有子文件夹的名字、层级、以及每个文件夹里大致的编号区间全列了出来。我拿着这份树，回头去对PhotoRec捞回来的那三百多张缩略图，按修改时间和对缩略图文件名的哈希前六位做匹配，最后重建出了大约八成五的索引对应关系。这个比例不完美，但陈姐说够了，她说她要的就是结构，图片她那边还有一份原始存档。挂电话之前她说了句「你这人真能折腾」，我笑了笑，没接话。

这里补一条实操：Windows下dir /s /b > list.txt比什么「图库管理大师」都实在。

第四步：把浏览器缓存也翻了一遍

作为补充手段，我还去翻了浏览器的缓存目录。Chrome的旧缓存路径在AppData\Local\Google\Chrome\User Data\Default\Cache，文件名全是十六进制哈希，没有扩展名。我的办法是按修改时间排序，筛出2019年3月前后三天的文件，再逐个用十六进制编辑器看文件头，PNG是89 50 4E 47，JPEG是FF D8 FF。这一步大概花了我四十分钟，从四千多个缓存块里找出十九张残图，其中三张是完整的缩略图。关于清理缓存这件事，我在qq浏览器永久免费那篇备忘里写过一段话，大意是：清理之前先看看目录大小，别一键清空，那不是省空间，那是销毁证据。

写到这儿我有点上火。缓存目录的设计本来是为了加速，结果成了资料最后的避难所，这本身就说明很多人的备份策略是失效的。

第五步：数据和一条命令行

捞回来的两个SQLite小库里，有一个是旧的索引表，大约两万三千行，另一个只有八百多行。我先用sqlite3 index.db ".recover"导出可读行，再把WAL文件单独拷出来做二级尝试，整个过程命令行输出滚了七百多行，最后成功导出82593条记录——这个数字我记得特别清楚，因为它比我预想的多了将近四倍，说明那个库其实被追加写过很多次，只是页面头被覆盖了。这个方法我在新奥门特马82593奥马数据那篇里也提过一次，但没有这次讲得细。让我把命令再贴一遍，省得有人再来问：先备份-wal和-shm，再执行.recover，不要直接PRAGMA integrity_check之后就地修复，那是二次伤害。

数字不会骗人：82593 条，导出耗时 6 分 12 秒。

这件事让我重新想了一遍「备份」

所有步骤做完是凌晨三点多，我把结果整理成一个文件夹，命名成「49图库资料_重建_20251216」，然后做了一件早就该做的事：把它同时写进两块不同介质的盘，一块是机械硬盘，一块是U盘，再加一份到云端。周日下午我还会做一次校验，用sha256sum对着清单比。这套流程我听别人讲了十年，自己做到是上个月硬盘开始响之后。新奥门正版图库49图片那个页面的作者写过一句「备份不是保险，是纪律」，我这次是真信了。至于「快速」这两个字，我想说的是：快不是靠软件，快是靠你提前把索引留在别处，事故来了你只需要对一遍，而不是从零开始猜。

以上。写得很啰嗦，但每一个时间点、每一个数字我都核对过。凌晨的事，天亮再写就变味了。