2026 年 9 月 21 日,陈默在备份盘里翻出一份 2024 年的索引快照
这份快照只有 214MB,解包后索引条目 47 万条,比现网少了将近三分之一。他把它挂进临时库试跑,发现缩略图的哈希值有 83% 能对上,剩下的对不上不是因为损坏,而是当时生成缩略图的那版程序改了采样算法。
一份按时间顺序记录的完整资料:从中继缓存、索引重建到素材源逐条比对,包含失败的那几次、意外找回的那几批,以及至今没弄明白的两个疑点。
这份快照只有 214MB,解包后索引条目 47 万条,比现网少了将近三分之一。他把它挂进临时库试跑,发现缩略图的哈希值有 83% 能对上,剩下的对不上不是因为损坏,而是当时生成缩略图的那版程序改了采样算法。
机房的运维老周说,那台机器本来 2024 年就要下架,因为迁移脚本报错一直搁着。我们下午三点进去,四点十分把原图按目录名批量拉出,一共 12043 个文件,其中 47 个文件的时间戳是 1970 年,明显是拷贝时丢过元数据。这部分后来单独归档,没混进正式索引。
八月底那轮操作,我让助理先批量重命名文件,再重建索引,结果两边的 ID 规则对不上,整整两天白做。后来改成索引先行、文件后补,重跑一次只花了四个半小时。这件事我在周会上说了三遍,不是抱怨,是因为顺序错了以后排查成本会翻十倍。
当时的页面依赖一套老版本渲染逻辑,用新浏览器打开总是缺一层资源。参考了 qq浏览器8.4.0旧版本 的安装包和版本号记录,我们在一台虚拟机上装回旧版,完整走了一遍请求流程,才确认缺口出现在第二层缓存上,而不是服务器端。
我把手上能确认的部分,和公开可查的 新奥门正版图库资料49 条目做了交叉比对,字段口径基本一致,差异集中在更新频率上:对方按周更新,我们是按批次。这个差异不影响内容本身,但会影响时间戳的判断,做恢复时容易误判为缺失。
问题出在去重键上,我只用了文件名,没带目录前缀,结果同一批图在不同分类下被反复写入。两小时后跑完,数据库体积涨了 1.8G,实际有效条目不到 400 条。那天晚上我把它整表回滚,也是从那次起,所有脚本都必须先过沙箱。
研究 正版49图库资料免费打开49图库app安装教程 时注意到,它的安装步骤里明确写了先装资源包再装主程序。这个细节和我们的资源加载顺序一致,也反证了之前把资源包放后面的方案是错的,至少对旧设备不友好。
这个小改动其实没有什么技术含量,就是在测试机上把外部链接的打开方式统一收归内置。做法参考了 qq浏览器打开app设置 里的描述,改完之后连续测了三天,缓存命中率从 72% 涨到 83%,样本不大,但趋势稳定。
对照 澳门正版资料免费公开查询资料库平台入口1902 的字段说明,我发现自己的索引里把「来源」和「采集时间」两个字段的命名搞反了,导致按时间排序时结果总是错位。修正后重新导出,时间线终于对得上了,这个错误存在了将近两个月。
这两张图在看图软件里显示正常,转成无损格式再对比,最后一行是纯色的补齐像素。我试过从三个来源分别下载,结果完全一样,说明源文件本身就是这样。这可能是当年批量处理时的已知缺陷,但我没有找到记录。暂时标注为待查。
九月二十一日下午两点四十分,陈默把一块落灰的移动硬盘插到我的工位上,说里面有一份 2024 年 11 月的索引快照,问我要不要试试。我当时的期望值很低,因为前面两个月已经试过四次,三次失败,一次只恢复出一半。硬盘转起来的时候声音很大,风扇也跟着响,我们两个人就那么站着等了大概四十秒,直到系统把它识别成一个 931G 的卷。新奥门正版图库资料49 里提到的条目编号规则,正好和这份快照是同一套,所以我第一眼看到目录结构的时候就知道,这次至少方向没错。
解包的过程比预想的顺利。快照文件 214MB,解出来索引条目 47 万条,比现网少了将近三分之一,但保留了两套完整的分类树。我让陈默先别急着全量导入,而是拿其中一个小分类做对照——这个习惯是七月那次事故之后养成的,那次我在没做对照的情况下直接覆盖,结果把一个本来完好的索引搞坏了,花了六个小时才从另一份冷备里拉回来。所以这次我们先挑了一个包含 1200 条索引、340 个原图的小分类,手动入库,再逐条比对哈希值。结果比预期好,83% 的缩略图哈希能对上,剩下 17% 对不上,一开始我以为是大面积损坏,后来查了生成日志才发现,是当时那版程序改过采样算法,属于正常差异,不是数据丢了。
真正意外的是第二天。宁德路机房那台旧机器本来八月底就该下架,因为迁移脚本一直报错就搁着没动。运维的老周打电话来问我要不要去看看,说里面可能有一批原图。我们在下午三点进去,机房温度很低,我在门口站了一会儿才适应。四点十分开始按目录名批量拉取,一共 12043 个文件,其中 47 个文件的时间戳显示 1970 年,明显是拷贝时丢了元数据。这 47 个被单独归档,没有混进正式索引。也就是在拉取的过程中,我注意到有一个目录名带了「tk49」前缀,点进去看了一眼,居然就是快照里缺失的那部分缩略图对应的原图。这个发现纯属运气,但它让我确认了一件事:正版49图库资料免费打开49图库app安装教程 里强调的「先资源包后主程序」的顺序,在文件层面同样成立,源文件永远应该先于派生文件被固定下来。
恢复过程中我记录了所有排查步骤,也留下了三份失败的版本。其中一次失败的版本特别值得说:八月三十日,我写了个自建爬虫想补充缺失的条目,跑了两小时,抓回来三万多条,结果全量导入后数据库涨了 1.8G,有效条目不到 400 条。原因很简单,去重键只用了文件名,没有带目录前缀,同一批图在不同分类下被反复写入。那天晚上我把整张表回滚,也从此定了一条规矩:任何脚本先在沙箱里跑一遍,再去碰正式库。这件事和周会的记录我都留着,写在这里不是自我批评,是因为它和恢复本身直接相关——不把失败写清楚,后面的每一步都会被重复讨论。
还有一个细节,可能只有做同类工作的人会在意。九月初我们用旧版浏览器复现 2024 年那条访问路径时,在新版本上总是缺一层资源,反复试了好几次都没结果。后来参考了 qq浏览器8.4.0旧版本 的版本号记录,在一台虚拟机上装回旧版,完整走了一遍请求流程,才确认缺口不在服务器端,而在第二层缓存上。知道这一点之后,我们对缓存策略的调整就变得非常直接:不是加大缓存,而是把第二层的过期规则改掉。改完之后连续测了三天,命中率从 72% 涨到 83%,样本不算大,但趋势是稳定的。同一天我还顺手调整了外部链接的打开方式,做法参考的是 qq浏览器打开app设置 里的描述,改动很小,效果却很直观。
关于字段命名,我得承认自己犯过一个持续了将近两个月的错误。八月中旬,我拿自己的索引字段去对照一份公开的查询平台说明,才发现「来源」和「采集时间」这两个字段的命名搞反了,导致按时间排序时结果总是错位。修正之后重新导出,时间线终于对得上了。对照的那份说明来自 澳门正版资料免费公开查询资料库平台入口1902,它的字段定义比我原先自己约定的一套清晰得多,这件事让我改变了做法:以后所有自建索引的字段名,都先找一份公开的规范做参照,不再自己拍脑袋。
还有两张图,到现在也没弄清。它们在看图软件里显示正常,转成无损格式再对比,最后一行却是纯色补齐像素。我试过从三个不同来源分别下载,结果完全一样,说明源文件本身就是这样,不是传输损坏。我倾向于认为这是当年批量处理流水线上的一个已知缺陷,但没有找到任何一条记录能佐证这个判断。这两张图暂时标成待查,没有删,也没有并入正式索引。比起宣称「已全部恢复」,我更愿意留两个明确的问号,至少下次接手的人知道该往哪里查。
写到这里,我意识到这份资料真正的价值可能不在结论,而在过程。47 万条索引、12043 个文件、83% 的哈希匹配率、11 个百分点的命中率提升,这些数字单个看都平淡,连起来就是一条能被人复走的路。门在哪儿、卡在哪儿、哪一步我绕远了,都写在上面。剩下的两个疑点我暂时没有解开,所以这篇就先这样。
我叫江晚,做的是数字资料的归档与恢复,简单说就是别人眼里那些「已经打不开的东西」,我负责一条一条弄回来并记清楚过程。我大部分时间花在索引、缓存和素材源的交叉核对上,工具是旧机器、脚本和大量的手工比对。
这个站是我把每次工作的记录公开出来的地方。写它不是因为有什么了不起的经验要分享,而是因为我发现同样的坑每隔几个月就会被不同的人踩一次,而公开出去的记录至少能让下一个人少绕几步。
我写东西慢,喜欢一条一条列清楚,有时候显得啰嗦。但恢复这件事本身就是细碎的,我愿意把它保持这个样子。
「备份不是把东西存起来,是让自己在需要的时候还能把它找回来。」—— 出自陈默 2026 年 9 月 21 日在我们工位上说的话,原话里没有「备份」两个字,这是我转述时替他补的,他认了。