那是个周五傍晚我在清理脚本里手滑多打了一个通配符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 时代恢复率反而高些——这是个残酷的技术倒退。场景 3XFS/Btrfs 上extundelete 直接不适用。它只认 ext 系。XFS 上基本只剩photorec见下这种内容扫描流。顺带一说photorec不读文件系统账本直接按文件头签名JPEG 的_ff d8、PDF 的 %PDF 这类扫描全盘内容。好处是什么文件系统都行连 Windows 盘都行坏处是丢文件名和目录结构——恢复出 3000 张f0001234.jpg靠人眼一张张归位。适合「只要内容不要结构」的绝望时刻。三、三个真实建议rm 是延迟陷阱先-i一次再放行。交互式 rm 太烦但通配符 rm 前先ls一遍同表达式看看命中谁成本三秒。我现在的肌肉记忆任何带*的 rm先跑一遍同参数的 lsrm 没有回收站但可以造一个。桌面环境其实有GNOME 的「垃圾箱」纯命令行的替代方案是trash-clisudo apt install trash-cli用trash-put代替 rmtrash-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-clitrash-put / trash-list / trash-restore 成功率排序 → 备份 100% 快照 恢复工具概率 祈祷 磁盘实战 05｜rm 误删了还能救回来吗？extundelete 真实成功率、失败场景与三条铁律
那是个周五傍晚我在清理脚本里手滑多打了一个通配符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 时代恢复率反而高些——这是个残酷的技术倒退。场景 3XFS/Btrfs 上extundelete 直接不适用。它只认 ext 系。XFS 上基本只剩photorec见下这种内容扫描流。顺带一说photorec不读文件系统账本直接按文件头签名JPEG 的_ff d8、PDF 的 %PDF 这类扫描全盘内容。好处是什么文件系统都行连 Windows 盘都行坏处是丢文件名和目录结构——恢复出 3000 张f0001234.jpg靠人眼一张张归位。适合「只要内容不要结构」的绝望时刻。三、三个真实建议rm 是延迟陷阱先-i一次再放行。交互式 rm 太烦但通配符 rm 前先ls一遍同表达式看看命中谁成本三秒。我现在的肌肉记忆任何带*的 rm先跑一遍同参数的 lsrm 没有回收站但可以造一个。桌面环境其实有GNOME 的「垃圾箱」纯命令行的替代方案是trash-clisudo apt install trash-cli用trash-put代替 rmtrash-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-clitrash-put / trash-list / trash-restore 成功率排序 → 备份 100% 快照 恢复工具概率 祈祷