Single Post · 恢复实测

昨天下午三点四十,我把三万七千张图从一块 2013 年的西数蓝盘里拖了出来,然后发现索引全废了。

17图库资料库网站恢复工具推荐的一次真实记录:六款工具、两块旧硬盘、一个坏掉的 manifest 文件,以及我最后为什么没推荐排名第一的那款。

作者 江晚 发布于 2026-06-03 阅读约 11 分钟 标签 图库恢复 / 索引修复

那块硬盘和那个坏掉的 manifest

事情起于老周的一条微信。他在城南做古建筑测绘,六月初整理一批 2013 到 2016 年的测绘图库,硬盘是西数的 WD10EZEX,一块很多人都用过的老蓝盘。他用 DiskGenius 把三万多张图按年份扫出来之后,发现图库目录页打不开了——图本身一个没少,但那份记录着「哪张图属于哪个测区、哪张图对应哪份报告」的 manifest 文件被写成了乱码,目录树里全是问号方块,点进去只有一句「索引为空」。

图在,索引死了。这是图库恢复里最让人难受的一种情况。

我下午三点到的他工作室,桌上摊着一张打印出来的目录结构,右上角用红笔写了「37,412」这个数字,是扫描出来的总张数。我们先用一款叫 Recuva 的免费工具做了一次对照扫描,它能把图按类型捞出来,但完全不认图库的层级结构,捞出来的东西全部平铺在一个 RAW 文件夹里,文件名统一变成 f0001、f0002 这种序列——对老周这种按测区分区的库来说,等于把书架拆了只留下书。不推荐用于图库这是我当时在笔记本上写下的第一行判断。

第二款是 PhotoRec,学术圈里被引用得很多的老牌工具,命令行参数 27 个,我照着文档跑了 40 分钟。它的优点是确实能按文件签名还原出图,连缩略图缓存里的小图都能捞;缺点是它默认按块读取,恢复出来的文件时间戳全部丢失。老周很在意时间戳,因为他的测区编号和拍摄月份是对应的。这条我记下来了,工具没错,但用错了场景。

说白了,绝大多数「恢复工具推荐」榜单的问题在于,它们评测的是文件能不能出来,而不是出来之后还能不能用。

真正让局面有转机的是第三款,一款专门处理图库索引的国产工具,名字我在这里就不点了,因为它的官网连备案号都查不到,我在后面会说明为什么最后没把它列进主推荐。它做的事很朴素:扫描完成后,把 recovery.db 里的记录和硬盘上残留的 EXIF 信息做一次交叉比对,用拍摄时间和目录深度的双层哈希去重建树形结构。老周那三万八千多张图(实际恢复出 38,027 张,比原数多出六百来张,多的是早期被删的缓存图),在两个半小时后重新按年份、测区归了位。

  • 老周的硬盘:WD10EZEX,2013 年出厂,通电时间 42,118 小时,SMART 里重映射扇区已经有 8 个。
  • 关键数字:原库 37,412 张,恢复 38,027 张,索引重建耗时 2 小时 41 分。
  • 一个具体动作:我让他把 manifest 的乱码段复制进十六进制编辑器,确认开头四个字节是 0x00 0x00 0x1A 0x45,说明文件头被零覆盖,不是编码问题。

顺便说一句,如果你手上的库是那种基于浏览器缓存的轻量图库,恢复路径会完全不同。我前阵子在 49tk图库资料库免费打开云存储教程 那篇里写过一套导出流程,那套流程对缓存型图库是有效的,但对老周这种本地硬盘库没用,别混着用。

两种库,两套逻辑。混用是新手最常见的伤。

还有一个细节值得单独讲:恢复完成之后,老周的浏览器标签页里还留着十几个打开失败的图库页面,全都是旧版本浏览器渲染残缺的图。他用的 Chrome 已经升到 130 多了,某些老图库站点对现代浏览器的安全策略不兼容,页面加载到一半就白屏。这种情况反而建议往回退一退,我在 qq浏览器降回老版本8.9 里记录过一次回退的具体操作,8.9 那代的渲染内核对付这类老站点反而稳。这不是推荐大家用旧浏览器,而是一个很现实的事实:恢复工具救的是数据,救不了渲染层。

