3 月 2 日在旧机房的 4 号机架上核对分区表
那天我把硬盘挂到 Ubuntu 24.04 的救援模式下,用 testdisk 扫描了 42 分钟,找回了两个丢失的主分区,但第三个分区里的图库索引仍然是空的。
这块盘里存着近七年的图库素材目录,索引文件散落在三个分区,缩略图和原图早已不同步。关于 49tk 图库资料恢复,我能给出的不是结论,而是一次排查过程和几个还没回答的问题。
按时间倒序,每条对应一次实际的检查、比对或修复动作。
那天我把硬盘挂到 Ubuntu 24.04 的救援模式下,用 testdisk 扫描了 42 分钟,找回了两个丢失的主分区,但第三个分区里的图库索引仍然是空的。
她负责原图校验,我负责缩略图路径。1183 条里有 217 条的缩略图指向一个已经不存在的目录 /thumbs/v2,这个目录名在旧备份里从未出现。
用 wget --mirror 抓取页面结构时发现,站点本身只保留当前版本,历史目录的入口藏在分页的第 7 页之后,手动翻页几乎找不到。
脚本跑完之后输出 39 个目录节点,其中 11 个节点的标题是空的。空标题节点是不是内容已被删除、还是解析器没读到,我到现在也没弄清。
在 Android 14 的 QQ 浏览器 14.7 上复现,页面在第一屏后停止渲染,控制台报了一个 SyntaxError。桌面端则完全没有这个问题。
他说的没错:备份服务器的时区是 UTC+0,而图库索引写的是本地时间。两者相差 8 小时,导致按时间排序恢复时,有 6 天的资料顺序整体错位。
归档工具按关键词匹配,把「下载」「app」误判成图库资源。我手动删掉了 78 条误标记录,剩下 9 条因为 ID 重复不好处理,暂时留着。
其中一条是「缩略图与原图的哈希前缀必须一致」。我按这条规则跑了一遍,发现 211 张缩略图哈希不匹配,说明它们来自另一个来源。
那条规则依赖 Windows 的注册表路径解析,而图库索引是纯文本的相对路径。两种模型不兼容,我尝试手写映射表,写到第 54 条时放弃了。
第一层是栏目,第二层是批次,第三层是单图。问题在于第二层的批次编号不连续,缺了 17、23、31 三个批次,这三个批次在原备份里找不到痕迹。
合并脚本用的是 pandas.merge,结果发现了 412 组重复的 URL。同一张图被挂在不同的批次下,说明当初的人工录入并不严格。
老陈 2021 年就离开这个项目了,没人知道「老规矩」指的是什么。这条线索我留了一个问号,暂时没有继续查下去。
写给自己看的,也给碰巧读到这里的同行。
先说清楚起点。2 月 23 日下午四点左右,我把那块标注「图库-2014-备份B」的移动硬盘接到笔记本上,系统托盘弹出「文件系统无法识别」。这块盘是 USB 3.0 接口,2TB 容量,最后一次正常读取是 2022 年 11 月,之后一直放在防潮箱里。我第一反应不是数据丢了,而是分区表被覆盖,这种在旧盘上很常见。
用 testdisk 扫描了 42 分钟,找到了两个主分区,里面的文件结构还算完整。第三个分区却始终只能看到根目录,点进去是空的。图库的索引文件,也就是那个记录「哪张图在哪个目录、什么时候入库、属于哪个批次」的文本表,恰好在这个分区里。没有索引,原图就算全在,也等于一堆没有编号的散页。
我把索引的样本打印出来贴在墙上,看了整整一个晚上。它其实是每行一条记录,用竖线分隔字段:图片编号、原图相对路径、缩略图相对路径、入库时间、批次编号。看起来简单,但每个字段背后都藏着坑。比如相对路径的基准目录,在不同年份的备份里是不一样的;再比如缩略图路径,2018 年之前指向 /thumbs/v1,之后改成 /thumbs/v2,而 /thumbs/v2 这个目录在我手上的任何一份备份里都不存在。
林悦在 2 月 25 日晚上和我一起做了第一次逐行比对。她负责原图校验,我负责缩略图路径,1183 条记录,两个人分头看,花了将近五个小时。结论是:原图有 1089 条能够对应到实体文件,缩略图则只有 966 条能找到,剩下 217 条指向的就是那个不存在的 /thumbs/v2。我把这 217 条的编号抄在便签上,贴到显示器的边缘,现在还在那儿。
第一个疑问是时间戳。周启明在 2 月 20 日提醒我,备份服务器的时区是 UTC+0,而索引里写的入库时间是本地时间,两者相差 8 小时。这不是小问题:如果按时间顺序做恢复,有 6 天的资料会被排到错误的位置,而图库这种东西,顺序一乱,批次关系就断了。他建议我「先把时间轴统一,再谈恢复」,我现在认同这个思路,但统一到哪个时区,还没有定论。
周启明原话:「你先别急着恢复,先确认所有东西说的是不是同一个时间。」这句话我记在本子上,抄了两遍。
第二个疑问是缩略图的来源。我按 49图库资料库免费打开网站使用注意事项 里提到的校验规则做了一遍:缩略图与原图的哈希前缀必须一致。结果是 211 张缩略图的哈希对不上。这说明它们不是从原图生成的,而是从别处拷过来的,甚至可能来自另一个图库。这个发现让我不太舒服,因为它意味着「备份」这件事本身在我接手之前就已经不干净了。
第三个疑问关于批次编号的断档。我对照 正版4949图库资料库 的目录组织方式画了一张三层关系图,发现第二层的批次编号缺了 17、23、31 三个。这三个批次在现有备份里没有任何痕迹,既没有目录,也没有索引记录,连日志都没有。它们是真的从未存在过,还是曾经存在又被删掉,我找不到证据。
在抓取 49图库 官网 的静态快照时,我发现站点只保留当前版本,历史目录的入口藏在分页第七页之后。用 wget --mirror 抓了 2.1 GB,拿到了不少页面结构,但对索引本身的帮助有限,因为它给的是「现在有什么」,不是「曾经有什么」。
我又写了个脚本,去解析从 免费打开4949图库 页面结构里提取出来的目录节点,一共 39 个,其中 11 个节点的标题是空的。空标题的节点让我很困惑:它可能是解析器没读全,也可能是内容确实已经删了,只剩下骨架。我倾向于前者,但没有证据。
移动端也试了一次。按照 复制粘贴到qq浏览器打开 这条旧记录的方法,在 Android 14 的 QQ 浏览器 14.7 上复现,页面在第一屏之后停止渲染,控制台报 SyntaxError。桌面端没有这个问题。同一段代码在不同环境下的表现差异,说明前端对兼容性的处理并不一致,这对资料恢复来说是个坏消息。
说实话,我到现在都不确定「恢复」这个词在这里是否合适。如果索引丢失、缩略图不属于原图、批次断档、时间轴错位,那么即便把所有文件都找回来,拼出来的也不是原来那个图库,而是另一个东西。我甚至怀疑,追求「恢复原样」本身就是一个不现实的目标。
我的个人观点是:图库资料恢复的难点从来不在技术,而在「什么算恢复成功」这个定义上。
这句话可能会让一些同行不同意。他们会说,能读出来、能打开、能对应,就是成功。我不否认这个标准在工程上有用,但它回避了一个问题:对应上的东西,是不是原来那一个?我暂时没法回答。
还有几件事挂着。第一,那 217 条指向 /thumbs/v2 的记录,我打算从 2021 年的一份增量备份里找线索。第二,老陈留下的「按老规矩」那句纸条,我问了三个同期的人,没人记得。第三,我在 imtoken苹果版app下载 这个页面上误标的 9 条记录,还没清完。另外,参考 浏览器打开microsoftstore 里提到的路径规则,我尝试手写映射表,写到第 54 条时放弃了,因为两种模型的假设根本不兼容。
写到这里,问题比答案多。我把这些记下来,不是为了给出结论,而是因为怕忘。明天我会接着看那 217 条记录,如果找到 /thumbs/v2 的来源,我会再来更新这一页。
我叫江晚,做的是图库资料的整理与归档,断断续续有六年了。这个站是我给自己建的记录本,主要写下 49tk 图库资料恢复过程中遇到的细节、失败和没想通的地方。
我不是工程师出身,脚本是边学边写的,所以这里的记录可能不够漂亮,但每一条都对应一次真实的操作。我做这个站,是因为同类问题的公开资料太少,多数只讲结果不讲过程。
如果你也在处理类似的旧盘和旧索引,欢迎对照着看,但别把我的判断当结论,我自己都还在犹豫。
「恢复不是把东西放回原处,而是确认它原来在哪儿。」
—— 出自周启明 2026 年 2 月 20 日发给我的一封邮件,邮件标题是《关于时间戳的三个提醒》