误删文件后应立即停止磁盘写入，优先使用 debugfs 提取未链接 inode 或 extundelete 按路径恢复；仅当二者失效且文件系统损坏时才用 photorec 扫描裸块。
误删文件后立刻停写磁盘
Linux 下删除文件只是解除 inode 链接，数据块本身未必被覆盖。但只要系统继续写入（日志、缓存、临时文件），就可能覆盖原数据块，恢复成功率断崖式下降。
关键动作不是找工具，而是先阻止进一步写入：
- 如果在本地终端操作，立即
sync后切到只读模式：mount -o remount,ro /（需 root） - 如果是远程服务器，优先断开非必要进程（尤其
rsync、logrotate、用户脚本） - 不要运行
apt upgrade、yum update或任何安装 / 编译行为 - 别用
dd或shred清理“空闲空间”——那等于主动擦除证据
ext4 文件系统用 debugfs 直接提取未链接 inode
ext4 是主流发行版默认格式，debugfs 是内核自带的底层调试工具，不依赖第三方安装，且能绕过文件系统层直接读取磁盘结构。它适合已知文件名或大致创建时间的场景。
典型流程（以恢复 /home/user/report.txt 为例）：
- 先卸载分区：
umount /dev/sda2（不能对挂载中的 ext4 使用debugfs -w） - 启动交互式调试：
debugfs /dev/sda2 - 查最近删除的 inode：
lsdel（输出含时间戳和大小，可筛出目标文件） - 若知道原路径，用
dump <inode> /tmp/recovered.txt</inode>提取内容 - 注意：
lsdel不显示文件名，得靠大小 + 时间 + 目录位置交叉判断
风险点：误 dump 其他 inode 可能输出二进制乱码，建议重定向到文件再用 file 或 head 检查。
extundelete 恢复带路径的完整文件树
当需要按原路径还原多个文件（比如整个被 rm -rf 的项目目录），extundelete 比 debugfs 更省力，它能重建目录结构并保留文件名。
但有硬性前提：必须在文件系统启用 ext3 或 ext4 的 journal 模式下工作，且 journal 未被循环覆盖。
- 安装：
sudo apt install extundelete（Debian/Ubuntu）或yum install extundelete（RHEL/CentOS） - 基础恢复：
extundelete /dev/sda2 --restore-all（结果进RECOVERED_FILES/） - 按路径恢复：
extundelete /dev/sda2 --restore-directory /home/user/project - 失败常见原因：
extundelete报No journal found→ journal 已被覆盖，此时只能退回debugfs或扫描工具
别碰 photorec 除非其他方法全失效
photorec 是基于文件头签名的无文件系统恢复工具，不认 inode、不看路径、不依赖 journal。它能把磁盘当裸块扫一遍，找回 PNG、PDF、TXT 等常见格式内容。但代价是：所有恢复文件都丢失原名、原目录、元数据，且大量碎片文件会混入结果。
只在以下情况考虑它：
- 文件系统已损坏（
fsck报严重错误） - 误删发生在 XFS/Btrfs 等
extundelete不支持的格式上 -
debugfs和extundelete均提示“no deleted inodes found”
执行前务必用 photorec 的 –d 参数指定外置存储路径，避免写回原盘；恢复出的 recup_dir.1/ 里，用 file * 快速过滤文本类文件，别指望自动归类。
真正难的是判断哪一步该停——journal 是否尚存、inode 是否被复用、磁盘写入是否可控，这些没法靠命令返回值直接告诉你，得结合 dmesg、df -i、lsof +L1 综合看。
