误删文件若进程仍在运行，可通过/proc/PID/fd/直接恢复；ext4分区优先用extundelete（需卸载）；无法卸载时用debugfs查lsdel；元数据损坏则用photorec按文件签名扫描。
文件刚删，进程还在？先看 /proc/PID/fd/
很多误删其实根本不用动工具——只要删的时候文件还被某个进程打开着（比如日志在持续写入、脚本正在读取配置），数据就还在内存+磁盘上，只是目录项没了。
这时候 lsof | grep deleted 一跑，基本就能定位到哪个 PID 还攥着它。
进 /proc/<pid>/fd/</pid>，ls -la 会看到带 (deleted) 标记的文件描述符，直接 cp /proc/<pid>/fd/<n> ./recovered.txt</n></pid> 就完事。
常见坑：
• 进程退出后这条路立刻失效，别等；
• lsof 需要 root 权限才能看到其他用户进程；
• 如果文件是被 rm -rf 连目录一起删的，但进程仍持有着某个子文件句柄，也能单独捞出来。
ext4 分区误删，优先用 extundelete 恢复
extundelete 是目前对 ext3/ext4 最靠谱的“元数据级”恢复工具，前提是：没卸载前别写新数据、没启用 discard（SSD TRIM）、没用 shred 类安全删除。
实操三步不能跳：
• 先 df -T /path/to/file 确认是 ext4；
• 必须 umount /dev/sdXN，挂载状态下恢复大概率失败或损坏；
• 恢复命令选对参数：
– 单个文件：extundelete /dev/sdXN --restore-file "etc/passwd"（路径是相对于分区根）；
– 整个目录：extundelete /dev/sdXN --restore-directory "home/user/docs"；
– 所有可恢复项：extundelete /dev/sdXN --restore-all（结果默认进当前目录的 RECOVERED_FILES/）。
注意：--restore-inode 可用于已知 inode 编号的精准恢复，但得先用 extundelete /dev/sdXN --inode 2 查根目录再逐层翻找，适合目录结构混乱时。
分区没法卸载？试试 debugfs 直接扒 inode
根分区（/）或系统盘删了文件又没法重启进 Live 环境？debugfs 是 ext 系统自带的底层调试器，不依赖第三方安装，但要求你敢直面 inode 和数据块地址。
关键流程：
• sudo debugfs /dev/sdXN 进交互模式；
• 输入 lsdel 列出所有已删但未覆写的 inode（时间越近越靠前）；
• 用 stat <inode_number></inode_number> 看大小、数据块范围是否完整；
• 退出后执行 sudo debugfs -R "dump <inode_number> /tmp/recovered" /dev/sdXN</inode_number> 把原始字节导出来。
风险点：
• 不校验文件头尾，导出来的可能是碎片或混杂内容；
• 如果文件被覆盖过部分数据块，stat 会显示 “0 blocks”，说明不可恢复；
• 导出后得靠 file 或十六进制查看器判断实际类型。
extundelete 失效？换 photorec 扫原始扇区
当 extundelete 报 “No undeletable inodes” 或恢复出来全是乱码，说明文件系统元数据已损，或者用了 XFS/Btrfs 等非 ext 系列——这时就得放弃路径和文件名，靠文件内容特征硬扫。photorec 就是干这个的：
• 它不读 superblock、不认目录树，只扫描磁盘上符合 JPG/PDF/ZIP 等 400+ 种文件头签名的连续扇区；
• 安装后运行 photorec /dev/sdXN，选分区、选保存路径（**必须另存到其他磁盘**，否则越恢复越丢）；
• 恢复结果只有编号命名的文件（如 f0001234.jpg），得靠内容或 file 命令人工识别。
典型失败场景：
• 文件太小（• 文本类文件（如 .txt/.conf）无强签名，容易漏掉；
• SSD 启用 TRIM 后，photorec 也大概率扫不到任何东西。
真正决定成败的不是工具选得多花哨，而是删完那几分钟里——有没有立刻停写、有没有避免 apt update 或日志轮转这类后台写操作。越快断开写入，inode 和数据块保留越完整。别的都是补救，这一步才是底线。
