昨天下午三点十七分，我把那块贴了「2019 backup」标签的旧硬盘从抽屉最底层抽出来。灰尘在台灯底下飞，像一层薄薄的雪。硬盘是西部数据 2TB 的机械盘，2017 年买的，接口还是 USB 3.0 的宽口，插进新笔记本要转接头。我蹲在地上，用左手捏着转接头，右手点开 Finder。硬盘转起来的时候发出一种老式电风扇的嗡嗡声。我找了大概六分钟，在一个叫 「49图库backup_2019.06_final」 的文件夹里停下——4,117 个 JPG，外加一个 2.3MB 的 index.db。当时的我并不知道，这个数据库文件会成为接下来三天里让我反复骂人的核心。
我承认，我对图库管理这件事有职业性的偏执。
先说清楚背景。我 2018 年到 2020 年之间做过一段时间的小型图片资料整理，接的活儿不复杂，就是帮一些做设计的朋友把散落在各个平台上的素材归档。49图库那批图是其中体量最大的一块——原始来源已经模糊了，文件夹结构也很粗糙，按日期和编号排，比如 2019-03-18_00492.jpg 这种，没有分类、没有标签、连缩略图缓存都是乱的。那个 index.db 是当时一个叫 老周 的朋友帮我写的脚本生成的，用 SQLite 存路径和 SHA-1，他当时拍了胸脯说「这库能扛十年」。结果昨天我用 DB Browser for SQLite 打开，第一行就报 `database disk image is malformed`。老周去年搬去了成都，微信头像换成了他女儿的照片，我给他发了条消息，他回我一句「你试试 sqlite3 .recover」，然后就没下文了。
一句「你试试」，就是七十二小时的开始。
我先用 sqlite3 命令行跑了 .recover，导出 187 条记录，但 JPG 文件总共有 4,117 个，硬对硬是缺了一大截。接着我试了三个恢复软件——名字就不说了，其中一个扫描到 60% 的时候直接卡死，我盯着进度条看了四十分钟，最后用活动监视器强杀。后来我想起之前用过的一套比较老的 Python 脚本，思路不是修数据库，而是直接扫文件夹、按修改时间建索引，再跟那 187 条记录做交集。这个过程里，我印象最深的一个细节是：2019年6月11日 14:32:07 这个时间戳在索引里出现了 9 次，对应 9 张几乎一样的图，只是角落里水印位置差了十几像素。这种冗余就是当年批量下载留下的后遗症，迁就原始来源的命名规则，从来没做过去重。
图库维护的烂摊子，从来不是「丢了」，而是「乱到没法用」。
后来的解决路径比我想的更朴素。我把全部 JPG 按 SHA-1 重新算了一遍哈希，用不到 200 行 Python 把重复项标记出来，然后按年月重建目录，索引改用 CSV 存——不上数据库了，老周那套方案在我这儿宣告失败。中间我翻到之前保存的一篇参考页面，叫 恢复49图库手机版，里面的手动操作步骤我照着核对了一遍，对确认文件完整性有用，但没法解决数据库本身的问题。另外为了找备份来源，我又翻了 49图库资料网下载 上的旧版本说明，确认了文件名命名的历史规则，凑巧对上了好几个断档的编号。整个过程我都是在本机做的，浏览器只用来看这些参考页，中间有一次换设备，直接用 qq浏览器在线进入网页 登进去比对了一下旧页面，算是没有断线。
我讨厌「一键恢复」这四个字，因为真正的恢复从来不是一键。
写这篇东西的直接原因，是昨晚十一点我在群里看到有人问「有没有办法把 49图库的图一次性搬回来」。下面第一条回复是「用那个新入口查就行」。我点开一看，页面上挂着 新奥门494949.cm查询资料49图库维护 的链接，信息很杂，能看但没法直接用。我不是针对哪个站，我是真的受不了这个行业里默认的态度——把「找回来」说成一件不需要过程的事。4,117 张图里有 300 多张因为文件名编码问题变成了乱码，那是我一张一张改回来的，不是点一个按钮。说到这里我得摆明观点：任何声称能「自动还原完整图库」的工具，都是在偷换概念。资料库的价值不在图本身，在于那套被人嫌麻烦、却唯一可靠的元数据，丢了元数据，剩下就是一堆占空间的像素。
元数据不是附件，它是主体的一部分。
最后说一下结果。七十二小时后，我手上有了一个干净的结构：4,117 个文件、去重后 3,682 张、按年月分 27 个文件夹、一个 1.1MB 的 CSV 索引。比原来的数据库大了，也比原来慢，但我能在一分钟内定位任何一张图的来源。老周后来回了我第二条消息，说「你那个 CSV 方案太原始了」，我没回他。原始的东西活下来了，先进的东西躺在硬盘里报错，这件事本身就有意思。今天写下来，算是给自己留个完整的记录，也给同样卡在这一步的人一个参照，虽然我猜大多数人不愿意看这么长的过程。但我还是那句话，图库这行的问题，从来跟技术关系不大。