extundelete仅支持ext3/ext4因直接解析其日志和inode位图，不兼容xfs/btrfs/ntfs；恢复前须卸载或只读挂载，优先用live系统操作，恢复单个文件比目录更可靠，且无法恢复硬链接本身。
extundelete 为什么只能恢复 ext3/ext4 文件系统
因为 extundelete 直接解析 ext3/ext4 的日志（journal）和 inode 位图，它不支持 xfs、btrfs 或 ntfs。如果你的分区是 mkfs.xfs 格式，装了 extundelete 也完全没用——它连设备都打不开，会直接报错 No EXT3 filesystem found。
实操建议：
- 先用
df -T /path或lsblk -f确认文件系统类型，别凭印象判断 - 如果已是 ext4，注意：开启
extents和filetype特性不影响恢复，但启用metadata_csum（默认开启）可能导致部分旧版本extundelete解析失败 - 别在误删后继续写入数据——哪怕只是
ls -l列目录，也可能触发元数据更新，覆盖待恢复 inode 的信息
恢复前必须卸载或只读挂载分区
运行 extundelete 时若目标分区仍为读写挂载，工具会拒绝操作，并提示 Device or resource busy。这不是权限问题，而是防止恢复过程中新文件分配到刚释放的 block，导致数据被覆盖。
实操建议：
- 优先使用 Live CD/USB 启动，然后
sudo umount /dev/sdXN（例如/dev/sda2） - 实在无法卸载（比如根分区），可尝试临时切为只读：
sudo mount -o remount,ro /，但风险高，仅限紧急且无其他选择时 - 别用
lsof +L1查“已删除但进程还在用”的文件——那类文件extundelete根本不处理，它是面向已从磁盘释放的 inode
恢复单个文件比恢复整个目录更可靠
extundelete 恢复全目录（如 --restore-directory）依赖目录项（dirent）未被覆盖，而目录结构比文件内容更容易被新写入破坏。实际中，常出现“能列出文件名，却恢复出空文件”或“恢复出乱码文件名”的情况。
实操建议：
- 先用
extundelete /dev/sdXN --inode 2查根目录 inode，再逐层--ls找目标路径，确认 inode 存在且状态为Deleted - 明确知道文件路径时，直接用
--restore-file "path/to/file.txt"，它只读取对应 inode 和 block，成功率高得多 - 恢复出的文件默认放在当前目录的
RECOVERED_FILES/下，注意检查文件大小和file命令输出，避免恢复出零字节或损坏的副本
extundelete 恢复不了硬链接指向的原始 inode
如果误删的是硬链接本身（不是源文件），而源文件还存在，那根本不需要恢复——硬链接只是多一个目录项指向同一 inode。extundelete 不区分“链接被删”和“文件被删”，只要 dirent 标记为 deleted，它就按文件恢复，结果可能是重复内容，也可能是 inode 已被复用后的垃圾数据。
实操建议：
- 执行恢复前，先用
stat对比疑似源文件和备份路径的Inode和Links字段 - 若发现目标文件仍有多个硬链接存活（
Links > 1），说明数据仍在，删掉的只是其中一个入口，不用跑extundelete - 真正难恢复的是：文件所有硬链接都被删，且原 inode 未被复用——这时才轮到
extundelete上场，但它无法告诉你“这个 inode 原本属于哪个路径”，只能靠你记得名字去猜
最麻烦的不是命令不会输，而是删完才发现没开快照、没配 rsync、也不记得文件最后一次修改时间——这时候再翻日志、查 backuppc 记录，比敲十遍 extundelete 都费劲。
