一、YanMiRestore 是什么？
YanMiRestore 是一个基于 Rust 编写的数据恢复工具，主要面向以下场景：
- 电脑硬盘（HDD / SSD）
- 移动硬盘、U 盘等外接存储
- 手机导出的合法备份 / 镜像文件
它的定位并不是做一个“黑盒式的一键恢复神器”，而是做一个恢复过程清晰、默认安全、可审计追踪的恢复工具。
简单来说，它做的事情是：
- 先生成恢复方案
- 再对源介质进行只读扫描
- 最后按扫描报告决定是否执行恢复
这套流程看似“多了一步”，实际上非常专业。因为数据恢复最怕误操作，而 YanMiRestore 的设计，就是在尽量降低这种风险。
二、它已经实现了哪些能力？
从当前项目说明来看，YanMiRestore 已经具备 5 条可用恢复路径，这意味着它不是只能做“回收站找回”这种浅层恢复，而是已经覆盖了逻辑恢复、元数据恢复和签名雕刻三类常见路径。
1. 回收站 / 垃圾桶逻辑删除恢复
对于已经挂载的目录，YanMiRestore 会扫描常见的逻辑删除目录，例如：
$Recycle.BinRECYCLERRecyclerRECYCLED.Trash.Trashes
这条路径适合那种“刚删除不久，系统还保留逻辑入口”的场景。 优点是恢复快、损坏概率低、能保留更多原始信息。
2. NTFS 删除 MFT 记录扫描
这是比较有技术含量的一块。
YanMiRestore 支持：
- 扫描已删除的 MFT 记录
- 解析
$DATA属性 - 处理常驻 / 非常驻数据
- 解析数据运行列表（run list）
这意味着它不是简单地“找到一条删除痕迹”，而是能够进一步定位文件数据段，为后续恢复提供实际坐标。
如果你研究过 NTFS，就知道这一步非常关键：能不能从元数据走到真实数据段，决定了恢复是不是停留在“看到文件名”的层面。
3. FAT12/16/32 与 exFAT 删除目录项扫描
对于 FAT 系列文件系统，项目支持：
- 删除目录项扫描
- 尝试按链式簇重建
- 或在特定场景下按连续簇假设重建文件段
这对 U 盘、旧设备、移动存储来说非常实用。 尤其是 exFAT，很多移动设备、U 盘、SD 卡都在用。
当然，项目也很诚实地说明了：在严重碎片化场景下，FAT/exFAT 仍可能只能恢复部分段，这一点非常真实。
4. ext4 删除 inode 扫描
在 Linux 场景下，YanMiRestore 支持：
- 扫描
i_dtime != 0的删除 inode - 解析 extent
- 支持直连块映射提取
这说明它已经具备一定的 ext4 删除元数据恢复能力，而不是只靠“签名雕刻”去碰运气。
对于学习 Linux 文件系统恢复的同学来说，这一块很有参考价值。
5. 原始镜像签名雕刻恢复
当文件系统元数据损坏、目录项丢失、或者无法通过正常删除记录恢复时，YanMiRestore 还提供了签名雕刻能力。
当前支持的类型包括：
jpgpngpdfsqlitedocxxlsxmp4
签名雕刻的特点是： 不依赖完整目录结构，直接在原始镜像里搜索文件特征。
这是一种典型的“兜底方案”，适合在文件系统元数据失效时使用。 当然，它也有典型缺点：可能误报，也可能因为碎片化导致恢复结果不完整。
三、这个项目最亮眼的，不是功能，而是设计思路
很多人写工具，习惯先把功能堆起来。 但 YanMiRestore 给人的感觉是：它不是先堆功能，而是先立规矩。
它最值得肯定的地方，不是“支持了几个文件系统”，而是它把“安全恢复”这件事做成了默认行为。
1. 默认 dry-run，不直接写文件
recover 命令默认并不会直接导出文件，而是只生成恢复动作计划。
只有显式加上：
--execute
它才会真正写出恢复结果。
这个默认值特别专业。因为很多恢复事故，本质上不是工具不行，而是用户太着急，直接执行了高风险操作。
YanMiRestore 通过默认 dry-run，强行把“先看、再动手”变成了标准流程。
2. 强制阻止危险输出路径
项目对恢复目标路径做了严格限制：
- 目标目录位于源路径内部：禁止
- 目标目录是源目录父路径：禁止
- 目标路径与源路径相同：禁止
- Windows 下与源路径同卷：禁止
这一点真的很加分。
因为数据恢复里最危险的操作之一，就是把恢复结果写回源盘所在卷。 一旦发生覆盖，很多原本还能恢复的数据就真的没机会了。
YanMiRestore 直接从程序层拦截这种操作，而不是把风险留给用户自己“注意”。
3. 保留扫描报告和恢复清单
恢复流程中会生成：
scan-report.json扫描报告恢复清单.json恢复结果清单
这意味着整个恢复过程是可追踪的、可复盘的、可审计的。
这对于以下场景特别有意义：
- 企业内部数据恢复
- 合规审计
- 批量恢复任务
- 技术排查与复现
- 项目演示与教学
四、命令设计非常清晰，适合实战
YanMiRestore 当前的核心命令有 4 个：
designscanrecoverdevices
这套命令设计很像一个完整的恢复流水线，而不是散乱的几个功能入口。
1. design：先生成恢复方案
这个命令会根据：
case-id- 目标类型
- 扫描深度
- 文件系统提示
生成一个恢复执行计划。
它会输出：
- 阶段步骤
- 安全规则
- 前置假设
这一步非常像“恢复前评估”。 在实际项目中，这种设计非常有价值，因为它让恢复过程从“黑盒操作”变成“可解释流程”。
2. scan：只读扫描，生成统一报告
scan 是整个项目最核心的命令之一。
它可以：
- 自动识别输入是挂载目录还是镜像文件
- 自动识别目标类型
- 支持交互确认
- 支持
--yes跳过确认，便于脚本化执行 - 输出 JSON 扫描报告
- 打印扫描摘要与文件系统统计信息
更关键的是：它是只读扫描。
这意味着扫描过程中不会往源介质写入内容，尽可能保护原始现场。
3. recover：按扫描报告执行恢复
这个命令并不是直接重新扫源，而是读取扫描报告进行恢复。
不同候选项的处理方式也不同：
- 逻辑项：从回收站路径复制
- NTFS / ext4：按
source_segments分段提取 - 雕刻项：按
offset + size从镜像提取
这说明项目在架构上已经做到了“扫描”和“恢复”解耦。 这种解耦的好处很大：
- 扫描结果可复用
- 恢复逻辑更清晰
- 便于调试
- 便于批处理
- 更适合后续扩展 GUI 或任务系统
4. devices：自动识别设备
新增的 devices 子命令，可以列出本机可用设备，并自动标注为：
- 电脑硬盘
- 移动硬盘
- 手机
- 其他设备
这对普通用户特别友好。 因为很多用户根本不清楚自己要扫的是哪个路径，尤其是在 Windows 下，盘符、卷路径、可移动设备类型都容易搞混。
有了 devices，至少可以先识别设备，再做扫描，大幅降低误操作概率。
五、最近新增的几个功能，很明显是在往“可用工具”打磨
从项目更新内容来看，YanMiRestore 不只是能跑，而是在明显提升“用户体验 + 可配置性”。
1. 动态进度条
现在项目支持动态刷新进度条，包含：
- 旋转符
- 已耗时
- 当前进度
- 百分比
- 阶段信息
而且扫描和恢复阶段都能显示。
这在恢复类工具里非常重要。因为恢复任务通常耗时较长，用户最怕的是：
- 不知道程序是不是卡死了
- 不知道进行到哪一步了
- 不知道当前在处理什么
动态进度条解决的不是“好不好看”，而是“能不能安心等”。
2. --skip-carved
新增的 --skip-carved 参数非常实用。
它允许在恢复时： 只恢复文件系统候选项，跳过签名雕刻结果。
为什么这个功能重要？
因为雕刻恢复虽然常常能找到更多结果，但也更容易出现：
- 文件碎片化
- 恢复结果不完整
- 误报
- 文件损坏
如果你的目标是“先拿到更稳的结果”，那跳过雕刻项，优先恢复文件系统元数据指向的候选项，往往更合理。
3. YanMiRestore.toml 配置文件
这一点说明项目已经开始从“命令行工具”往“可配置的工程化工具”升级。
配置文件支持管理：
ui：进度条刷新频率、动画间隔、模板、旋转帧等scan：逻辑扫描上限与回收站目录名carver：雕刻读取范围、条目上限、格式阈值等fs.ntfs / fs.fat / fs.ext4：文件系统扫描阈值partition：分区解析上限recovery：恢复缓冲区与卷对齐参数
这意味着你可以根据不同设备、不同容量、不同恢复策略，灵活调整扫描与恢复行为。
对于做批处理、做内部工具封装、做长期维护的人来说，这一步非常关键。
六、项目目录结构也很有参考价值
如果你正在学习 Rust 工程化项目结构，那 YanMiRestore 的目录划分值得借鉴。
它没有把所有逻辑塞进一个 main.rs，而是按职责拆成多个领域模块：
main.rs：程序入口app：命令分发与流程编排cli：参数定义config：配置加载error：统一错误类型model：请求、计划、报告、设备等领域模型scanner：扫描流程recovery：恢复流程report：输出与报告写入device：设备识别carver：签名雕刻fs：文件系统扫描聚合（NTFS / FAT / ext4 / partition）
这样的拆分带来几个直接好处：
- 职责清晰，后续扩展不容易乱
- 文件系统模块可以独立维护
- 配置、模型、流程解耦明显
- 后期新增 APFS / F2FS / 更多雕刻格式时更容易扩展
- 更适合多人协作
对于一个恢复工具来说，这种结构说明它已经不再是“练手脚本”，而是具备了长期演进的基础。
七、一个推荐的实战使用流程
如果你真的要用这个工具，我建议按下面这个顺序来，最稳：
# 1）先生成恢复方案
cargo run -- design --case-id CASE-1001 --target-kind pc-disk --depth deep --include-carving
# 2）只读扫描，生成报告
cargo run -- scan --source E:\evidence\disk.img --output .\output --case-id CASE-1001 --target-kind pc-disk --depth deep --include-carving
# 3）先做恢复预演（不写文件）
cargo run -- recover --report .\output\CASE-1001-scan-report.json --destination G:\restore
# 4）确认无误后，再执行实际恢复
cargo run -- recover --report .\output\CASE-1001-scan-report.json --destination G:\restore --execute
这套流程的优点非常明显：
- 先看方案，不盲扫
- 先扫描，不直接写
- 先预演，不急着导出
- 确认无误，再执行恢复
这正是 YanMiRestore 的核心哲学： 恢复不是一锤子买卖，而是一个需要控制风险的过程。
八、它的“已知限制”反而是加分项
很多项目最怕的一件事，就是 README 写得像神仙下凡，实际一跑全是坑。
YanMiRestore 的一个优点是：它把限制写得很清楚。
比如当前仍存在这些边界：
- NTFS 压缩 / 加密流尚未实现解码
- FAT/exFAT 与 ext4 的某些删除项解析仍处于稳态占位实现
- FAT/exFAT 在严重碎片化场景下可能只能恢复部分段
- exFAT
NoFatChain仍依赖连续簇假设 - ext4 尚未完整重建删除文件名
- ext4 旧式多级间接块尚未完整解析
- APFS / F2FS 目前仅能做签名探测
- 签名雕刻本身存在误报风险
- 手机场景仅面向合法导出数据，不涉及绕过加密
看起来像是“问题不少”，但实际上，这种明确边界的态度，比“什么都能恢复”的宣传靠谱得多。
因为数据恢复本来就不是一个“百分百成功”的领域。 把能力和边界说清楚，才是一个成熟工具该有的样子。
九、YanMiRestore 适合哪些人参考？
如果你是下面这几类人，我觉得这个项目都值得看：
1. Rust 学习者
你可以从中学习：
- CLI 工具项目如何拆分模块
- 如何设计命令流
- 如何做统一错误处理
- 如何做配置驱动
- 如何构建更有工程味道的 Rust 项目
2. 系统工具开发者
这个项目很适合参考“高风险工具”的设计思路：
- 如何做只读约束
- 如何阻止危险路径
- 如何做 dry-run
- 如何保留执行报告
- 如何把流程设计得更稳
3. 文件系统 / 数据恢复方向的技术研究者
如果你对以下内容感兴趣：
- NTFS MFT 删除记录
- FAT/exFAT 删除目录项
- ext4 删除 inode
- 原始镜像签名雕刻
- 分区识别（MBR/GPT）
那么这个项目具备一定的学习与扩展价值。
4. 想做自己恢复工具的人
很多人想写恢复工具，但一开始就容易陷入“先实现扫描”的思路。 实际上，恢复工具更难的，往往不是扫描代码，而是安全约束和流程设计。
YanMiRestore 提供了一个很好的切入点： 先把“恢复纪律”立住，再慢慢增强恢复能力。
十、我对这个项目的评价
一句话总结：
YanMiRestore 现在可能还不是“最强恢复工具”，但它已经是一套很有方向感的数据恢复工程框架。
它的价值不只是“支持了 NTFS / FAT / ext4 / 雕刻”，而是它在很早期就做对了几件特别重要的事：
- 把“源盘只读”变成设计核心
- 把“安全优先”落实到命令默认值和路径限制
- 把“恢复过程”做成可追踪、可审计的流水线
- 把项目结构做成了可持续演进的工程化模块
这类项目，最怕的是方向跑偏。 而 YanMiRestore 的方向，我认为是对的。
对于数据恢复这种高风险场景来说，先保证不伤源，再尽可能恢复，永远比“先扫出来再说”更专业。
结尾
如果你正在找一个适合学习的 Rust 实战项目，或者你想研究“如何做一个安全的数据恢复工具”，YanMiRestore 是一个非常值得关注的开源项目。
它现在当然还有不少可提升空间，但从当前设计来看，它已经具备了一个好项目最重要的东西：
清晰的边界、正确的方向、工程化的结构，以及对风险的敬畏。
这比单纯“功能多”更难得。
