误删文本文件可恢复，关键在于立即停止写入、按文件系统类型选择工具：进程仍在使用时从/proc/PID/fd直接拷贝（100%保内容）；ext3/ext4用extundelete按原路径恢复；XFS/Btrfs或已写入则用photorec扫描原始块；紧急无工具时可用debugfs提取inode数据。
误删文本文件后，恢复关键在于“快停写 + 对症工具 + 保留原内容”。文本文件本身不依赖复杂结构，但恢复方式高度依赖文件系统类型和删除后的操作状态。以下几种方法按优先级和适用场景展开：
进程还在用？直接从 /proc/fd 拿回来
这是最快、最稳、100%保内容的方法，前提是删除后相关进程没退出——比如日志服务、Web 服务器、编辑器后台进程仍在读写该文件。
- 运行 lsof | grep deleted，找带“(deleted)”标记的行，记下 PID 和 FD 编号（如 3）
- 执行 sudo cat /proc/PID/fd/FD编号 > recovered.txt，例如：
sudo cat /proc/1234/fd/3 > config_backup.conf - 注意：路径必须写对，输出文件建议存到其他分区，避免覆盖原位置
ext3/ext4 文件系统？优先用 extundelete
适用于刚删不久、未大量写入、且确认是 ext3 或 ext4 分区的情况。它能按原路径、原名恢复，包括 .txt、.log、.conf 等纯文本文件。
- 先查类型：df -T /path/to/deleted/file，确认 Type 是 ext4 或 ext3
- 立即只读挂载：sudo mount -o remount,ro /dev/sdXN（根分区需进 Live USB 操作）
- 恢复单个文本文件：sudo extundelete /dev/sdXN --restore-file "home/user/notes.txt"（路径是相对于分区根目录，不是绝对路径）
- 恢复后文件默认在当前目录的 RECOVERED_FILES/ 下，名字带序号，可用 file RECOVERED_FILES/* 快速识别文本类
非 ext 系统（XFS/Btrfs）或已写入？用 photorec 扫描原始块
当文件系统是 XFS、Btrfs，或你已重启、写入新日志、无法卸载时，extundelete 失效，photorec 是通用兜底方案。它不认目录结构，靠识别文件头尾特征（如文本文件虽无固定头，但常含可读 ASCII 字符段）拼出内容。
- 安装：sudo apt install testdisk（photorec 是其子命令）
- 运行：sudo photorec /dev/sdXN，交互中选分区 → 选 “Other”（通用模式）→ 选存储位置（务必避开原分区）
- 恢复出的文件名是自动生成的（如 f0000001.txt），可用 head -n 20 f0000001.txt 快速预览是否为你要的文本内容
- 小技巧：若记得部分关键词（如某段报错信息），恢复后可在所有结果里用 grep -l "关键词" * 筛选
实在没工具？试试 debugfs 提取 inode 原始数据（ext 系列专属）
适合无法安装新软件、又确定是 ext 分区的紧急情况。它绕过日志，直接从 inode 读取未覆盖的数据块，但需手动定位 inode 号，且不保证文件名和编码完整。
- 先卸载或只读挂载目标分区
- 进入调试：sudo debugfs /dev/sdXN，输入 lsdel 查看已删 inode 列表（关注 Size 和 Deletion time 接近的）
- 记下目标 inode（如 123456），退出后执行：
sudo debugfs -R "dump 123456 /tmp/recovered_raw" /dev/sdXN - 用 file /tmp/recovered_raw 看类型，再用 iconv 或 vim -b 查看是否为可读文本
