48小时救援记录：TestDisk 分区恢复与 PhotoRec 文件找回实战手记
【免费下载链接】testdiskTestDisk & PhotoRec项目地址: https://gitcode.com/gh_mirrors/te/testdisk
一次相机存储卡失灵，让我把 TestDisk 与 PhotoRec 从"听说过"变成了"离不开"。这是一篇按时间线记录的实战手记：前 6 小时怎么用 TestDisk 做分区恢复，第 20 小时怎么靠 PhotoRec 做文件找回，以及事后总结出的五条教训。适合正在经历数据丢失、且想自己动手解决问题的普通用户。
事故档案：分区表坏了，数据并没有消失
事情发生得很普通。周末整理照片，把 SD 卡从相机里抽出来插进读卡器，系统弹出提示："此卷不包含可识别的文件系统"。再看一眼资源管理器，卡还在，容量还在，但里面空空如也。相机开机也提示"请格式化存储卡"。
那一刻心跳漏了一拍。几百张原图，没有备份。
这里要先解释一个关键概念：分区表损坏，不等于数据消失。分区表可以理解成一本书的目录页——它记录着"第几章在第几页"。目录页被撕掉、被写乱，书页本身还好好地躺在那里，只是你找不到入口了。SD 卡的分区表坏了，系统自然"看不见"里面的文件，但照片数据大概率还在扇区里躺着。
这正是一个典型场景：分区表损坏修复，属于 TestDisk 的主场。
黄金第一步：动手前的"现场保护"
在开始任何修复之前，先做一件事：停止写入。不要格式化（格式化等于把目录页撕掉再重新印刷）、不要新建文件、不要用系统自带的"修复"功能反复读写。每一次写入，都可能把原本还有机会找回的数据覆盖掉。
如果你的设备还勉强能识别，建议先做一份磁盘镜像，之后的恢复操作都在镜像上进行。Linux 下一条命令即可：
dd if=/dev/sdb of=/tmp/sdcard.img bs=4M status=progress把/dev/sdb换成你的设备名，dd会按扇区把整张卡原样复制成镜像文件。这一步是"磁盘镜像数据恢复"的常规操作——恢复过程本身是只读的，但多一层镜像保护，等于给自己留了后悔药。
到这一步，工具还没上场。先认识一下它们：TestDisk 与 PhotoRec 是同一套开源套件中的两个程序，遵循 GPL 许可，完全免费，覆盖 Windows、Linux、macOS、BSD 等主流平台。TestDisk 负责"修目录页"（分区表、引导扇区、文件系统结构），PhotoRec 负责"在书页里逐行找文字"（文件内容级扫描）。
第6小时：TestDisk 分区恢复，把目录页重新拼出来
镜像做好的当晚，我开始用 TestDisk。它的界面是文本风格的，没有花哨的图形，但每一步都有清晰的提示，新手跟着走完全没问题。核心流程就五步：
- 选择设备：列出所有磁盘，选中 SD 卡或它的镜像文件
- 选择分区表类型：普通 PC 基本选 Intel（MBR），也有 GPT、Mac、Sun 等选项
- 选择 Analyse（分析）：让 TestDisk 扫描磁盘上残留的分区信息
- 执行 Quick Search（快速搜索）：快速定位候选分区，找到后可以浏览里面的文件目录来确认
- 选择 Write（写入）：把找到的正确分区表写回磁盘
我当时的操作命令很简单：
sudo testdisk /dev/sdb十几分钟后，Quick Search 找到了两个分区，其中一个正是照片所在的分区，浏览目录时看到了熟悉的照片文件夹。选择写入、重启读卡器——分区回来了。
这个过程背后是 TestDisk 的看家本事：它不依赖操作系统，而是直接读取磁盘上的原始结构，在分区表被破坏甚至被覆盖后，通过扫描引导扇区、文件系统超级块等残留信息，重建出分区表候选列表，再由你确认哪个是正确的。
值得多说一句：TestDisk 不只是修分区表。它还支持修复引导扇区、重建 FAT/NTFS 的引导记录、把丢失的引导程序写回系统盘。常见的"开机显示 Missing operating system"这类启动问题，很多时候就是它修好的。它支持 FAT、NTFS、ext2/3/4、HFS+、JFS、XFS 等 20 多种文件系统，覆盖面相当广。
第20小时：PhotoRec 文件恢复，逐扇区找"指纹"
分区回来了，但事情没完。打开照片文件夹，发现最近一次旅行拍的照片缺了将近三分之一——那部分文件正好落在被覆盖过的区域，目录项损坏了，系统认不出来。
这就轮到第二个工具上场。PhotoRec 文件恢复的思路和 TestDisk 完全不同：它完全无视文件系统，直接对磁盘或镜像做逐扇区扫描，靠文件签名（每种格式开头固定的字节序列）来识别和切割文件。这种技术叫 file carving（文件雕刻），即使整个分区表都丢了，它照样能干活。
sudo photorec /dev/sdb1运行后依次选择要扫描的分区、文件类型（默认全选）、以及恢复文件的保存目录——记住，保存位置必须和源盘不是同一个物理设备。
常见文件签名长这样，这就是 PhotoRec 的"识别指纹"：
| 文件类型 | 十六进制签名 | 说明 |
|---|---|---|
| JPEG 图片 | FF D8 FF | 每张 JPEG 的开头标志 |
| PNG 图片 | 89 50 4E 47 | PNG 的标准文件头 |
| PDF 文档 | 25 50 44 46 | 即 ASCII 的%PDF |
| ZIP 压缩包 | 50 4B 03 04 | ZIP 家族通用文件头 |
扫描持续了大概三个小时。结束后，恢复目录里按扩展名分好了文件夹，jpg/、raw/、mov/各归其位。那次运气不错，找回的 200 多张照片里绝大多数能正常打开。整个项目支持480 多种文件扩展名、约 300 个文件家族，从 JPEG、PNG 到 Office 文档、邮件、数据库文件都有覆盖。如果你更习惯图形界面，套件里还带了 QPhotoRec（基于 Qt 的版本），同样的功能，点鼠标就能操作。
收尾：校验结果，以及"不完美"的真相
恢复不等于验收。PhotoRec 找回的文件文件名是随机重编的，因为原始文件名信息可能已不存在；而且某些文件因为头部或尾部被覆盖，会打不开。我的做法是把能打开的挑出来按内容重新命名归档，打不开的单独放一个目录，防止混进正常文件里造成混乱。
也请对成功率有合理预期。以下情况恢复希望渺茫：
- 数据已被覆盖：新文件写在了老数据的位置上，神仙难救
- SSD 执行过 TRIM：固态硬盘会主动清空被删数据所在的块，签名也没得扫
- 存在物理坏道：扇区读不出来，恢复工具也无能为力
- 反复格式化：每次格式化都是一次新写入
所以"尽快行动"永远是第一原则。另外，优先在镜像上操作，既是保护现场，也是给自己留退路——这也是前面强调 dd 镜像的原因。
事故复盘：五条写成清单的教训
这次 48 小时的经验，最终沉淀成五条，每一条都对应着一次真实的踩坑：
- 备份要主动，别等事故教育你。恢复是补救，备份才是成本最低的方案
- 发现问题后立刻停止写入，这是性价比最高的"抢救动作"
- 先镜像、后操作，所有扫描和修复都在副本上进行
- 别用不同软件反复扫描同一块盘，每扫一遍都是风险，先想清楚再用哪个
- 恢复文件保存到另一块物理磁盘，写回原盘等于二次伤害
新手常见疑问速答
TestDisk 和 PhotoRec 会往被恢复的盘里写东西吗？不会。扫描和读取都是只读操作；只有你在 TestDisk 里明确选择 Write 时才会写回分区表，PhotoRec 则完全不写源盘。
两个工具必须一起用吗？不一定。分区丢了、盘不识别，优先 TestDisk；只是误删文件、文件系统还正常，直接 PhotoRec 就行。两者互补，但可以按需取用。
免费开源意味着不安全吗？恰恰相反，GPL 协议下源码完全公开，恢复逻辑可以被任何人审计。这也是它在取证行业被长期使用的原因之一。
为什么有的文件恢复了却打不开？文件签名找到了开头，但中间或结尾被覆盖、或存得零散，就会得到残缺文件。这类文件单独存放，别删，等以后有更好的镜像再试。
资源与延伸阅读
如果你想把工具装到自己电脑上，最直接的方式是从源码编译。克隆项目并完成构建：
git clone https://gitcode.com/gh_mirrors/te/testdisk cd testdisk ./autogen.sh ./configure make sudo make install依赖方面，核心是需要 libncurses（文本界面），其余如 jpeg、ewf、Qt 库都是可选的增强项，详细说明写在项目根目录的INSTALL文件里。
想深入了解实现，可以看src/目录：testdisk.c和photorec.c是两个主程序入口，filegen.c是文件签名识别框架，剩下三百多个file_*.c文件分别对应一种格式的识别逻辑，很值得翻一翻。
最后说回这次事故的结尾：照片找回来了，但我也明白了一件事——TestDisk 与 PhotoRec 是可靠的后备方案，却永远不该替代备份本身。如果你正握着那块"坏掉"的存储设备，别慌，先停止写入，按这篇文章的顺序从镜像做起；如果一切顺利，你会在恢复完成的那一刻，感激自己没有在最慌乱的时候按下格式化按钮。
【免费下载链接】testdiskTestDisk & PhotoRec项目地址: https://gitcode.com/gh_mirrors/te/testdisk
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
