能恢复，但取决于文件是否被进程占用及文件系统是否为ext3/ext4；lsof+/proc/pid/fd/可快速恢复正被读写的文件，extundelete适用于ext3/ext4已退出进程的恢复，testdisk/photorec为底层兜底方案。
能恢复，但取决于两个关键条件：文件是否还在被进程占用、文件系统类型是否为 ext3/ext4。其他情况（如 XFS、Btrfs 或已覆盖数据）基本无解。
lsof + /proc/pid/fd/ 恢复正在被进程读写的文件
这是最快、最可靠的方式，适用于删除后仍有进程在读或写该文件的场景——比如日志被 tail -f、程序正用 fopen(..., "a") 追加、或者 cat 命令还在输出中。
-
lsof | grep deleted能直接列出所有标记为(deleted)的打开文件，重点关注FD列（如1w表示标准输出写入）和PID - 确认 PID 后，进
/proc/<pid>/fd/</pid>目录，用ls -l查看软链目标，带(deleted)的就是你要的文件 - 执行
cp 1 /recovered.txt（其中1是 fd 编号）即可复制出原始内容 - 注意：该方法不依赖文件系统类型，但要求进程未退出；一旦进程终止，
/proc/pid/fd/下对应条目消失，这条路就断了
extundelete 恢复 ext3/ext4 上已退出进程的文件
extundelete 是专为 ext3/ext4 设计的恢复工具，它靠解析日志（journal）和 inode 位图来找回已删除但未覆盖的数据。不支持 XFS、NTFS 或 btrfs。
- 必须先卸载目标分区：
umount /dev/sda2；若无法卸载，至少要立刻停写（mount -o remount,ro /dev/sda2） - 用
extundelete --inode 2 /dev/sda2查根目录 inode，再逐层用--inode <num></num>找到被删文件的 inode 号 - 恢复单个文件用
extundelete --restore-inode <ino> /dev/sda2</ino>，结果会放在当前目录的RECOVERED_FILES/中 - 慎用
--restore-all：它会尝试恢复所有可识别的文件，但可能混入大量垃圾或损坏碎片，且耗时极长
testdisk/photorec 作为兜底方案：不依赖文件系统结构
当 extundelete 失效（比如日志已被清空、分区是 XFS、或你不确定文件系统类型），photorec 是更底层的选择——它跳过文件系统元数据，直接扫描磁盘块，按文件头尾特征（magic bytes）拼接内容。
-
photorec不恢复原文件名、路径、时间戳，只按类型（如.py、.log）重建内容，命名类似f0000001.py - 运行前务必把目标分区挂为只读，或用
dd先做镜像（dd if=/dev/sda2 of=/backup/sda2.img），避免边扫边写导致覆盖 - 支持绝大多数常见格式（文本、图片、PDF、Office 文档等），但对纯文本类（如配置文件、脚本）容易误判或截断，需人工筛查
-
testdisk本身主攻分区表修复，photorec是其附带的文件恢复子工具，安装testdisk即包含它
真正决定成败的不是工具选哪个，而是动作够不够快：只要磁盘还有写入，被删文件的块就随时可能被覆盖。从发现误删那一刻起，停止一切对目标分区的写操作，比记住命令更重要。
