Linux删除文件后数据仍可能残留于磁盘，因rm仅解除链接；若进程占用可从/proc/PID/fd/恢复，ext4可用extundelete（需只读挂载），photorec则适用于多种文件系统但无原名。
Linux 删除后文件还在哪儿？
Linux 删除文件时，rm 命令只是解除文件名到 inode 的链接（unlink），如果进程仍在占用该文件，它的数据块不会立刻被覆盖。所以“已删除”不等于“不可恢复”——关键看是否被新数据覆盖、是否有进程持有句柄、是否在 ext4/xfs 等支持日志的文件系统上。
常见错误现象：ls 看不到文件，但 lsof +L1 能列出带 DEL 标记的条目；df 显示磁盘空间没释放，说明文件虽删但未真正释放。
- 优先检查是否被进程占用：运行
lsof +L1（需 root 权限）或lsof | grep deleted - 若看到结果，直接从
/proc/<pid>/fd/<fd_num></fd_num></pid>复制出来，比如cp /proc/1234/fd/5 ./recovered.log - ext4 文件系统下，
debugfs可尝试恢复已 unlink 但未覆盖的 inode，但需卸载分区或确保只读挂载，否则风险极高
用 extundelete 恢复 ext3/ext4 上已删文件
extundelete 是专为 ext3/ext4 设计的恢复工具，依赖文件系统日志（journal）中残留的元数据。它不能恢复 xfs、btrfs 或已禁用日志的 ext4 分区上的文件。
使用场景：误删重要配置、日志、源码，且删除后没写入大量新数据、没重启、没执行 sync 或 dd 类操作。
- 安装：Ubuntu/Debian 上用
sudo apt install extundelete；CentOS 需先启用 EPEL，再yum install extundelete - 必须对**未挂载**或**只读挂载**的设备操作，例如
sudo extundelete /dev/sdb1 --restore-file home/user/report.txt - 如果不知道路径，先用
--restore-all，恢复内容默认放在当前目录的RECOVERED_FILES/下 - 失败常见原因：分区正在读写、日志已被覆盖、文件系统是 xfs（此时
extundelete直接报错Couldn't find ext3 filesystem）
photorec 不依赖文件系统结构，但恢复后无原名
photorec（属于 testdisk 套件）跳过 inode 和目录结构，直接扫描磁盘块识别文件头（magic bytes），因此能跨文件系统工作（ext4/xfs/btrfs/NTFS），也适用于损坏或格式化后的分区。
但它无法还原原始路径和文件名，所有恢复出的文件都按类型编号（如 f0000001.jpg），需要人工筛选。
- 安装后运行
sudo photorec，交互式选择磁盘 → 分区 → 文件系统类型 → 恢复目标目录 - 默认只恢复常见类型（PDF、TXT、PNG、SQL 等），如需恢复
.log或自定义扩展名，进菜单选File Opt手动开启 - 速度慢、结果杂：一次恢复可能产生上万小文件，
grep -r "ERROR" RECOVERED/这类命令比盲目翻找更有效 - 别在原盘恢复：务必指定外接硬盘或另一分区作为输出路径，否则写入动作会覆盖待恢复数据
为什么 rm -rf 后几乎没法靠系统命令找回？
Linux 内核不提供“回收站”机制，rm 是直接 unlink + mark block free。没有类似 Windows 的 $Recycle.Bin 或 macOS 的 .Trashes 隐含层兜底。
容易被忽略的关键点：
-
trash-cli这类第三方工具必须**提前安装并习惯使用trash替代rm**，事后装没用 - 某些桌面环境（GNOME/KDE）的文件管理器删文件会走 trash，但终端里
rm绕过一切 - 即使有快照（LVM/btrfs/zfs），也得事先配置好，不是删完再建快照就能回滚
- SSD 上因 TRIM 特性，删除后几秒内物理块就可能被清空，
photorec也可能失效
真要保命，只有两个硬动作：定期备份（rsync 或 borg）、对关键目录启用写前快照。其他都是赌概率。
