简介开源数据恢复软件资源包面向因误删、格式化、分区损坏或硬盘故障而丢失数据的用户与开发者提供一套可自行编译、修改的恢复工具源码。该包共516个文件以364个C源文件、145个头文件为主辅以少量CPP、RC资源配置及Makefile工程文件压缩后约4.42MB适合有一定C语言基础的人员学习底层磁盘扫描、文件系统解析FAT/NTFS与恢复流程。资源涵盖文件误删找回、分区表修复、坏道读取、系统崩溃后数据抢救等典型场景源码按功能模块划分便于按需裁剪或扩展文件类型支持。已有1524人学习下载。通过阅读源码可掌握数据恢复软件从扫描、分析、预览到恢复的完整实现思路理解FAT与NTFS簇链等底层机制并能够针对特定存储介质优化算法、增加自定义恢复规则是一份兼顾理论与实践的开源学习材料。1. 数据恢复这行当先明白它是门底层手艺不是碰运气很多人在存储设备出问题后的第一个动作是找个“抢眼”的收费软件扫一遍然后盯着进度条祈祷。我做了多年的数据和存储运维第一次用开源工具完整救回一块被误格式化的盘时才意识到一个反直觉的事实——数据恢复本质上是一场底层的逆向定位文件没被真正抹掉只是系统把索引标记成了“可覆盖”恢复工具是在文件系统层和块层之间把那些还没被新数据占用的残留结构找出来。开源方案的恢复能力并不比商业软件弱区别在于它要你自己读文档、理解参数、承担操作风险。这篇笔记适合运维、开发者和被误删文件困扰的个人用户帮你看清开源数据恢复的边界并把它用出稳定的成功率。2. 开源恢复工具选型先分清场景再决定用哪把刀数据恢复失败案例里绝大多数不是因为工具不行而是用错了场景。一个在 Windows 下误删了 NTFS 分区的文件拿 extundelete 去扫当然什么都扫不出来一块已经出现物理坏道的硬盘直接跑深度扫描结果往往是扫描卡死盘面损伤进一步扩大。开源生态里的恢复工具各有各的“主场”选型这一步走对后续基本就是按流程执行。2.1 三层恢复模型文件系统层、签名层和块层我把数据恢复分为三个层级选工具前先要判断数据问题发生在哪一层。文件系统层恢复依赖文件系统自己的元数据。像 ext3/ext4 删除文件时只清掉了目录项和 inode 的链接计数数据块本身还在。只要 inode 没被复用extundelete 就能把这些文件“捡回来”。这一层恢复速度最快几 GB 的分区往往几分钟就扫完但前提是文件系统结构本身没有被破坏。签名层恢复不依赖文件系统而是直接在未分配空间里按文件头特征去找数据。photorec 就干这个它内置了两三百种常见文件的魔数签名比如 JPEG 的FF D8 FF、PDF 的%PDF扫到签名就按预设的尾部规则切出文件。这一层能处理格式化、分区重建、甚至文件系统完全损毁的情况但恢复出来的文件名会变成f1234567.jpg这种编号目录结构也没了。块层指 ddrescue 这类工具做的整盘镜像。它不关心文件系统只做扇区级复制专门对付坏道和物理损伤介质。这三层不是互斥的通常块层镜像是第一步镜像做完之后再到镜像文件上做文件系统层或签名层恢复。2.2 工具选型对照表不同故障对应不同方案下面这张表是我处理过的典型场景和对应的工具组合可以作为选型时的参考。注意同一款工具在不同场景下的效果差异很大不要指望一个工具通吃。故障现象底层原因首选工具备选或补充单个文件误删分区仍在目录项和 inode 链接被清除extundeleteext 系列 / testdisk 的 undeleteFAT/NTFSphotorec 按签名捞格式化后想找回文件新文件系统覆盖了旧元数据数据块可能还在photorec 深度扫描testdisk 尝试找回原分区表分区丢失、分区表损坏MBR/GPT 结构损坏分区起始位置丢失testdisk 的 analyze 和 rebuild先 ddrescue 镜像再分析坏道、异响、S.M.A.R.T 异常介质物理损伤反复读写会扩大损伤ddrescue 镜像再做后续恢复强烈不建议直接扫原盘整盘被重新分区并写入了部分数据分区表和部分数据被覆盖testdisk 找回原分区布局 photorec 兜底取决于覆盖了多少新数据2.3 参数差异为什么同一套命令在不同工具里结果不同很多新手在 extundelete 里看到一个--restore-all就以为能通吃结果在 NTFS 分区上执行直接报错。原因是 extundelete 只认识 ext3/ext4 的 inode 结构。它没有数据签名概念所有恢复都靠 inode 里的指针去找数据块位置。一旦格式化把 inode 表清零extundelete 就会告诉你“no deleted inodes found”这时候它不是坏了而是它的设计根本不处理这种情况。photorec 则完全反过来它从头到尾不读 inode只按扇区扫描签名。好处是兼容上百种文件系统坏处是恢复出的文件没名字、没路径、碎片文件会丢失。它的wholespace选项可以控制是否扫描整个磁盘的未使用空间选whole会更慢但要全得多选free只扫空闲空间速度快但有可能漏掉已经带病解析的分区里的文件。ddrescue 的参数就更微妙了它的执行次数、日志文件、反向填充模式都会影响最终镜像的质量。后面实战部分我会细讲这里先记住一句话镜像阶段宁可慢不要急坏道盘的所有操作都必须以最小化磁头回退为原则。3. 实战流程从 ddrescue 镜像到 photorec 与 testdisk 的完整操作这一章是整套流程的核心。数据恢复界有个不成文的规矩在源盘上做一切操作都是在增加风险。正确姿势是先用 ddrescue 把整盘做成镜像之后所有恢复动作都在镜像文件上进行。这样即使恢复过程出现误操作源盘仍然保持原样永远有后悔药可吃。3.1 第一步用 ddrescue 做块级镜像假设系统里现在有两块盘/dev/sdb是待恢复的问题盘/dev/sdc是一块空盘。先把 sdc 分区并格式化然后挂载到/mnt/recovery。# 查看当前磁盘状态确认盘符映射 lsblk -o NAME,SIZE,MODEL,SERIAL # 创建镜像文件注意不要放在源盘上 mkdir -p /mnt/recovery # 执行块级镜像生成镜像文件和日志文件 ddrescue -d -r 3 /dev/sdb /mnt/recovery/disk.img /mnt/recovery/disk.log第一条lsblk是操作前必做的确认动作防止把好盘当成问题盘来镜像。第二条ddrescue的参数含义我需要解释一下。-d表示直接读取设备跳过系统缓存这样能拿到更真实的物理状态-r 3表示每个坏块区域最多重试 3 次避免在坏死区域上无限等待/mnt/recovery/disk.img是镜像输出文件/mnt/recovery/disk.log是断点日志这个日志文件必须保留如果镜像中途中断再次执行同一条命令时会自动跳过已完成的部分继续跑。镜像完成后检查日志的末尾统计重点关注rescued和non-tried两个数值。rescued是成功读出的数据量non-tried应该为 0如果还有大量non-tried说明镜像没有跑完需要再次执行同一条命令。这一步很多人会忽略以为 ddrescue 执行完就是完整镜像实际上对于坏道盘第一次扫描会漏掉许多区域必须重复执行直到non-tried归零。3.2 第二步在镜像上跑 extundelete 恢复误删文件镜像做完之后如果问题盘是 ext4 文件系统且只是误删文件可以直接在镜像上尝试 extundelete。注意 extundelete 需要识别镜像里的文件系统直接把镜像文件当块设备用即可。# 先用 losetup 把镜像挂为 loop 设备 losetup /dev/loop0 /mnt/recovery/disk.img # 查看文件系统状态确认分区偏移 fdisk -l /dev/loop0 # 如果镜像里有分区表需要按偏移挂载 loop 设备 losetup -o $((512*2048)) /dev/loop1 /mnt/recovery/disk.img # 执行恢复全部删除文件恢复到指定目录 extundelete /dev/loop1 --restore-all --output-dir /mnt/recovery/restored这里有三个关键点。第一losetup的-o参数指定分区偏移2048 扇区通常对应 1MiB 对齐的 ext4 分区起点但如果原来的分区布局不同这个值要根据fdisk -l的实际输出来改不能照抄。第二--restore-all恢复所有被删除的 inode如果你只想恢复某一个文件用--restore-file 路径名会更精准也更快。第三--output-dir指定输出目录这个目录必须和镜像不在同一块物理盘上否则恢复出的新文件可能覆盖掉还没恢复的旧数据。extundelete 的速度非常快因为它是按 inode 定位数据块的不需要全盘扫描。如果执行后提示没有找到已删除的 inode说明格式化过程中已经清掉了 inode 表这就得换 photorec 上签名扫描了。3.3 第三步用 photorec 做签名级深度恢复photorec 是 testdisk 工具包里的姊妹程序它的交互界面是字符菜单模式。直接在镜像文件上运行是最安全的做法。# 运行 photorec指定操作镜像文件而非物理盘 photorec /mnt/recovery/disk.img # 交互操作序列 # 1. 选择要分析的介质选中镜像文件 # 2. 选择分区类型通常选 IntelMBR或 EFI GPT # 3. 选择文件系统类型如果识别不准确就选 Other # 4. 选择扫描范围Whole整个镜像或 Free仅空闲空间 # 5. 选择恢复文件输出目录 # 6. 确认后开始扫描等待完成photorec 的扫描时间受镜像大小和文件数量影响几十 GB 的盘扫几个小时是常态。扫描过程中不要中断因为恢复进度不会保存中断就得重新来。输出目录的选择同样遵循独立物理盘原则。恢复完成后输出目录里会是一堆f1234567.jpg样式的文件按扩展名分类放在子目录里。这一步的验证很重要用file命令抽查几个文件确认头部签名和扩展名一致。# 抽查恢复文件的真实性 file /mnt/recovery/restored/*.jpg | head -20 # 统计各类文件的恢复数量 find /mnt/recovery/restored -type f | sed s/.*\.// | sort | uniq -c | sort -rnfile命令读取文件头部特征如果它输出JPEG image data而扩展名是.jpg基本可以确认文件完整。如果输出data说明这个文件只是扫到半个签名或者尾部被截断属于不完整恢复可以优先排查这一类。统计扩展名数量这一步能帮你快速判断恢复结果覆盖了哪些类型决定下一步是先修复还是先筛选。3.4 第四步用 testdisk 找回丢失分区如果问题不是删文件而是整个分区消失、系统提示未格式化这时候 testdisk 是首选。它通过扫描分区表附近的引导扇区和文件系统备份来找回原始分区布局。# 直接对镜像文件运行 testdisk testdisk /mnt/recovery/disk.img # 交互操作序列 # 1. 选择 Create 创建新日志文件 # 2. 选择介质类型镜像文件会自动识别 # 3. 选择分区表类型Intel / EFI GPT / 其他 # 4. 选择 Analyse 分析当前分区结构 # 5. 用 Quick Search 快速扫描找到疑似分区后按 P 预览 # 6. 预览确认文件列表正确后选择 Write 写回分区表这里有个容易翻车的点testdisk 的 Write 操作会把分区表写回镜像里。如果镜像文件本身是你后续恢复工作的基础写回没有问题但如果将来还要对这个镜像做其他法证分析建议先复制一份镜像再写。预览步骤里的P键可以浏览分区内文件这一步一定要做因为它验证的是分区位置是否正确而不是靠猜。如果 Quick Search 没找到可以用 Deeper Search 做全盘扫描它会遍历每个扇区找引导扇区标志耗时更长但成功率更高。找到的分区可能不止一个testdisk 会列出所有候选你需要根据文件列表内容判断哪一个是正确分区——识别原则是文件列表里能看到你熟悉的目录结构。4. 避坑要点五条血泪排查记录覆盖误操作与边界情况开源数据恢复里真正让数据彻底丢失的往往不是故障本身而是恢复过程中的错误操作。下面这几条是我这些年反复遇到的踩坑记录每条都按现象、原因、解决的顺序拆开方便你对照排查。4.1 恢复目标盘和源盘是同一块物理盘现象photorec 扫描时恢复出的文件不断报错打不开扫描速度越来越慢最后连源盘的原始数据也被破坏。原因输出目录设在源盘的另一分区上photorec 一边从源分区读数据一边往同一块盘的其他分区写文件磁头来回寻道不仅拖慢速度新写入的数据还可能和待恢复的数据块产生物理干扰。解决恢复操作前先确认输出目录不在源盘上。用df查看输出目录的挂载设备与源盘设备号比对不一致才算安全。我常用的检查指令是# 确认源盘和输出目录不在同一设备上 lsblk /dev/sdb df -h /mnt/recovery这两条命令的输出对比一目了然/dev/sdb是源盘/mnt/recovery挂载在/dev/sdc上物理隔离确认后才继续。4.2 坏道盘直接跑 photorec 导致卡死和二次损伤现象硬盘有坏道直接跑 photorec 扫描进度条卡在某个百分比不动硬盘发出规律的“咔哒”声之后整个盘陷入更深的不稳定状态。原因photorec 是逐扇区读取的遇到坏道时硬盘控制器反复重试每次重试都让磁头在坏道附近反复定位不仅导致进度停滞还可能让相邻的磁道也受损。解决先 ddrescue 镜像再在镜像上跑 photorec。ddrescue 遇到读错误会快速跳过并记录日志不会卡死。如果情况紧急可以用ddrescue -R反向扫描模式从磁盘尾部开始向头部扫这样磁头移动路径更平滑。4.3 extundelete 扫不出任何删除文件现象ext4 分区误删文件后extundelete 提示No deleted inodes found一个文件都恢复不出来。原因文件删除后系统可能立即触发了 journal 日志清理或后台的fstrim操作。如果分区启用了 discard 挂载选项删除操作会直接通知 SSD 擦除数据块inode 和数据块内容都被物理清空任何恢复工具都无能为力。另一种可能是 inode 被新文件复用文件数据已经被覆盖。解决开机第一件事就是用只读方式挂载分区或直接拔盘做镜像任何自动挂载都可能触发日志写入。恢复前用mount -o ro确认挂载状态并在镜像上操作不给系统写数据的机会。如果确认是 trim 导致的这文件基本没救了换 photorec 也只能碰运气。4.4 testdisk 写回分区表后分区里的文件反而全没了现象testdisk 找到原分区Write 写回后重启系统分区存在了但里面文件列表是空的或者文件系统报错。原因可能是找错了分区另一个同样大小、同样类型的旧分区被误写入了。也可能是写回的分区表里的起始扇区与实际数据位置偏移了几个扇区。原分区起始位置在备份引导扇区里记录了精确值但testdisk 的搜索结果是基于特征匹配的候选不一定对应当前数据布局。解决Write 之前一定要按P预览文件列表确认看到的是正确的目录结构再写入。如果已经写错不要急着格式化重新进入 testdisk同样搜索分区这次预览时多注意目录里文件的修改时间与故障发生前的情况做比对。4.5 恢复工具安装在待恢复的盘上现象在系统里装 testdisk 工具包时安装过程提示分区只读或空间不足随后发现原盘系统崩溃恢复无从谈起。原因安装软件会向系统分区写库文件和程序文件如果这个系统分区正是待恢复的分区写入动作可能覆盖了待恢复的数据区域。解决恢复工作必须在独立环境里进行。我一般用一个带 Live 系统的 U 盘启动进入系统后直接操作工具全部从 U 盘加载目标分区只做只读访问。如果手头没有 Live 介质也可以用另一台机器把问题盘挂成从盘但挂载时务必注意不要让它被自动挂载。5. 进阶用法用文件签名定制与恢复日志摆脱黑匣子很多人用 photorec 时把它当黑匣子扫到什么全凭运气。其实 signature 文件本身就是可以定制的日志文件也能指导你验证和补扫。掌握这两项恢复工作就从“碰运气”变成了“确定性操作”。photorec 的签名定义文件位于/usr/share/photorec/file_sig.c里面每一条记录包含文件类型、扩展名、头部签名、尾部签名和偏移量。比如 JPEG 的定义是头部FF D8 FF E0偏移量为 0。你可以在文件末尾追加自定义的类型记录格式为#define FILE_CUSTOM 999 { FILE_CUSTOM, custom, 0, CUSTOM-HEADER-, 0, NULL, 0, NULL, 0 },这条定义告诉 photorec 扫描时寻找以CUSTOM-HEADER-字符串开头的扇区并把后续连续数据恢复为.custom文件偏移量为 0尾部由解析长度决定。追加完成后需要重新编译 photorec。这在处理某个特定软件生成的私有格式文件时很有用——当内置签名列表里没有它默认扫描只能把这些数据当作未知类型丢弃而定制签名能做到定向捞取。恢复日志的问题也常被忽略。photorec 在扫描结束时会生成一个隐藏的photorec.ses会话文件。如果扫描中断下次运行选择Resume可以从中断点继续而不是从头开始。这算是一个后悔药机制RT 场景下能让几小时的扫描不白跑。给恢复工作做验证时我会强制走一遍完整闭环先file抽查每个类型的代表文件再打开几个关键文档确认内容可读最后用journalctl清掉系统里与该盘相关的挂载记录防止下次开机自动挂载造成二次污染。这套动作坚持下来后我的恢复成功率从“看运气”变成了“大概率可预期”。说到底开源恢复工具给的是地基能否盖起楼来取决于你有没有在动手前三分钟确认过选型、镜像和输出目录。希望帮到你。本文还有配套的精品资源点击获取