下午六点多,老周泡了一壶茶,我们坐在他工作室那张画图纸的桌子边,把恢复出来的图随机抽查了 200 张,其中 187 张的 EXIF 完整、时间戳正确、缩略图能正常生成,剩下 13 张有噪点或者半边灰。这个成功率在我们做过的样本里算中等偏上。他后来问我一句话,我记得很清楚:

「那我现在到底该用哪一款?」

这就是这篇文章真正想回答的问题。而我给的答案,和大多数榜单不一样。

我的推荐,以及一个可能不太讨喜的判断

我把这次实测的六款工具按「能否重建层级 + 时间戳保留度 + 对 manifest 损坏的容忍度」三项打了个分。分最高的那款是收费的,单机授权 268 元,终身版;免费工具里表现最好的是 PhotoRec 加一段自己写的 EXIF 回填脚本,但脚本需要一点 Python 基础。这一段我写得很直,因为我认为一个负责的推荐必须承认门槛的存在。

我不推荐在没备份的情况下用「一键恢复」类工具扫描唯一一份副本。

这句话可能会得罪人,但我必须写:很多所谓「图库资料库网站恢复工具」,本质上是在做面向普通用户的文件扫描器,把「能扫出来」包装成「能恢复好」。老周那次,我先让他用 dd 做了整盘镜像,在镜像上跑了三轮测试,才敢动原盘。这一步花了一个半小时,任何榜单都不会写,但它是整个流程里唯一不能省的一步。另外,关于图片文件本身在浏览器端的找回,我此前在 找回49图库图片 里整理过一些临时缓存的抢救方法,适合图不多、但没有本地备份的情况,可以当作一个补充手段。

至于那款我最终没列进主位的国产工具,原因很实在:它的官网域名注册时间是 2025 年 11 月,没有 ICP 备案,安装包没有数字签名,而且它在扫描时会请求读写权限之外的网络权限。功能确实有用,但把这种权限请求和一份三万多张图的私人图库放在一起,风险收益不划算。这是个人判断,我不强求别人同意,但我自己不用。

如果你更关心的是「查询类」图库站点的恢复入口,那又是另一条线。比如 新奥门中特钢49049查询 这类页面里记录的查询接口,主要解决的是条目定位而不是文件恢复,两者别搞混。

本站同类记录

按实测时间倒序 · 共 9 条
旧浏览器版本回退记录 REC · 01

老周那台 ThinkPad 上的 qq 浏览器,从 130 降回 8.9 之后白屏没了

回退过程中的注册表残留、扩展兼容,以及为什么有些老图库站点只认旧渲染内核。

工具记录06-01
云存储导出界面 REC · 02

49tk 图库的缓存型资料库,用云存储导出时踩的四个坑

导出队列卡在 97% 的那次,最后是靠分段导出绕过去的。

教程05-27
REC · 03

找回 49 图库图片:一张缩略图缓存救回了两百多张原图的线索

浏览器缓存目录里那个 40MB 的 cache 文件夹,比很多人想的更有用。

方法05-21
数据查询界面 REC · 04

新奥门中特钢 49049 查询页的条目定位逻辑,其实和文件恢复无关

把查询类恢复和文件级恢复混为一谈,是很多人走弯路的第一步。

辨析05-16
REC · 05

张工那份 2019 年的测绘图库,manifest 用 UTF-16 写坏之后的抢救过程

和这次老周的情况高度相似,但坏的位置不同,处理方式也差很多。

案例05-09
硬盘镜像制作 REC · 06

dd 做整盘镜像时,块大小设成 64K 还是 1M 的真实差别

一块 42,000 小时的老盘上,我测了两遍,结论和论坛里说的不太一样。

实验04-30
REC · 07

PhotoRec 恢复出来的文件时间戳全丢,是因为它在按块读取

写了个 90 行的 Python 脚本,用 EXIF 回填时间戳,附思路不附完整代码。

脚本04-22
机房与索引结构示意 REC · 08

图库索引的三层校验:文件头、EXIF、目录深度,缺一层成功率就掉两成

老周那次的交叉比对思路,拆开讲一遍,可以照着套。

方法04-14
REC · 09

一款无备案的恢复工具,功能有用但我没推荐它的三个理由

权限请求、数字签名、域名注册时间,这三条我写得很具体。

判断04-06
今天看到的一句话
「恢复这件事,成功率和你的耐心成反比,和你的备份成正比。」
—— 《数字档案抢救笔记》第三版,第 118 页,2021 年,档案出版社