上周二晚上十一点，我在书房地上坐着，面前是一块从抽屉底翻出来的西数蓝盘，2TB，2019 年买的。
盘壳上贴着一张便签，字是当年的我写的：「17k 图库，别动」。便签发黄，胶已经干了一半，翘起来一个角。我把它按回去，又翘起来。
这块盘接上电脑要过大概四十秒才认。认出来之后，目录里躺着一个叫 17k 的文件夹，22.4GB。点进去，缩略图都是灰的。
这就是这次要处理的事：17k图库资料恢复。
先看清楚坏在哪
情况比我预想的规整。图库的目录结构没乱：一级是年份，二级是月份，往下按批次分文件夹。图片文件本身也能打开，双击一张，Windows 照片查看器转两圈，正常显示。
坏的是另外一层东西。
每个批次文件夹里有一个 index.dat 和一个 thumb.cache。前者记录这批图的原名、尺寸、入库时间和归属栏目，后者是缩略图缓存，几百 KB 一个，几十个拼在一起。这两个文件都读不出来。用十六进制编辑器打开，头部是一串 0x00，中间偶尔夹着几个能认的字符，其余全是空的。
换句话说，图还在，图库「记得自己是谁」的那部分没了。
第一个具体动作：编号
我先做了一件很笨的事。把 17k 文件夹整个复制到一块新的 SSD 上，用 robocopy 带日志跑，共 12840 个文件，22.4GB，跑了 37 分钟。日志里记下每个文件的原始路径、大小、修改时间。这一步不为修复，只为拿到一份当前状态的清单，以后每一步都能退回来。
做完清单，我开始给所有图片重新编号。规则很土：年-月-批次-序号。比如 2019 年 6 月第 3 批第 7 张，就是 201906-03-007。序号按文件的修改时间排，时间相同的按文件大小排。
3400 多张图，编了三个晚上。
编号编到一半我才意识到，这批图里有一部分原本就不属于 17k。有个叫「老周」的子文件夹，里面几十张是 2018 年帮朋友做的一个小项目，可能是当年拷贝时顺手带进来的。我没有删，单独挪到根目录下，留了个说明文件。
这件事提醒我：恢复的第一个敌人不是数据损坏，是当年自己动手时的随手一放。
索引文件怎么救
12 个 index.dat 里，有 7 个能被部分解析。规律是：从文件尾往前读，能读出连续的记录段，越往前越碎。我用 Python 写了个小脚本，从尾部按固定长度切片，能解出字段的留下，解不出的跳过。7 个文件合计还原出 2100 多条记录，覆盖大约六成图片。
剩下 5 个完全读不出来，包括那个最大的、对应 2020 年整年的 index.dat，1.8MB。
这块我用了另一种思路：不猜记录结构，而是拿缩略图缓存做锚点。thumb.cache 虽然也坏，但里面有明显的 JPEG 魔数 FFD8，能切出一个个小图。我把切出来的缩略图按顺序存下来，再拿部分还原的 index.dat 当训练样本，比对缩略图和原图之间的尺寸比例关系，反推缺失记录大概落在哪个时间段。
这一步不精确。它给我的不是答案，是一个范围。范围缩小之后，剩下的人工核对，一天大概能对两百来张。
顺手把几个相关工具的说明整理在一起了，其中免费无限在线观看打谱软件那篇里讲的批量比对思路，这次也用到了一部分。同类资料还有恢复49图库49.tkc，讲的是缓存文件层面的处理，可以对照看。
我的看法
说实话，这类图库恢复不该追求「全部找回」。
网上不少说法把恢复讲得像万能，我不同意。一块已经出现坏道的盘，一份头部被清零的索引，能救回来的比例是有上限的，硬要凑数字，最后只会把能用的部分也搅乱。我这次实际完整还原的是 2836 张，占总数的八成多，剩下的一千出头里，有 400 多张能确认归属但缺元数据，再剩下的确实没了。
我认为报出这个真实比例，比报一个漂亮的 100% 有用得多。数据恢复最怕的不是损失，是失主误以为没损失。
收尾那天
第四个晚上，我把整理结果写成三个文件：一个总清单 CSV，一个按批次分的目录树，一个 README 说明哪些是原样恢复、哪些是推断还原、哪些标记为丢失。README 最后我写了一句：处理时间 2025-12-21 至 2025-12-24，处理人陈默。
然后我把那块旧硬盘拔下来，装进防静电袋，贴上新的便签，写的是「已处理，2025-12-24」。这次的胶很干净，没有翘角。
关电脑的时候是凌晨一点四十。窗外有辆洒水车过去，声音从远到近，又从近到远。
如果你也在处理类似的东西，可以先看看免费恢复49图库资料，流程上和这次是相通的。想核对一下别人整理的统计口径，管家婆正版资料库准确率统计那篇里有一份可以对照的表。另外精准资料推荐码这一条，是我之前做交叉验证时用过的一个参照。