rm删除后能否恢复取决于文件是否被进程占用及文件系统类型和后续写入情况；若文件仍被进程打开，可通过/proc直接复制恢复；ext3/ext4可用extundelete或debugfs，但需立即停写并卸载分区；GUI回收站仅适用于桌面环境下的图形化删除操作。
rm删除后能不能恢复，取决于两件事：**文件是否还在被某个进程打开**，以及**文件系统类型和后续写入情况**。能恢复，但不是“一键还原”，也没有通用方案——得看删的是什么、删完做了什么、用的是哪种文件系统。
文件还在被进程占用时，直接从 /proc 拿回来
这是最快、最可靠的方式，但只适用于：文件刚删，且仍有进程（比如日志服务、Web 服务器、tail -f、cat、vim 编辑中未退出等）在读/写它。
常见错误现象：df 显示磁盘空间没释放，lsof | grep deleted 能看到带 (deleted) 标记的条目。
- 用
lsof +L1或lsof | grep deleted找出对应 PID 和 FD 编号（比如 PID=1234，FD=3） - 确认该 FD 确实指向你要恢复的文件：
ls -l /proc/1234/fd/3，输出里应含原路径和(deleted) - 执行恢复：
cp /proc/1234/fd/3 /path/to/recovered_file（注意目标路径不能在原分区，避免覆盖） - 别用重定向（如
cat /proc/1234/fd/3 > file），某些场景下会截断或编码异常
ext3/ext4 分区上删了就没了？试试 extundelete
它依赖 ext3/ext4 的日志（journal）和 inode 信息，对 XFS/Btrfs 不起作用，对已覆盖的 inode 也无能为力。
使用前提：删完立刻停止对该分区的所有写入（umount 最好；若根分区，需 Live CD 启动）。
- 安装：
sudo apt install extundelete（Debian/Ubuntu）或sudo yum install epel-release && sudo yum install extundelete（CentOS/RHEL） - 恢复单个文件：
sudo extundelete --restore-file path/to/file /dev/sda1 - 恢复整个目录：
sudo extundelete --restore-directory path/to/dir /dev/sda1 - 不指定文件名，只扫描可恢复列表：
sudo extundelete --inode 0 /dev/sda1，它会列出所有可恢复 inode - 生成的文件默认放在当前目录的
RECOVERED_FILES/下，别漏看
debugfs 手动捞 inode，适合知道大概位置但没工具可用时
这是底层方法，需要你手动定位 inode 号，适用于 ext2/ext3/ext4，但操作门槛高、容易出错。
常见错误现象：extundelete 报 “No journal found” 或根本找不到目标文件。
- 先卸载分区：
sudo umount /dev/sda1 - 用
sudo debugfs /dev/sda1进入交互模式 - 查删除前所在目录的 inode：
ls -d /path/to/parent/dir（比如返回234567） - 列出该目录下已删除项：
lsdel，找时间戳接近、名字匹配的 inode 行 - 用
dump导出原始数据（可能含垃圾字节，需后续清理）/tmp/recovered - 导出后检查内容：
file /tmp/recovered，再用strings或 hexdump 辅助判断是否完整
别指望 GUI 回收站，除非你真用的是桌面环境+没用 rm
Linux 没有全局回收站机制。rm 是绕过任何中间层直接 unlink 的；而 GUI 文件管理器（如 Nautilus、Dolphin）删文件时，其实是 mv 到 ~/.local/share/Trash/files/，并记录元数据到 ~/.local/share/Trash/info/。
- 如果你是点鼠标删的，去
~/.local/share/Trash/files/找，用mv拿回来即可 - 但一旦执行过
rm -rf ~/.local/share/Trash/或清空回收站，这部分也彻底没了 - SSH 或脚本里调用
rm，哪怕在桌面机上运行，也绝不会进回收站
恢复成功率高度依赖「时间」和「静默」：删完立刻停写、立刻行动，比选哪个工具重要得多。工具只是把残存的 inode 或日志块重新拼出来，它们不创造数据——数据早就在那里，只是没人再指着它罢了。
