网硕互联帮助中心那是个周五傍晚，我在清理脚本里手滑多打了一个通配符，rm -rf cache* 变成了对一整个项目目录的处刑。
冷静下来的第一反应是去搜「Linux 误删恢复」。教程们热情洋溢：extundelete、testdisk、photorec，步骤齐全。我照做了——部分成功：删掉的源码找回了七成，另外三成永远消失。当时我不明白为什么是七成，也没人告诉我这数字还能更低。
这篇把恢复的真实面貌讲清：能救多少、什么时候救不了、以及为什么「预防」比「恢复」便宜一万倍。
〇、先花两分钟：rm 的时候磁盘上发生了什么
常识想象是「数据被擦掉了」。几乎不是。 真实过程（以 ext4 为例）：
rm 只干两件小事：把文件目录项里那行删了（以后按名字找不到它了），把 inode 标记为空闲（inode = B2 讲过的那页账本，记录数据块位置）；
数据块本身一个字节没动——文件内容还躺在盘上，只是「没人认领」；
真正的抹除发生在之后：任何新写入的文件都可能认领这些空闲块，覆写旧内容。
推论是这篇的核心：误删后的盘像一杯打翻的水，恢复像抢救桌面上的水——每过一秒桌面都在变干。 误删后系统继续跑、日志继续写、浏览器继续缓存，全在喝你的水。
所以误删后第一个动作不是装恢复工具（装包本身就在写盘！），是停止写入：能 umount 就 umount，能关机就关机（mount -o remount,ro 也行）。云主机还有一招大招：先打快照，然后在快照上恢复，原盘一个字节不动。
图示：rm 后磁盘真实状态、正确动作顺序与失败场景
一、extundelete：能用的姿势
前提三件事：ext3/ext4 文件系统、设备已只读或卸载、包名相同（sudo apt install extundelete）。
sudo extundelete /dev/sdb1 –restore-file projects/app/main.py
sudo extundelete /dev/sdb1 –restore-all
怎么读：前者指定路径恢复单个文件（相对分区根的路径，不带开头斜杠，带斜杠它会报「找不到」——高频翻车点）；后者全盘扫描恢复一切可识别的。恢复出来的文件放在执行目录下的 RECOVERED_FILES/ 里。
它的工作原理值得知道一句：扫描磁盘上「没被覆写的旧 inode 残影」，把 inode 记录的数据块链重新串起来。这个原理直接推导出所有失败场景——
二、三大失败场景：教程不会说的部分
场景 1：块已被覆写。 误删后继续用盘一小时再恢复，新写入的数据认领了旧块。残影在，内容已是别人的。这是「七成」变「两成」的头号原因，时间就是成功率。
场景 2：小文件 + 日志式文件系统。 ext4 的删除会清掉 inode 里的数据块指针（日志式文件系统为了一致性，删除时顺手抹了指针）。于是 extundelete 找得到 inode「这里曾有个文件、大小多少」，却不知道数据在哪，只能按文件大小在附近「猜」着抓。小文件常抓成碎片或乱码。ext3 时代恢复率反而高些——这是个残酷的技术倒退。
场景 3：XFS/Btrfs 上，extundelete 直接不适用。 它只认 ext 系。XFS 上基本只剩 photorec（见下）这种内容扫描流。
顺带一说 photorec：不读文件系统账本，直接按文件头签名（JPEG 的_ff d8、PDF 的 %PDF 这类）扫描全盘内容。好处是什么文件系统都行（连 Windows 盘都行），坏处是丢文件名和目录结构——恢复出 3000 张 f0001234.jpg，靠人眼一张张归位。适合「只要内容，不要结构」的绝望时刻。
三、三个真实建议
rm 是延迟陷阱：先 -i 一次再放行。 交互式 rm 太烦，但通配符 rm 前先 ls 一遍同表达式看看命中谁，成本三秒。我现在的肌肉记忆：任何带 * 的 rm，先跑一遍同参数的 ls；
rm 没有回收站，但可以造一个。 桌面环境其实有（GNOME 的「垃圾箱」），纯命令行的替代方案是 trash-cli（sudo apt install trash-cli，用 trash-put 代替 rm，trash-list 查看、trash-restore 恢复）。脚本里继续用 rm，手动删除改用 trash-put，就够了；
真正靠谱的从来是备份：rsync 定时快照、LVM 快照（D3 那套）、云盘打快照。恢复工具的成功率是概率，备份的成功率是 100%。F4 那篇会写一个能进生产的备份脚本。
四、和前后篇的关系
-
删除的底层机制（inode、链接计数）与 B3（已删文件仍被进程占用、磁盘不释放）是同一枚硬币的两面：B3 是「删了但进程还拽着」，本篇是「删了真没人拽」；
-
「先打快照再操作」的底气来自 D3 的 LVM 快照或云平台快照；
-
ext4 vs XFS 的选择（D4）直接影响你能用哪条恢复路线。
速查表（文末收藏版）
误删后第一动作 → 停止写入！umount / remount,ro / 云机先打快照
ext3/ext4 恢复 → sudo extundelete /dev/sdX1 –restore-file 相对路径/不带开头斜杠
全扫 → sudo extundelete /dev/sdX1 –restore-all （结果在 RECOVERED_FILES/）
其他文件系统/绝望局 → photorec（按文件头扫内容，丢文件名和目录）
恢复前 → 设备只读；别在原盘装工具、别往原盘写任何东西
失败三大场景 → 块被覆写 ／ ext4 小文件指针已清 ／ XFS/Btrfs 不适用
带 * 的 rm → 先跑一遍同参数的 ls
命令行回收站 → trash-cli（trash-put / trash-list / trash-restore）
成功率排序 → 备份 100% > 快照 > 恢复工具（概率）> 祈祷
评论前必须登录！
注册