简介这是一份完整的开源数据恢复软件源码包面向数据恢复开发者、安全研究人员及希望深入学习底层恢复机制的进阶用户。资源聚焦误删恢复、分区修复、坏道读取等场景清晰展示了存储介质扫描、文件系统分析、数据预览与安全恢复的完整流程。压缩包共516个文件以364个C源文件和145个头文件为主体辅以少量C、RC资源文件及Makefile.am等工程构建文件整包仅4.42MB结构紧凑。已有1524人学习下载。源码按功能模块划分覆盖FAT、NTFS等文件系统解析支持常见图片与文档类型的特征识别开发者可基于现有代码快速构建定制化恢复工具也可修改扫描算法、增加文件签名或优化I/O逻辑以提升恢复效率。整体适合数据恢复原理研究、二次开发及高校信息安全教学使用。1. 开源数据恢复软件不是玄学它解决的是分区表、文件系统和扇区这三件事某开发者的典型求助场景是这样的误删了一个项目目录找商业恢复软件全盘扫了一夜拿回来 3000 多个数字命名的文件一半打不开。工具没做错错在恢复策略。开源数据恢复软件的核心能力可以拆成三条线分区表恢复、文件系统元数据恢复、原始扇区特征码恢复对应 TestDisk、extundelete、PhotoRec 这类工具链。先把三条线搞清楚才知道误删后第一分钟该跑哪条命令而不是赌一把全盘扫描。下面从原理讲到命令删除到底发生了什么、哪些数据理论上能找回、恢复前为什么必须先做镜像然后给 TestDisk、PhotoRec、extundelete 的可照做步骤最后是一份避坑清单。适合两类人读自己误删过文件、想低成本自救的开发者和运维要给同事救急、但不想碰来路不明破解工具的人。开源工具大部分是命令行ssh 到服务器就能操作这是它在生产环境最大的价值。2. 先搞懂删除与覆盖三种恢复路线决定你该选哪个开源工具恢复能不能成一半取决于删除之后这块盘又被写入了多少数据另一半取决于你有没有选对恢复路线。这一章先把底层逻辑讲清楚后面给命令的时候你才知道每个参数在为什么服务。2.1 删除只是改标记ext4 的目录项、NTFS 的 MFT 与 FAT 的 0xE5绝大多数文件系统把删除实现成标记失效而不是擦除数据。ext4 里一个文件由三部分组成父目录里的目录项dentry、inode 和数据块。执行 rm 时内核做的只是把目录项标记为删除、清掉 inode 位图里对应的位再把数据块释放回空闲列表。数据块里的内容原样躺在那里直到将来被新文件覆盖。这也是恢复窗口的由来删除瞬间没有抹掉任何东西真正抹掉数据的是后续写入。NTFS 的机制类似每个文件在 $MFT 里有一条记录删除时把这条记录标记为未使用同时清掉 $Bitmap 中对应簇的占用位。文件内容仍然留在原来的簇里。FAT/exFAT 则更原始删除时只把目录项首字节改成 0xE5 表示废弃。麻烦的是 FAT 没有 inode文件的簇链信息也随目录项一起失效碎片化文件的恢复难度明显高于 ext4 和 NTFS。由此得到一个关键推论误删之后立刻停止一切写入。系统日志、临时文件、浏览器缓存、甚至把恢复软件装到同一块盘上都会压缩恢复窗口。SSD 还要额外注意 TRIM支持 TRIM 的固态盘在删除后由固件主动擦除物理块元数据没了数据也没了任何工具都救不回来。遇到这种场景问题不在工具而在盘本身。2.2 三条恢复路线元数据、分区表、特征码分别解决什么问题第一条路线是文件系统元数据恢复。原理是解析残留的目录项、inode 和日志journal重建被删除文件的名称、大小和磁盘位置。代表工具是 extundelete、ext4magicext4和 ntfsundeleteNTFS。优点是保留文件名和目录结构恢复速度快文件完整度高缺点是极度依赖元数据没有被覆盖一旦做过格式化或分区重建就基本失效。第二条路线是分区表与超级块恢复。分区表MBR 或 GPT记录每个分区的起始与结束位置误删分区、误转分区表格式、引导扇区损坏都会让整块盘变成未分配空间。TestDisk 通过扫描疑似引导扇区、超级块来重新勾画分区边界分区回来了里面的文件自然可见。它恢复的是分区的可见性不改动文件系统内部结构。第三条路线是特征码雕刻carving。它不依赖文件系统直接逐扇区扫描已知文件类型的特征字节比如 JPEG 以 FF D8 FF 开头、PDF 以 %PDF 开头、PNG 有固定文件头。代表工具是 PhotoRec、foremost、scalpel。优点是文件系统全毁、格式化重装之后依然有效缺点同样明显文件名和目录结构全部丢失文件碎片化时只能拿到片段恢复结果需要大量人工甄别。恢复路线依赖什么是否保留文件名/结构适用场景典型工具元数据恢复目录项、inode、日志未被覆盖保留误删后写入少文件系统还能识别extundelete、ext4magic、ntfsundelete分区表恢复分区边界信息可被扫描识别保留误删分区、误格式化未覆写TestDisk特征码雕刻文件类型特征齐全、文件未碎片化不保留文件系统全毁、格式化重装PhotoRec、foremost2.3 开源工具选型与边界一张表选对第一个命令拿到一台需要恢复的机器我一般会先问三个问题分区表还在吗文件系统还能挂载吗删除之后往这块盘写过多少东西三个答案基本决定走哪条路线。下面这张表可以当作第一命令的选型依据。现场情况首选工具理由磁盘变成未分配空间TestDisk找回分区等于找回文件ext4 分区误删少量文件extundelete、ext4magic保留路径和文件名速度最快NTFS 误删TestDisk 的 Undelete、ntfsundeleteMFT 未被覆盖时命中率高文件系统已被格式化PhotoRec不依赖文件系统结构坏道严重先 ddrescue 镜像再进上述流程先保住数据再谈恢复U 盘/SD 卡 FAT 误删PhotoRecFAT 删除后簇链信息难以复原这些工具以 CLI 和 TUI 为主许可证基本是 GPL 系可以脚本化也能通过远程会话操作没有图形界面依赖。但开源不等于万能TRIM 过的 SSD、被覆盖写入的区域、加密文件系统基本都属于不可恢复范畴特征码恢复对加密容器也无效因为加密会把文件特征彻底抹平。选型阶段把边界认清能省下大量无意义的扫描时间。3. 镜像先行用 ddrescue 给故障盘做只读备份这是恢复流程的地基恢复这条路上有一条血泪经验排在第一位不要在原始盘上反复折腾。ddrescue 不直接找回文件但它是整个恢复流程的地基先把数据从危险盘里抢出来后面所有工具才有反复试错的资格。3.1 为什么先镜像坏盘每多读一秒成功率就往下掉误删场景不一定有坏道但很多求助是误删加机器摔过或拷数据到一半盘不识别的混合故障。对这类盘直接在原盘上跑恢复工具等于让磁头反复读坏道区域可能把原本还能读的扇区也带坏。镜像的含义是按扇区把整块盘复制成一个映像文件之后所有扫描、重试、误操作都发生在镜像上原盘封存不再碰。这就是恢复流程里的后悔药试错成本几乎归零。动手前先看一眼盘的健康状态用 smartctl 读 SMART 信息sudo smartctl -a /dev/sdb重点看两个字段Reallocated_Sector_Ct已重映射的坏扇区数和 Current_Pending_Sector待重试扇区数。pending 数量持续上涨说明盘在恶化更要优先镜像。镜像目标放在另一块物理盘或网络存储上目标空间不小于源盘容量。如果源盘比目标盘大ddrescue 会在日志里反复报错所以先确认容量再开始。3.2 ddrescue 最小命令与两遍策略-d、-n、-r 怎么配合ddrescue 一次接受三个参数源设备、镜像文件、日志文件。日志是核心它记录每个块的读取结果断点续传全靠它。常见做法是跑两遍第一遍快速把好数据抢走第二遍只针对坏块区慢慢重试。# 第一遍快速拷贝跳过坏块不进入慢速擦刮阶段 sudo ddrescue -d -n /dev/sdb /recovery/disk.img /recovery/disk.log # 第二遍针对日志里标记的坏块区重试最多重试 3 次 sudo ddrescue -d -r 3 /dev/sdb /recovery/disk.img /recovery/disk.log参数说明-d 是 direct I/O绕过操作系统页缓存避免缓存掩盖真实的读取状态也防止大量坏块读操作把内存拖垮-n 是 no-scrape第一遍只做快速拷贝遇到读不通的块先跳过目标是尽快把好数据读走不在坏道上恋战-r 3 表示对每个坏块最多重试 3 次重试非常耗时而且磁头状态不好时反复重试可能让情况更差所以放在第二遍做。两条命令的镜像和日志路径必须完全一致ddrescue 靠日志续传日志丢了等于之前的工作全部作废。注意源设备要写整块盘 /dev/sdb而不是 /dev/sdb1。要恢复的分区表和未分配空间都在整盘层面只镜像分区会漏掉关键区域。如果目标盘空间紧张可以加 --sparse 生成稀疏文件但目标文件系统必须支持稀疏文件ext4 和 xfs 没问题FAT/NTFS 不支持。镜像过程中随时可以按 CtrlC 中断之后重跑同一条命令即可续传。3.3 镜像状态解读与只读校验ddrescue 运行界面会显示当前进度、已恢复比例和 current status状态有 running、rescuing、finished 几种。日志文件是纯文本用 cat 直接看每行对应一个块区间行尾的状态字符含义固定 表示该块已成功读出* 表示坏块/ 表示部分可读? 表示未尝试。扫一眼日志就能看出坏块集中在盘的哪个区间也可以据此判断第二遍重试的优先级。镜像完成后把镜像挂成回环设备做只读校验# -P 参数让内核解析镜像内的分区结构 sudo losetup -P /dev/loop0 /recovery/disk.img # 对第一个分区做只读文件系统检查-n 保证不写盘 sudo fsck -n /dev/loop0p1 # 校验完卸载回环设备 sudo losetup -d /dev/loop0如果镜像只包含一个文件系统的裸数据比如直接 dd 了某个分区那么 fsck 对象就是 /dev/loop0 而不是 /dev/loop0p1。fsck -n 只读检查不会写入任何修复。检查通过后后续的 TestDisk、PhotoRec、extundelete 全部指向 /dev/loop0 系列设备原盘不再碰。到这一步从镜像上恢复的闭环就成立了。4. 从镜像上恢复数据TestDisk 重建分区、PhotoRec 特征码扫描、extundelete 定向找回镜像做完进入真正找回文件的环节。这一章按场景给三条可操作路径分区表没了走 TestDisk文件系统毁了走 PhotoRecext4 误删少量文件走 extundelete 或 ext4magic。每条路径都给出命令和菜单操作要点。4.1 TestDisk 重建分区表的完整流程与写回时机适用场景很明确分区被误删、分区表格式被误转、磁盘管理工具里显示未分配空间。分区表记录的是分区的边界边界信息还在磁盘上残留着TestDisk 就能把它扫出来。sudo testdisk /dev/loop0交互流程按顺序走日志选项直接选 Create new log 或跳过选择磁盘时确认容量对得上分区表类型按实际选MBR 选 IntelGPT 选 EFI GPT进入 Analyse 后先跑 Quick Search扫到分区按 P 预览文件列表。预览能看见文件说明分区边界正确看不见就退回跑 Deeper Search 深度搜索。确认无误后选择 Write 写回分区表。写回时机是新手最容易纠结的地方。记住一条原则先用 P 预览确认文件可见再考虑写回写之前 TestDisk 会提示备份当前损坏的分区表一定要备份写完后只读挂载验证一次不对就恢复备份重新来。Deeper Search 很慢但对误格式化场景命中率高值得等。常见误用是拿 TestDisk 去恢复 ext4 误删的单个文件——它能做 NTFS 的 undelete但 ext4 场景效率远不如 extundelete别把工具用错地方。4.2 PhotoRec 特征码恢复不依赖文件系统的保底手段当文件系统被格式化、分区表彻底丢失、或者元数据恢复完全失败时PhotoRec 是最后的保底。它不读目录只按文件特征码逐扇区扫描。sudo photorec /dev/loop0菜单要点第一个菜单选择目标分区或直接选 Whole 整盘扫描整盘慢但遗漏少进入 File Opt 勾选要恢复的文件类型默认全选如果只想找图片和文档只留对应类型可以快很多输出目录必须选在另一块盘上这是原则确认后开始扫描进度按扇区显示可中断再次运行可续扫。恢复结果会落在输出目录下的 recup_dir.1、recup_dir.2 等子目录里文件按类型分名字是纯数字。先用 file 命令批量确认类型和完整性再做筛选。特征码恢复对碎片化文件只能拿到第一个连续片段大视频、数据库文件尤其明显这属于雕刻技术的固有限制不是工具坏了。脚本化场景可以先看 photorec --help 确认参数但第一次用建议交互式跑一遍把菜单层级记住后面才不容易慌。4.3 extundelete 与 ext4magicext4 定向恢复的两个常用工具如果分区还能被文件系统识别只是误删了几个文件或目录优先走元数据恢复。extundelete 是这条路线上最常用的工具。# 恢复单个文件路径是文件系统内的相对路径不带前导斜杠 sudo extundelete /dev/sdb1 --restore-file home/user/project/config.yaml # 恢复整个目录 sudo extundelete /dev/sdb1 --restore-directory home/user/project # 恢复所有已删除且未被覆盖的文件 sudo extundelete /dev/sdb1 --restore-all运行前提是分区已经卸载或者以只读方式挂载任何写操作都会污染恢复现场。输出在当前目录下的 RECOVERED_FILES/ 里保持原相对路径。一个常见报错是 ext4 开启了 64bit 或 flex_bg 特性时extundelete 解析会失败这种情况换 ext4magic。ext4magic 的常见用法是sudo ext4magic /dev/sdb1 -r -d /recovery/out-r 表示恢复已删除文件-d 指定输出目录配合 -a 和 -b 按删除时间区间过滤可以减少误恢复具体参数以 --help 为准。ext4magic 更依赖 jbd2 日志删除时间不长、日志没有被轮转覆盖时成功率通常比 extundelete 高。删除后写入越多命中率越低看到 File not found 之类的提示多半是 inode 已经被重新分配抓紧时间换路线。5. 避坑清单开源数据恢复最容易翻车的五个操作这一章是踩坑记录五个场景都是我见过最多的翻车现场每一条按现象、原因、解决三步写清楚。5.1 恢复文件写回原盘二次覆盖现象恢复时把输出目录选在源盘同一个分区第一轮恢复完再扫第二轮发现可恢复文件更少之前恢复出来的部分文件也打不开了。原因删除后的块被文件系统视为空闲恢复输出写回时系统直接把这些空闲块分配出去正好覆盖了待恢复数据。解决输出目录永远放另一块物理盘。只有一块盘时先做镜像恢复从镜像读、往第三位置写。没有第二块盘之前不要开始任何恢复操作。5.2 拿到坏盘直接扫描不看 SMART现象不检查健康度直接挂载跑全盘扫描进度卡在某个扇区几个小时盘体咔哒响最后系统直接掉盘。原因恢复工具对每个坏块都会反复重试磁头在坏道区间来回寻道会加速盘体恶化把原本能读的相邻扇区也带坏。解决先跑 smartctl 看 Reallocated_Sector_Ct 和 Current_Pending_Sector数值高就先按第 3 章做 ddrescue 镜像第一遍 -n 跳过坏块第二遍再小范围重试。镜像过程中发现 pending 数量上涨立即停止断电封存。5.3 恢复中途断电或误中断元数据二次损坏现象镜像跑到半夜停电或者在原盘上直接跑恢复嫌进度慢按了 CtrlC。重启后分区挂不上报 superblock 错误。原因中断落在一个写动作中间文件系统处于不一致状态。原盘本来就是受伤状态再被写一次就彻底脏了。解决长时间任务一律放 tmux 或 screen 里跑输出重定向到日志文件。操作对象永远是镜像或 loop 设备不是原盘。中断之后先 fsck -n 检查再决定下一步不要直接上 -y。5.4 特征码恢复后拿到一堆数字文件名和半截文件现象PhotoRec 跑完几千个数字命名的 jpg 和 pdf目录结构全无关键的大视频文件只有开头几百 KB打开就报错。原因雕刻只认文件头尾特征不解析文件系统目录。文件在磁盘上碎片化存放时只能恢复出第一个连续片段后续片段没有索引可循。解决需要保留文件名和目录结构的场景优先走元数据恢复雕刻作为最后的保底手段。恢复大文件前先恢复一个小样本用 file 看大小分布心里有底再决定要不要跑完整盘。5.5 上来就跑 fsck -y 修一下把恢复痕迹清没了现象开机提示文件系统错误顺手执行了 fsck -y系统恢复正常几天后想找回之前误删的文件什么都搜不到。原因fsck 会重放日志、重建位图和目录项把删除标记当成错误纠正掉。而删除标记恰恰是元数据恢复的核心线索修完等于线索被清空。解决恢复完成之前任何检查都用 fsck -n 只读模式。确实需要修复时在镜像上修修完另存一份再做恢复实验原盘始终不动。6. 恢复后的验证与演练把恢复流程练成肌肉记忆6.1 用演练盘把流程走一遍找一块闲置 U 盘或临时虚拟磁盘格成 ext4拷入照片、PDF、压缩包各几个先记录哈希再删除然后按镜像、选路线、恢复、校验的完整顺序走一遍。目的是熟悉 TestDisk 的菜单层级和 PhotoRec 的选项含义。真到数据丢失那一刻人都是慌的演练过至少知道下一步该按什么。# 删除前记录原始文件哈希 sha256sum data/*.jpg known.sha256 # 恢复后对比哈希命中说明文件完整 sha256sum -c known.sha2566.2 批量校验恢复结果file、pdfinfo、sha256sumPhotoRec 的输出是数字命名文件先按类型过滤再抽查完整性。file recup_dir.1/* | head -50 # 文档类看能否解析 pdfinfo recup_dir.1/0001.pdf 2/dev/null | head -10 # 压缩包测完整性 unzip -t recup_dir.1/0002.zip 21 | tail -5图片可以用 ImageMagick 的 identify 检查尺寸压缩包用 unzip -t 或 gzip -t 验证。校验通过的文件才值得保留按类型归一下目录比人工翻快得多。我现在的习惯是接到任何误删求助第一句话永远是盘拔了没有第二句是有没有镜像。顺序对了大多数场景都能找回一部分顺序错了神仙工具也救不回来。这些命令希望你永远用不上但真到那天至少不会在慌乱中把盘越弄越糟。希望帮到你。本文还有配套的精品资源点击获取